Seven posts in. Uniswap V2 Wrapped Up. The final one. This one is about TWAP oracles, something we've mentioned in passing in basically every post in this series without fully explaining. The price accumulators that _update() quietly increments on every pool interaction. The mechanism that a significant portion of DeFi relies on for price data without most users ever knowing it's there.
This post is a bit different from the flow posts. There's no user-facing operation to walk through, no Router function signature to open with. It's more of an infrastructure post — explaining a system that runs underneath everything else, what problem it's solving, how it solves it, and why the solution is elegant enough to be worth understanding properly. It also has a villain, which helps.
The problem: on-chain price data is hard to trust
Lots of DeFi protocols need to know what something is worth. A lending protocol needs to know the value of your collateral to decide how much you can borrow against it. A stablecoin needs to know the price of its underlying assets to maintain its peg. A derivatives protocol needs a price feed to settle positions. The list goes on.
The naive approach: just read the current ratio of a Uniswap pool. The pool holds ETH and USDC, so reserveUSDC / reserveETH is the current ETH price. Simple, on-chain, always available.
The problem is that this number can be moved. Temporarily, but significantly, and within a single transaction. And if a protocol uses it as a price feed, that movability is an attack surface.
The attack: how a flash loan breaks a spot price oracle
Here's the scenario. A lending protocol uses the Uniswap ETH/USDC spot price to determine how much a user can borrow against their ETH collateral. An attacker wants to borrow more than their collateral is actually worth.
They take a flash loan for a large amount of USDC. They dump it all into the ETH/USDC pool in a single transaction. The constant product formula means this massive USDC injection drives ETH's price on the pool way up — the pool now shows ETH at, say, $10,000 instead of $3,000 because the USDC reserve ballooned and the ETH reserve shrank. The attacker immediately goes to the lending protocol, which reads the Uniswap spot price, sees ETH at $10,000, and lets the attacker borrow against their ETH at that inflated value. The attacker takes the loan, repays the flash loan, and the pool's price snaps back to $3,000. The lending protocol is now holding undercollateralised debt. The attacker has the difference.
The entire attack fits in one transaction. The flash loan is repaid. The spot price manipulation is undone. But the loan from the lending protocol persists, because that was a separate state change and it doesn't revert just because the flash loan did.
This is the flash loan oracle attack, and it was not theoretical. It happened, multiple times, to real protocols, for real money, in the early days of DeFi. The spot price is simply not safe to use as a price feed in any context where it can be profitably manipulated within a single transaction.
The solution: time-weighted average price
Uniswap V2 introduced TWAP — Time Weighted Average Price — as a built-in feature of every pair contract. We've seen _update() doing something with price accumulators in every flow post. Here's what it's actually doing.
Every time _update() is called, before it updates the reserves, it does this:
price0CumulativeLast += reserve1 / reserve0 * timeElapsed
price1CumulativeLast += reserve0 / reserve1 * timeElapsed
It takes the current spot price (the ratio of the reserves before this update) and multiplies it by how many seconds have elapsed since the last update. That product gets added to a running cumulative total. The result is a number that represents the sum of every price-times-time the pool has ever seen, continuously accumulating since the pool was created.
On its own, this number is meaningless. The useful thing is the difference between two snapshots of it, divided by the time between them. That's the time-weighted average price over that period.
Say you snapshot price0CumulativeLast at time T1, and again at time T2. The TWAP for that window is:
This is the average price of token0 in terms of token1, weighted by how long the price stayed at each level during that window. A price that held for an hour contributes 3600x more to the average than a price that held for one second.
Now think about the flash loan attack in this context. The attacker manipulates the spot price within a single transaction, which means within a single block, which means for at most a few seconds of block time. But the TWAP is averaging over whatever window the consuming protocol chose — typically 30 minutes, an hour, or longer. A price spike that lasted a few seconds barely moves a 30-minute average. To meaningfully manipulate a TWAP, an attacker would need to hold the spot price at a manipulated level for a significant fraction of the averaging window. That means holding a large, expensive position across multiple blocks, paying fees on every swap that moves the price, and watching the market push back against them with every passing block as arbitrageurs correct the imbalance. The attack goes from cheap and atomic to expensive, sustained, and probably unprofitable.
This is why it's time-weighted. The time weighting is what makes manipulation costly rather than free.
A few things worth knowing about how TWAP is actually used
Uniswap V2 pairs store the accumulators but don't compute averages themselves. The computation is left to whoever is consuming the price data — an external oracle contract that snapshots the accumulator at two points in time and does the division. The UniswapV2OracleLibrary provides helpers for this, and the periphery repo ships example implementations. But the design is intentionally minimal: the pair just accumulates, and the interpretation layer is built on top.
The window length is a design choice made by the consuming protocol. Shorter windows are more responsive to real price movements but more vulnerable to manipulation. Longer windows are more resistant to manipulation but slower to reflect genuine market changes. Most protocols settle somewhere between 30 minutes and a few hours depending on their risk tolerance and the volatility of the asset.
TWAP is everywhere, but nothing blindly trusts it
Uniswap TWAP became one of the most widely used on-chain price sources in DeFi. MakerDAO used it. Compound referenced it. Dozens of smaller protocols built their entire price logic on top of it. For a long time, if you wanted a decentralised, manipulation-resistant, on-chain price feed that didn't require trusting any external party, Uniswap TWAP was essentially the answer.
It's still used extensively. But the space has also developed alternatives, and most serious protocols now run multiple price feeds rather than relying on any single source.
Chainlink is the dominant off-chain oracle network — a decentralised network of node operators that aggregates price data from multiple sources off-chain and posts it on-chain at regular intervals. It's highly reliable and covers a wide range of assets, but it introduces trust in the Chainlink network and has update latency. Pyth Network takes a similar approach but with a focus on high-frequency financial data, pulling from institutional sources and updating more frequently. RedStone is a newer entrant with a different architecture — data is delivered on-demand and verified on-chain rather than continuously pushed, which reduces gas costs significantly.
Most mature protocols treat these as complementary rather than competing. A typical setup might use a Chainlink feed as the primary source, cross-reference against a Uniswap TWAP as a sanity check, and have logic that pauses operations if the two diverge beyond a threshold. This is sometimes called a circuit breaker. The idea is simple: if your two independent price sources suddenly disagree by 20%, something unusual is happening — either one feed is being manipulated, or there's a genuine market event — and the safest response is to stop accepting new positions until things stabilise rather than continue operating on potentially bad data.
Some protocols also implement price deviation limits, where a single update that moves the price more than some percentage in one block is rejected outright. Others use time delays on price updates, where a price change only takes effect after a minimum delay, giving the system time to detect anomalies before they affect operations.
None of this is foolproof. The history of DeFi oracle exploits is long and ongoing, and we'll probably cover it properly in a dedicated post at some point because it deserves the full treatment. The general direction of the space is toward defence in depth: multiple independent sources, sanity checks between them, automated circuit breakers, and the humility to acknowledge that no single mechanism is enough on its own.
And that's Uniswap V2
Seven posts. Constant product formula, architecture, mint, swap, burn, flash loans, TWAP oracles. If you've read the whole series, you've essentially read the Uniswap V2 codebase — not line by line, but in the way that actually matters. You understand what every major component is doing, why the design decisions were made, and how the pieces fit together.
The protocol that looked like two repos and some scary math turns out to be one invariant, a handful of contracts, and a lot of elegant engineering around keeping that invariant honest. Hopefully it feels that way now.
There's more to cover in this space: V3's concentrated liquidity is a genuinely different and more complex model, the oracle exploit history is worth a proper post, the composability story from 2020 has more threads to pull, and deterministic contract deployment probably deserves its own writeup as promised. We'll get there.
Thanks for following along.
Top comments (0)