Price Feeds

How a Chainlink price feed round works

A Chainlink Data Feed runs on a committee of 11-31 independent oracle nodes that have staked LINK as collateral. The round-based Off-Chain Reporting (OCR 2.0) protocol proceeds as follows: Each node independently fetches the current price from its assigned data sources (typically Binance, Coinbase, Kraken, and 3-5 others). The node drops the highest and lowest values, takes the median of the remainder, and signs that value with its BLS private key. Nodes then exchange their signed values over a peer-to-peer network until a threshold of signatures is collected on the same value. One designated node submits the aggregate - the median price plus the BLS-threshold signature bundle - in a single on-chain transaction to the Aggregator contract. The contract verifies the aggregated signature against the known public keys of the node set; if the threshold is met, the price is accepted. This design reduces gas cost by ~90% versus each node submitting individually, while preserving byzantine fault tolerance: up to floor((n-1)/3) nodes can be faulty or malicious without affecting the output.

A new round fires when either the deviation threshold is crossed (e.g., the off-chain median differs from the last on-chain answer by more than 0.5%) or the heartbeat timer expires (e.g., 1 hour for ETH/USD on mainnet). The deviation trigger ensures the on-chain price tracks the market during volatile periods; the heartbeat ensures a price update arrives even during calm markets and serves as an anti-censorship mechanism. Consumer protocols must implement their own staleness checks - calling latestAnswer() and comparing updatedAt against the feed's configured heartbeat, and reverting if the price is stale. This is where most oracle-related hacks originate: a protocol that fails to check staleness can trade on a price that hasn't updated in hours, creating arbitrage opportunities against protocols that do check.

Key concepts

OCR 2.0 and BLS threshold signatures

OCR 2.0 replaced the older "every node submits on-chain" model with a peer-to-peer aggregation round. Each node produces a signed observation using a BLS private key; when enough nodes sign the same value (or values within the deviation threshold), one node submits the aggregate bundle on-chain. The Aggregator contract verifies the BLS threshold signature using the known public key of the oracle committee - this means any party can mathematically confirm that at least a supermajority of nodes agreed on the price, without needing to trust any single node. The BLS scheme also allows signature aggregation: 31 individual ECDSA signatures take far more gas than one aggregated BLS threshold signature.

Deviation threshold vs heartbeat

The two-trigger model is the economic governor of the oracle feed. A 0.5% deviation threshold for ETH/USD means an update only fires when the market moves by half a percent from the last on-chain price - which might be once per hour in calm markets and dozens of times per hour during a flash crash. The heartbeat (commonly 1 hour for majors, 24 hours for stablecoins) fires regardless of price movement, guaranteeing maximum staleness and acting as an anti-censorship floor. The combination means feeds are efficient (no idle gas on quiet days) and live (maximum staleness is bounded by heartbeat regardless of volatility).

Pull oracle: Pyth and the Wormhole attestation layer

Pyth's pull model publishes signed price messages to an off-chain data chain (Solana first, then extended to ~30 chains via Wormhole). Each publisher - typically an institutional market maker - signs its own price observation directly. The on-chain Pyth program verifies the publisher's signature and stores the price. Any consumer can call getPriceNoOlderThan() to get the latest price, paying the verification gas themselves. This creates a market for oracle freshness: if nobody reads the price in a given block, no gas is spent on idle updates. The tradeoff is liveness - if no keeper relays the latest message, the price can go stale.

Uniswap V3 TWAP as a secondary oracle

Uniswap V3's observe() function returns a cumulative tick accumulator. The TWAP over any window is computed by reading the accumulator at two block heights and computing the geometric mean of the price ratio. TWAP is a powerful secondary oracle because it reflects actual tradeable prices with full economic meaning - if BTC/USD TWAP moves 5%, that 5% is real arbitrage pressure from the market. It is commonly used as a circuit breaker against a primary oracle: if the primary oracle's price and the Uniswap TWAP disagree by more than a tolerance (Aave uses ~2%), the protocol pauses borrows. The limitation is that TWAP only exists for pools where someone has actually traded.

Staleness and PriceOracleSentinel

Aave V3's PriceOracleSentinel adds a governance-controlled circuit breaker that pauses liquidations during L2 sequencer downtime. When the sequencer goes down, oracle updates stop arriving, and a naive protocol would continue liquidating borrowers based on stale prices. The sentinel detects this by checking whether the latest update's timestamp is within a grace period, and if not, switches to a degraded mode that only allows repayments (no new borrows or liquidations). MakerDAO's OSM puts a 1-hour delay between a price being published and it being usable by the Spotter contract, giving governance time to freeze a compromised feed.

Data quality: source selection and outlier removal

Chainlink nodes fetch from multiple sources and apply outlier removal before computing the median. The standard approach is to drop the highest and lowest value (trimmed mean variant) or to simply take the median of all values. Source selection is itself a security decision: feeds that source from only CEXs are resistant to DEX-based manipulation but exposed to CEX-level failures; feeds that include Uniswap V3 TWAP reflect actual market execution but can be manipulated by??? provision. The best feeds include a cross-section of CEXs, spot DEXs, and futures markets (CME) to make coordinated manipulation across all sources economically infeasible.

Frequently asked questions

What is the difference between Chainlink's push model and Pyth's pull model?

Chainlink's Data Feeds use a push model: a committee of 11-31 nodes runs Off-Chain Reporting (OCR), aggregating prices off-chain and writing a single aggregated transaction to the on-chain Aggregator. The feed sponsor (or Chainlink SCALE program) pays gas per update, and consumers call latestAnswer() at zero marginal gas cost. Pyth uses a pull model: institutional market makers publish signed price messages to an off-chain data chain (Solana, then Wormhole-attested to other chains), and any consumer relays the latest one to the target chain by paying the verification gas themselves. Pull oracles can achieve sub-second freshness because updates are only paid for when someone reads them - no idle gas is burned on updates nobody uses.

How does TWAP aggregation work in Uniswap V3 and why does window length matter?

Uniswap V3 stores a cumulative tick accumulator that increments by the pool's tick each block. A TWAP is read by calling observe() at two block heights and taking the geometric mean of the price ratio: TWAP = exp((ln(P2) - ln(P1)) / (t2 - t1)). To manipulate the TWAP by n% over a window W, an attacker must keep the pool mispriced by roughly n% (W / block_time). A 30-minute TWAP on Ethereum means ~900 blocks at 2-second block time, so moving the TWAP by 5% requires sustaining a 5% dislocation for 900 blocks while absorbing arb pressure every block. The cost scales linearly with window - doubling the window doubles the manipulation cost.

What is RIPOE (Range-based Input / Proof-based Output Execution)?

RIPOE is a price validation pattern used by protocols like Aave V3 and Compound V3 to handle stale oracle data. Instead of accepting a single answer, the protocol defines an acceptable price range (e.g., +/-2% from the last known value). If the oracle's new price falls within that range, it's accepted and the protocol updates. If it falls outside, the transaction reverts - preventing liquidations from firing on obviously bad data. The range is governance-controlled and wider for volatile assets, tighter for stablecoins. This is different from a pure staleness check (which only checks updatedAt) because it also bounds how far the price can jump in a single update.

Why do high-frequency trading protocols prefer Pyth over Chainlink?

Pyth's pull architecture delivers sub-second price updates for sub-second latency strategies. A market maker on GMX or a perp protocol needs the mark price to track the index within a fraction of a second - otherwise an arbitrageur can trade the spread before the liquidator. Pyth achieves this by having the publisher (an institutional market maker like Alameda or Jump) push a signed price to the Solana chain in real time; Wormhole relays it to destination chains in under a second. Chainlink's OCR push model is more secure and cost-efficient for low-frequency reads (lending liquidations, CDPs) but the heartbeat interval (often 1 hour) and deviation threshold model means prices are refreshed less frequently at the tail. The tradeoff: Pyth is faster but shifts liveness to the consumer's keeper; Chainlink is slower but guarantees freshness via heartbeat.

How does multi-source aggregation prevent oracle manipulation?

When an oracle aggregates from N independent sources (e.g., Binance, Coinbase, Kraken, CME, LMAX for ETH/USD), an attacker must move all N prices simultaneously to shift the aggregate. This is structurally harder than moving a single source because: (1) institutional sources have deeper order books and higher arb resilience; (2) the median of N values is resistant to outliers - if 4 of 5 sources report $3,200 and one reports $3,500 due to manipulation, the median is $3,200; (3) geospread nodes across different regions resist coordinated geographic manipulation. Chainlink's OCR additionally requires a BLS-threshold signature from a supermajority of the node set before accepting an update, so no single node or small colluding subset can inject a bad value.

What are the economic implications of the deviation threshold / heartbeat model?

The two-trigger model (deviation threshold OR heartbeat expiry) creates an economic bound on oracle gas costs. For ETH/USD on Ethereum mainnet, a ~0.5% deviation threshold and 1-hour heartbeat means the feed updates at most once per hour on a stable day and up to dozens of times per hour during volatile markets. Stablecoin feeds tighten deviation to 0.25% but extend heartbeat to 24 hours because they almost never drift - this saves enormous gas on a high-frequency chain. The tradeoff is that long-tail assets with low liquidity or low volatility often lack a funded feed because the LINK subsidy per feed is the actual gate on decentralization. This is why many long-tail assets still run on a single centralized data provider or a small-node-set feed - the market for fully decentralized long-tail feeds hasn't economically materialized.