TWAP (Time-Weighted Average Price)

A TWAP oracle reports the average price of a token over a defined time window, not the latest trade. It exists to resist single-block manipulation. An attacker can flash-loan a large swap and move the spot price for one block, but the oracle averages across many blocks of trades, so the manipulated print barely moves the window's mean. Windows typically run 5 minutes to an hour.

The canonical implementation lives in Uniswap V3. The pool stores a running tick accumulator on every swap; a consumer contract reads the accumulator at two timestamps, subtracts, divides by elapsed time, and recovers the time-weighted geometric mean over the chosen window. Longer windows are harder to manipulate and slower to react. Lenders pick the window by trading those two off. Volatile collateral usually warrants shorter windows so liquidation isn't delayed past the point where collateral still covers the debt.

After the 2020 oracle-manipulation attacks, TWAP became the standard methodology. Lending protocols had been losing capital to flash-loan-driven moves on spot-price oracles. TWAPs solved the single-block problem by construction. They didn't solve the thin-liquidity problem: if an attacker can hold the price off-true for the full window with modest capital sustained over time, the average the contract reads is still wrong. Depth caps how cheaply the attack can be sustained.

Don't confuse the TWAP oracle with the trader's TWAP execution algorithm, which splits a large order into equal slices over a window to minimize market impact. Same name, different problem. The oracle reads price; the algorithm submits orders.

At Rekord, TWAP serves as a fallback only where a rated Chainlink feed isn't available. Institutional pledged collateral runs on multi-source price oracles with continuous deviation checks.