A smart contract needs an external data feed because it can only read state that earlier transactions parked on-chain. SyncSwap, an Automated Market Maker on top of a zero-knowledge rollup, is a live place to see the consequences of that constraint: dune.com. Every other fact about the world outside the chain has to be carried in by someone else, in a transaction, before any contract can use it.
Most writing about data feeds stops at "oracles bring data on-chain." The useful part is what the route looks like, because the route is where latency comes from. A price feed is not a live quote. It is the result of the most recent update round, written to the feed contract, and read by any contract that wants it. The age of that value is a risk parameter.
What an update round actually involves
Off-chain, a set of independent nodes watches the same exchanges and produces a price for the asset. Each node submits that answer to an on-chain aggregator contract. After enough nodes have responded, the aggregator stores a median. That median is the feed. A consuming contract reads it without talking to any node.
Two rules decide when this happens:a deviation threshold and a heartbeat. The threshold trips when the price has moved a set percentage off the last stored value. The heartbeat trips when a set amount of time has passed. The first makes updates meaningful;the second makes them possible. But both are designed to keep the number of updates low, because every update is a transaction that someone has to pay for.
On Ethereum mainnet that transaction also has to wait for a block — roughly 12 seconds, plus whatever time it spends in the mempool. On a zero-knowledge rollup, the wait is for the sequencer's block, which is normally much shorter. The proof that settles that block arrives later, but a contract reading state on the rollup does not wait for it. The consequence is that the block clock that used to dominate price feed latency on L1 is not the dominant clock anymore. The update policy is.
The alternative to a feed
Uniswap's built-in oracle is the main alternative. Uniswap v3 pools accumulate a cumulative price observation on every swap. A contract can read a time-weighted average over the window it chooses. No outside operators, no update transactions, no trust beyond the pool's arbitrage activity. That makes it useful for settlement prices, where you want the market's judgment over a period, not a single tick.
But TWAP is slow by construction. A long window is the thing that makes it manipulation-resistant;the cost is that the price is an average, not a spot price. If your contract has to act before the pool has time to trade, or the asset has no pool with enough liquidity, you need an external feed. The criteria that decide it are freshness, trust, cost, and coverage.
What decides which one to use
Freshness decides whether a TWAP can work at all. For a liquidation, you need a price as close to spot as possible;a push feed updated by a threshold can be faster than a heartbeat feed, but only if the market is moving. Pyth's pull model cuts the policy delay almost entirely:signed prices exist off-chain, and a user brings one on-chain inthe same transaction that uses it. The latency becomes almost entirely the user's own inclusion time, notthe feed's round. The cost is also the user's: every fresh read is an extra transaction.
Trust differs across the same split. A push feed with nodes aggregating independently spreads trust across operators;a pull feed puts more weight on known publishers and their ability to issue fresh signatures. Both are safer than a single operator, but they aren't the same failure mode.
Consider a stablecoin facing USD. While the peg holds, spot price sits in a tight band. A threshold-based feed rarely updates, because the price isn't moving enough. Your contract is reading a number that might be hours old—and that is fine until it isn't. A depeg doesn't announce itself;the feed updates only after the price has crossed the threshold, by which point your contract has been looking at a stale price for the whole drift. This is not a broken feed;it is the threshold policy doing its job: say nothing when there is no news. If your protocol depends on catching the drift early, you need a heartbeat that forces updates, or pull a fresh price yourself right before you act.
The decision
- External feeds move the latency budget around: threshold and heartbeat make updates durable and cheap; pull feeds make them fresh.
- TWAP removes trust in operators, at the cost of being deliberately slow.
- On a ZK rollup, as of 2026, the cheap L2 transaction has made pull feeds affordable in places where they weren't on mainnet.
Pick the latency budget first;the feed mechanism second.