Data Availability

How oracle data gets published on-chain

Oracle data publication is a two-phase process: off-chain aggregation followed by on-chain write. In Chainlink's OCR protocol, oracle nodes independently fetch prices from their data sources, compute a local median, sign it with a BLS private key, and exchange signed values over a peer-to-peer network until a threshold signature bundle is collected. One designated node submits the aggregate transaction to the on-chain Aggregator contract - this is the only on-chain transaction per round, which is why OCR reduces gas cost by ~90% versus per-node submissions. The Aggregator verifies the BLS threshold signature against the known public keys of the node set, and if the threshold is met, accepts the price. The key data availability property here is: the on-chain price is only written if a supermajority of nodes agreed on the same value, meaning the price is as reliable as the most trusted node in the set.

Pyth's model is different: publishers (institutional market makers) sign price observations directly and publish them to an off-chain data chain (Solana). Any consumer on any connected chain can relay the latest signed message by paying the verification gas. The data availability guarantee comes from Wormhole's guardian set: the message is only considered final when 2/3 of the Wormhole guardians have attested to it. This means Pyth data availability is tied to Wormhole's guardian liveness, not to a single chain's sequencer. The tradeoff is that if Wormhole guardians go offline, no new messages can be relayed - but this is a much more robust liveness guarantee than a single chain's sequencer, which has failed multiple times in 2023-2024.

Key concepts

Staleness and the updatedAt check

Every Chainlink Aggregator exposes updatedAt - the unix timestamp of the last accepted price. Consumer protocols are expected to call latestRoundData(), extract updatedAt, and compare it to the feed's configured heartbeat. If updatedAt is older than heartbeat, the protocol should revert (not use a stale price). The November 2022 Chainlink pause demonstrated what happens when protocols don't check this: they continued operating on a price that hadn't updated in 45 minutes during a fast market. The standard implementation is: require updatedAt > (block.timestamp - heartbeat), or revert. Aave V3's PriceOracleSentinel extends this with a grace period - if the latest update is older than the grace period, the protocol pauses borrows and liquidations (not just individual reads).

Fallback oracle chain

Production lending protocols implement a tiered fallback: (1) Primary oracle - Chainlink push feed; (2) Sanity check - Uniswap V3 TWAP, if primary price diverges from TWAP by more than tolerance (e.g., 2%), pause; (3) Time-delayed history - if both primary and TWAP fail, use Chainlink's 8-hour-old history (available via the historical rounds mapping); (4) Governance pause - always available as final resort. The fallback chain matters because an oracle outage rarely affects just one data source: if the chain itself is down (L2 sequencer), Chainlink nodes can't submit updates AND TWAP can't be read (no new blocks). The time-delayed history is the fallback that works even during chain-level outages.

Sequencer liveness and PriceOracleSentinel

Aave V3 on Arbitrum and Optimism implements a PriceOracleSentinel that detects L2 sequencer outages and pauses DeFi activity. When the sequencer goes down, no new blocks are produced, Chainlink keepers can't submit updates, and the on-chain price becomes stale. The sentinel monitors the timestamp of the latest oracle update: if it is older than a grace period (typically 5 minutes), it switches the protocol to degraded mode - repayments are allowed but new borrows and liquidations are paused. This prevents the scenario where borrowers get liquidated at stale prices during the outage and arb bots clean up the difference. The sentinel's design correctly assumes that the sequencer is a centralized single point of failure that must be handled explicitly.

CCIP commit-then-execute and RMN verification

CCIP's data availability model uses a commit-then-execute pattern: the source chain records the intent to send a message (commit phase), the Risk Management Network (RMN) independently verifies the commitment against the source chain's state (verify phase), and only after RMN approval does the message execute on the destination chain (execute phase). This is fundamentally different from simple bridge designs where the destination chain trusts the source chain's block headers directly. The RMN re-verifies the message commitment - it doesn't just trust that the source chain said the message was committed. If the RMN can't verify (e.g., chain is partitioned), no execution occurs - the default is safe. This eliminates the class of bridge hacks where an attacker creates a phantom message on the destination chain with no corresponding real message on the source chain.

Data availability cost and feed economics

Chainlink feed updates cost $3-$8 in gas on Ethereum mainnet. A volatile feed (ETH/USD) can fire dozens of times per hour during a crash, creating a monthly budget in the thousands of dollars. A stablecoin feed with a 24-hour heartbeat fires once or twice per day, costing ~$20/month. Long-tail assets often lack a funded feed because the LINK subsidy per feed is the gating factor - the protocol or Chainlink Labs has to pay for each update. This is why many DeFi protocols use a single centralized data provider for less-liquid collateral: the economics of a fully decentralized oracle don't pencil out for a $500K TVL market. Pyth and API3 dAPIs address this by shifting costs: publishers pay to publish, consumers pay per read, and long-tail assets become viable because the cost is borne by the consumer rather than a centralized sponsor.

Wormhole guardian set and cross-chain data availability

Pyth's cross-chain data availability is guaranteed by Wormhole's guardian set - 19 validators that must all sign off before a message is considered final and relaying can begin. The guardian set is a security buffer: even if some guardians are down, the remaining validators can still produce attestations (the threshold is 2/3, not unanimous). The key property is that a Pyth price is only available on a destination chain when 2/3 of Wormhole guardians have attested to the source-chain message - this means the price is as available as Wormhole itself, which has maintained >99.9% uptime since 2021. The tradeoff is that Wormhole is a separate security domain from any individual blockchain, so if Wormhole itself has an issue, Pyth prices stop updating everywhere simultaneously.

Frequently asked questions

What is oracle staleness and why does it cause DeFi exploits?

Oracle staleness occurs when the on-chain price hasn't been updated for longer than the feed's configured heartbeat. If the Chainlink ETH/USD feed has a 1-hour heartbeat and the last update was 90 minutes ago, the price is stale. Consumer protocols that don't check updatedAt can read a price that is 90 minutes old, which may be dramatically wrong during a fast market. When Binance paused withdrawals during the August 2024 market spike, protocols that trusted a stale Chainlink feed saw prices that didn't reflect the actual market crash - liquidations fired at prices that didn't exist, and arbitrageurs cleaned up the difference. The fix is a staleness check that reverts if updatedAt is older than the configured heartbeat, combined with a PriceOracleSentinel that pauses liquidations during sequencer downtime.

How does a fallback oracle work when the primary feed fails?

A robust protocol implements a fallback chain: primary oracle (e.g., Chainlink ETH/USD) -> Uniswap V3 TWAP sanity check -> time-delayed Chainlink history (8 hours old) -> governance pause. If the primary oracle's price and the TWAP disagree by more than a tolerance (Aave V3 uses ~2%), the protocol pauses borrows and liquidations until governance can investigate. The fallback chain is not just technical insurance - it is the actual attack surface for sophisticated exploits: an attacker who can temporarily break the primary oracle (e.g., by congesting the L2 sequencer so Chainlink keepers can't submit updates) can trigger the fallback and trade on the degraded price. MakerDAO's OSM addresses this by adding a 1-hour delay to every price write, so even a temporarily compromised oracle gives governance time to respond before bad prices affect collateral ratios.

What is the economic model for oracle data availability?

Chainlink feeds are paid in LINK by the feed sponsor - historically Chainlink Labs subsidized the major feeds, now increasingly protocol-controlled via the SCALE/BUILD programs on L2s. The per-update gas cost on mainnet for a Chainlink feed update is roughly $3-$8 depending on gas prices, and a volatile-asset feed (ETH/USD) can fire dozens of times per hour during a market crash, creating a substantial monthly budget. Stablecoin feeds with 24-hour heartbeats fire once or twice per day, costing roughly $10-$20/month in gas. Long-tail assets often lack a funded feed because the LINK subsidy per feed is the gating factor - this is why many DeFi protocols use a single centralized data provider for less-liquid collateral, accepting the manipulation risk as a known tradeoff. Pyth and API3's dAPIs shift this model: publishers/contracts pay for data, consumers pay per read via a relay.

How does the Risk Management Network (RMN) verify data availability for CCIP?

The RMN is a parallel DON that reviews every cross-chain message before CCIP executes it. Unlike a simple bridge that trusts the source chain's block headers, the RMN independently verifies: (1) the message commitment matches what was committed on the source chain (prevents message fabrication); (2) token amounts are within configured limits (prevents draining a vault in one message); (3) the destination chain is not in a slasherectable state (prevents execution on a chain under attack). This independent verification layer is what makes CCIP's data availability model more robust than simpler bridges - the RMN doesn't trust the source chain's data directly, it re-verifies it. If the RMN can't reach consensus (e.g., the destination chain is partitioned), no message executes - the default is safe rather than permissive.

What happened in the November 2022 Chainlink ETH/USD outage and what did it teach?

In November 2022, Chainlink's ETH/USD feed on Ethereum paused for approximately 30 minutes during a period of elevated market volatility, stopping Aave and Compound liquidations and affecting any protocol that depended on real-time prices. The pause occurred because the deviation threshold wasn't crossed (the price was moving but not past 0.5%) and the heartbeat interval had not elapsed - the feed was technically working as designed, but the market moved faster than the feed could follow. This demonstrated that the two-trigger model has a failure mode: during a fast market, the heartbeat floor (1 hour) means the price can lag substantially before a new update fires. The fix adopted by leading protocols was to add a secondary price source (Uniswap TWAP) that updates on every trade, so if the primary oracle stalls, the secondary can trigger circuit breakers or pause activity until the primary recovers.

How does the L2 sequencer outage problem affect oracle liveness?

On Optimism and Arbitrum, the sequencer determines transaction ordering and finality. When the sequencer goes down (as happened on Arbitrum in March 2024 and Optimism multiple times), oracle keepers can't submit their periodic updates, and the on-chain price becomes stale. Aave V3's PriceOracleSentinel specifically addresses this: it detects when the latest oracle update's timestamp is older than the configured grace period (e.g., 5 minutes), and if so, switches to degraded mode - repayments are allowed, but new borrows and liquidations are paused. This prevents the worst-case scenario: liquidations firing on stale prices during a period when the market is moving but the oracle can't update. The sentinel's design acknowledges that the sequencer is a centralized component with its own failure modes, and that oracle liveness is only as good as the chain's own liveness.