Skip to content
Financial Context Wiki

How to choose a TWAP window

Choose a TWAP lookback by testing manipulation cost, market depth, price lag, observation availability, and the protocol's value at risk rather than relying on a universal duration.

Updated

For educational purposes only; not investment or security advice. A poorly designed price oracle can cause wrongful liquidations, undercollateralized borrowing, and protocol losses.

Direct answer

There is no universally safe TWAP window. Choose the shortest window that still makes a profitable manipulation implausible for the specific pool and protocol, then confirm that its lag remains acceptable during a real price move. A longer window usually forces an attacker to influence the market for more time, but it also keeps old prices in the average for longer. It cannot compensate for thin liquidity, concentrated liquidity outside the relevant price path, excessive value at risk, or a flawed integration.

Treat window selection as a risk-budget exercise, not as a choice among defaults such as 5 minutes, 30 minutes, or 1 hour. The protocol should document the source pool and averaging method, maximum acceptable price error and response delay, economically extractable value, modeled attack cost, available observation history, and fallback behavior. Re-run the analysis when liquidity, incentives, block production, collateral caps, or market structure changes.

How it works

An accumulator-based oracle records price over time. For an arithmetic accumulator, the average over the interval from t1 to t2 is:

TWAP(t1,t2) = (cumulativePrice(t2) - cumulativePrice(t1)) / (t2 - t1)

Uniswap v2 accumulates a price measured at the beginning of each block and lets an external consumer checkpoint two accumulator values. Uniswap v3 stores observations of cumulative ticks and therefore returns a time-weighted geometric mean price after converting the mean tick. The averaging convention, quote direction, observation capacity, rounding, and update behavior are part of the oracle specification; integrations must not assume every TWAP is an arithmetic average of sampled spot prices.

Use this selection process:

  1. Define the consumer’s loss function. Record how the price changes borrowing power, liquidation, minting, redemption, or settlement. Set the maximum tolerable delay and error for both rising and falling markets.
  2. Measure executable liquidity. Model reserves, fees, and active in-range liquidity across the entire price path an attacker would have to traverse. TVL and recent volume alone do not establish manipulation resistance.
  3. Bound the attacker’s payoff. Include collateral caps, borrow caps, liquidation bonuses, positions already open, composability with other protocols, and any profit available before a pause. The security margin should compare attack cost with total extractable value, not with one user’s trade.
  4. Model feasible attacks. Test one-block and multi-block distortion, flash-sourced capital, proposer control or ordering advantages, arbitrage and back-running, congestion, and the cost of unwinding. Published research shows that simple assumptions of attack cost growing linearly with the window can fail under stronger attacker models.
  5. Sweep candidate windows. For each duration, simulate historical jumps and adversarial price paths. Reject windows that either permit profitable manipulation or leave the protocol using an unacceptable stale value.
  6. Add independent controls. Use exposure caps, deviation or sanity checks against an independent reference, staleness limits, conservative collateral factors, and a tested pause or fallback policy. These controls do not make an unsafe source safe, but they can limit loss when assumptions break.

The result is specific to a pool, fee tier, chain, oracle implementation, asset pair, and protocol state. Copying another protocol’s 30-minute window copies none of its liquidity or loss limits.

Example

Assume a simplified arithmetic TWAP and a market price that moves instantly from 100 to 70, then stays at 70. A trailing 30-minute window observed 15 minutes after the move contains 15 minutes at each price:

(15 x 100 + 15 x 70) / 30 = 85

After 30 minutes, the old 100 observations have fully left the window and the TWAP reaches 70. A 5-minute window reaches 70 after 5 minutes, but an attacker also needs to sustain distortion for a shorter period. For a lending market, valuing collateral near 85 while the executable market is near 70 can delay liquidation and create bad debt; for another use case, a slower value may be acceptable.

This example isolates lag. It does not estimate manipulation cost, and the 85 result does not apply to a geometric-mean oracle. A real review must replay the exact oracle math against pool observations, active liquidity, fees, block sequence, and the protocol’s positions.

Risks and controls

  • Window too short: a small number of distorted blocks can move the result enough to make an exploit profitable. Increase manipulation resistance, improve the source market, reduce exposed value, or use a better diversified reference.
  • Window too long: the oracle can materially lag a genuine jump, delaying liquidations on a fall or undervaluing collateral on a rise. Measure worst-case lag and set conservative risk parameters.
  • Liquidity mismeasurement: headline TVL may be inactive, narrowly concentrated, one-sided, or absent along the attack path. Use executable depth and active liquidity at relevant ticks and prices.
  • Observation failure: insufficient history, stale observations, uninitialized capacity, incorrect timestamps, or a wrong pool and quote direction can invalidate the calculation. Revert or enter a documented safe state instead of silently using a substitute.
  • Attacker-model failure: flash liquidity, multi-block proposer influence, transaction ordering, and cross-protocol profit can lower net attack cost. Stress assumptions rather than treating fees times minutes as a proof.
  • Governance and market drift: a window that passed testing can become unsafe after liquidity migration, fee-tier changes, new collateral listings, higher caps, upgrades, or chain changes. Monitor inputs and require review thresholds.
  • Fallback failure: an independent feed may have different market coverage, decimals, latency, or failure modes. Specify exactly when to pause, reject, cap, or switch, and test that path on-chain.

Before deployment, publish the units, quote direction, averaging method, window, minimum usable history, source-pool criteria, risk caps, and failure behavior. Monitor both the TWAP-to-reference deviation and the economic inputs used in the original attack-cost model.

Common misconceptions

  • “A longer window is always safer.” It may raise the duration of an attack, but it also increases lag and does not repair weak liquidity or an incomplete attacker model.
  • “A 30-minute TWAP is an industry guarantee.” A duration is only one parameter. Security depends on pool depth, active liquidity, fees, block production, oracle math, and value at risk.
  • “Flash loans cannot affect a TWAP.” They remove capital constraints within a transaction; whether an attack succeeds depends on the oracle’s sampling and the attacker’s ability to influence enough of the window or exploit surrounding protocol logic.
  • “High TVL means high manipulation cost.” Only liquidity that is executable along the relevant price path contributes directly to resisting the modeled trade.
  • “TWAP is the current market price.” It is an average of historical on-chain states from a particular market, so it is intentionally lagging and may not represent the broader market.

Sources

Navigation

Search the wiki...