Oracle Heartbeat

What Is an Oracle Heartbeat?

An oracle heartbeat is the maximum amount of time that can pass between consecutive price updates from a blockchain oracle. It acts as a safety net: if an asset's price stays within the deviation threshold and no price-triggered update occurs, the heartbeat forces a refresh so that on-chain data never goes completely stale.

The concept is borrowed from system monitoring, where a "heartbeat" signal confirms a service is alive. In the context of oracle networks, the heartbeat confirms that the price feed is still active and reflecting current market conditions, even during periods of low volatility.

Heartbeat intervals vary by asset pair and by chain. On Ethereum mainnet, Chainlink's ETH/USD and BTC/USD feeds use a 3,600-second (one-hour) heartbeat, while less liquid pairs such as FXS/USD or AMPL/USD may use heartbeats of up to 86,400 seconds (24 hours). On faster chains like Polygon, heartbeats can be much shorter because lower gas costs make frequent updates economical.

How It Works

Oracle price feeds that use a push-based model rely on two complementary triggers to decide when to post a new price on-chain:

1. Deviation threshold: if the off-chain price moves by more than a set percentage from the last on-chain value, nodes push an update immediately. For ETH/USD on Ethereum mainnet, this threshold is 0.5%.
2. Heartbeat interval: if no deviation-triggered update has occurred within the heartbeat window, nodes push an update regardless of whether the price has changed. For ETH/USD on Ethereum mainnet, this interval is 3,600 seconds (one hour).

The two triggers are evaluated independently: whichever fires first initiates a new aggregation round. Oracle nodes collect their individual price observations, reach consensus through the aggregation contract, and post the result on-chain with a timestamp.

The Update Cycle

Consider an ETH/USD feed with a 0.5% deviation threshold and a one-hour heartbeat:

• If ETH moves from $2,000 to $2,015 (a 0.75% change) within 10 minutes, the deviation threshold triggers an update at minute 10. The heartbeat timer resets.
• If ETH stays at $2,015 for the next 60 minutes without moving more than 0.5%, the heartbeat triggers a fresh update at minute 70, confirming the price is still $2,015.
• If ETH then drops from $2,015 to $2,005 (a 0.5% move), the deviation threshold fires again and the heartbeat resets once more.

This dual-trigger design balances freshness against cost: deviation triggers capture significant price moves quickly, while heartbeats ensure the feed never goes silent during calm markets.

Checking for Staleness

Smart contracts consuming oracle data should verify that the price is fresh. Chainlink's latestRoundData() function returns an updatedAt timestamp alongside the price. Protocols compare this timestamp against the feed's heartbeat to detect stale data:

(
  uint80 roundId,
  int256 answer,
  ,
  uint256 updatedAt,
  uint80 answeredInRound
) = priceFeed.latestRoundData();

require(answer > 0, "Invalid price");
require(updatedAt > 0, "Round not complete");
require(
  block.timestamp - updatedAt < HEARTBEAT + BUFFER,
  "Stale price"
);

The HEARTBEAT constant should match the specific feed's configured interval, and the BUFFER accounts for minor network delays. A common mistake is hardcoding a single staleness threshold across all feeds: a three-hour timeout works for an ETH/USD feed with a one-hour heartbeat but will incorrectly reject a stablecoin feed whose heartbeat is 24 hours.

Parameters by Asset Class

Heartbeat intervals and deviation thresholds are tuned per asset pair based on the asset's volatility profile and the consuming protocols' requirements:

These parameters are not immutable. Oracle operators can adjust heartbeats and deviation thresholds in response to changing market conditions or protocol requirements. For example, in mid-2025, Inverse Finance's risk working group reduced the deviation threshold for USR/USD from 1.0% to 0.5% to better support high-leverage stablecoin markets.

Why It Matters for DeFi

DeFi protocols that lend, borrow, or trade against collateral rely on oracle prices to trigger liquidations, calculate health factors, and determine position values. When prices go stale, multiple risks emerge.

Under-liquidation occurs when the on-chain price remains artificially high while the real market price has dropped. Borrowers whose collateral should be liquidated continue to hold their positions, accumulating bad debt for the protocol. Over-liquidation is the reverse: a stale low price triggers unnecessary liquidations, unfairly penalizing users whose collateral is actually worth more.

Oracle manipulation becomes easier when heartbeats are long, because an attacker has a wider window during which the on-chain price diverges from the true market price. This divergence can be exploited through oracle extractable value strategies: traders who see the real price before the oracle updates can front-run the update for risk-free profit.

For a deeper look at how real-time attestations address some of these freshness challenges, see the research on stablecoin real-time attestation with Chainlink.

Use Cases

Lending and Borrowing Protocols

Lending protocols such as Aave and Compound use oracle heartbeats to determine when to mark a price as stale and pause affected markets. Without heartbeat-aware staleness checks, a frozen price feed could allow borrowers to take out undercollateralized loans or prevent healthy positions from being liquidated in time.

Stablecoin Collateral Valuation

Stablecoin protocols that accept volatile collateral (like ETH or BTC) need timely price updates to maintain their peg. A stale oracle during a market crash could delay collateral auctions and lead to a liquidation cascade once the feed finally updates with a much lower price.

Perpetual Futures and Derivatives

On-chain perpetual futures platforms use oracle prices for funding rate calculations and position mark-to-market. A heartbeat gap during a volatile move can result in incorrect funding payments or delayed liquidations, creating bad debt in the insurance fund.

Cross-Chain Price Feeds

When oracle data is relayed across chains, heartbeat freshness becomes even more critical. The relay itself introduces additional latency, so the consuming protocol on the destination chain should account for both the source feed's heartbeat and the bridge's relay delay when setting its staleness threshold.

Risks and Considerations

Gas Cost Tradeoff

Shorter heartbeats mean more frequent on-chain transactions and higher cumulative gas costs. On Ethereum mainnet, each oracle update requires a transaction from the aggregator contract, and with dozens of feeds running simultaneously, the gas bill for oracle operators is substantial. This cost ultimately flows to protocols and users through oracle subscription fees or data access costs.

Longer heartbeats reduce costs but widen the window for stale-price exploits. Protocol designers must evaluate the tradeoff based on their specific risk tolerance: a lending protocol with aggressive liquidation thresholds needs tighter heartbeats than a less time-sensitive governance price reference.

Heartbeat Mismatch Bugs

A common integration mistake is using a single hardcoded staleness threshold for all price feeds. If a protocol sets a three-hour staleness limit but consumes a stablecoin feed with a 24-hour heartbeat, the protocol will reject perfectly valid price data and potentially halt operations. Conversely, using a 24-hour threshold for a major crypto feed with a one-hour heartbeat means the protocol could operate on data that is many hours old without flagging it.

Each feed should be configured with a staleness threshold that matches its specific heartbeat interval, plus a small buffer to account for network congestion or delayed aggregation rounds.

L2 Sequencer Dependency

On Layer 2 networks, oracle heartbeats interact with sequencer uptime. If the L2 sequencer goes down, no oracle updates can be posted, and the heartbeat effectively pauses. When the sequencer comes back online, protocols need a grace period before trusting oracle prices: acting immediately on a potentially stale price could trigger incorrect liquidations. Chainlink provides a dedicated Sequencer Uptime Feed for this purpose.

Network Congestion

During extreme gas price spikes on Ethereum mainnet, oracle update transactions may be delayed as they compete for block space. If congestion pushes the actual update interval beyond the heartbeat window, protocols with tight staleness thresholds may temporarily lose access to price data. This is especially risky during market crashes, when both gas prices and the need for fresh oracle data peak simultaneously.

Pull vs. Push Feeds

The heartbeat model applies specifically to push-based oracles, where nodes proactively post updates on-chain. Newer pull-based oracle designs (such as Chainlink Data Streams or Pyth) shift the update responsibility to the consuming protocol, which fetches and posts the latest price on-demand. Pull-based feeds avoid the heartbeat tradeoff entirely but introduce their own challenges around data freshness guarantees and transaction ordering.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.