Temporal Functions: Time-Weighted Dynamic Pools

Temporal Functions: Time-Weighted Dynamic Pools

Beyond Fixed Weight Pools

Every AMM you have built so far uses a fixed invariant. Constant product locks assets at 50/50. Balancer generalized this to arbitrary fixed weights like 80/20 or 60/20/20. But those weights never change. What if a pool could automatically adjust its weights based on market conditions, turning the AMM into an on-chain trading fund?

That is the core idea behind temporal function AMMs. QuantAMM, the reference protocol for this specialization, introduces dynamic weights that evolve over time based on quantitative strategies. Instead of a static weight vector, the pool evaluates a temporal function that outputs weight values at each block. A pool might start at 50/50 ETH/USDC and gradually shift to 70/30 as momentum signals strengthen, all without any external rebalancing transactions.

This transforms the AMM from a passive liquidity venue into an active portfolio manager. Liquidity providers get exposure to systematic trading strategies simply by depositing into the pool. The Cyfrin security audit of QuantAMM specifically highlights this dual nature: the system is simultaneously a DEX and a fund management protocol, which creates a unique attack surface you will learn to reason about.

Why Dynamic Weights Matter

In a weighted AMM, the invariant is Product(reserve_i ^ weight_i) = k. When weights change, the invariant surface rotates. A higher weight for token A means the pool is willing to hold more of token A relative to its total value. The pricing function itself acts as the rebalancing mechanism, so the pool does not need to execute discrete trades.

Consider a two-token pool with ETH and USDC. At 50/50 weights, the pool values them equally. If the temporal function shifts to 70/30 favoring ETH, the pool now prices ETH more conservatively (requiring more ETH per unit of USDC). This effectively means the pool is increasing its ETH allocation. Arbitrageurs bring prices in line, and the result is a portfolio that tracks the intended allocation without any explicit buy/sell orders.

The Six Strategy Types

QuantAMM defines six families of temporal functions, each encoding a different quantitative strategy:

1. Momentum: Increase weight for tokens with rising prices relative to their moving average. Buy winners, sell losers. Uses the gradient of price relative to EMA.

2. Anti-Momentum (Mean Reversion): The opposite. Increase weight for tokens that have fallen, betting they will revert. Useful in range-bound markets.

3. Minimum Variance: Allocate more to tokens with lower volatility. The goal is to minimize overall portfolio variance, which is a classic portfolio optimization objective.

4. Channel Following: Track whether a token's price is moving toward the upper or lower band of a price channel. Increase weight when price approaches the upper band (trend continuation).

5. Difference Momentum: Instead of absolute momentum, use the difference in momentum between tokens. This captures relative strength: which token is gaining momentum faster than the others.

6. Power Channel: A nonlinear version of channel following. The weight change is proportional to a power of the channel position, making the strategy more aggressive near the channel boundaries.

Each strategy is encoded as parameters to the temporal function (decay rates, lookback windows, channel widths). The same weight storage and update infrastructure supports all six. What changes is how the "target weight" is calculated from price data.

AMMs as On-Chain Trading Funds

This is the key conceptual shift. In a traditional AMM, LPs passively provide liquidity and earn fees. They have no control over portfolio allocation. In a temporal function AMM, the pool itself is an autonomous trading agent. LPs are effectively investing in a quantitative strategy.

This has profound implications for security. Traditional AMM audits focus on swap math correctness and reentrancy. Temporal function AMM audits must also verify that the strategy implementation is correct, that weight updates cannot be manipulated, and that the guard rail system prevents adversarial weight shifts. Multi-block MEV becomes a concern because an attacker who controls multiple consecutive blocks could manipulate the price feed that drives weight updates.

What You Will Build Next

In the following sections, you will implement the multi-slot weight storage system that packs 4 weights per 256-bit slot for gas efficiency, build the time-based weight update engine with EMA smoothing and block multipliers, construct a multi-asset pool with three levels of guard rails, and finally ship the complete temporal function AMM.