What it is
A TWAP (time-weighted average price) oracle is a way for a smart contract to read an asset's price that smooths out short-term spikes by averaging observed prices over a chosen time window — say, the last 30 minutes or 24 hours — instead of just reading the current instantaneous price. It trades a bit of freshness for a lot of manipulation resistance.
How it works
- A price source (usually an AMM pool, like a Uniswap V3 pool) records a price observation — a cumulative price value — at set checkpoints, often every block or every time a trade happens.
- Each observation stores the cumulative sum of price × time-elapsed since the last observation, building a running ledger of "price-time" rather than just "price."
- To compute a TWAP over a window (e.g., the last hour), a contract reads the cumulative value now and the cumulative value from one hour ago, subtracts them, and divides by the elapsed time — yielding the average price over that interval.
- Because this calculation only depends on two checkpoint reads, it's cheap to compute on-chain and doesn't require replaying every trade in between.
- Any protocol needing a price — a lending market checking collateral value, a derivatives protocol settling a position, a DAO's treasury (as with MetaDAO or Empty Set Dollar) valuing an asset — calls this function instead of reading the pool's live spot price.
- The longer the averaging window, the more expensive and slow it is for an attacker to move the price meaningfully, since they'd need to sustain a manipulated price across the whole window, not just one block.
Why designers use it
- Resists flash-loan and single-block price manipulation: an attacker would need to hold a distorted price for the entire window, which is far costlier than a single large trade.
- Provides a decentralized, on-chain price source without relying on a centralized off-chain price feed or trusted third party.
- Cheap to query on-chain compared to averaging raw historical trade data manually.
Failure modes
- Short-window exploits: a TWAP with too short a window (or on a low-liquidity pool) can still be manipulated by an attacker willing to sustain a distorted price for that shorter period — this has caused real exploits when protocols used minute-scale windows.
- Thin liquidity pools: on low-liquidity pairs, even a modest trade can move price enough that the TWAP itself becomes unreliable, since there's little real trading volume to "average against."
- Stale price during low activity: if a pool sees few trades, the TWAP can lag far behind the real market price, causing incorrect liquidations or mispriced settlements when the market gaps.
- Cross-pool arbitrage lag: during the averaging window, the TWAP can diverge from prices on other venues, creating arbitrage opportunities that indirectly cost protocol users.
What to check before using it
- Is the averaging window long enough, relative to the pool's liquidity depth, to make manipulation economically irrational?
- How deep is the underlying pool's liquidity — would a realistic attacker have enough capital to move and hold the price?
- What happens during periods of low trading activity — does the TWAP go stale, and does your protocol handle that gracefully?
- Have you modeled the cost of a flash-loan or sustained-capital attack against your specific window and pool size?
- Is there a fallback oracle if the TWAP source pool loses liquidity or gets delisted?