How DeFi Price Oracles Aggregate and Publish Prices

An oracle is the bridge between information outside a blockchain and code that must run using onchain state. A lending protocol may use an asset-to-currency feed to value collateral, while a derivatives contract may use a reference to settle or test a risk limit. The contract can read the number included in its state; it cannot directly inspect every exchange order book or decide which external market price is fair.

The word “price” hides several different measurements. A feed can describe one asset in a quote currency, a protocol-defined redemption rate, or another specified quantity. It is not automatically the price at which a trader can sell a large position. A pool’s spot ratio and a centralized venue’s last trade can move for different reasons. The DEX swap guide explains why a pool quote and an execution result diverge; mark price versus last price covers another venue-specific distinction.

Oracle systems also differ. A push feed periodically writes an answer to a contract, so consumers can read the latest published value. A pull design may deliver a signed report when a user or application requests it. This guide focuses on common EVM push price feeds and uses Chainlink’s documented interface as an example, not as a claim that every DeFi protocol uses the same provider or update rules.

In Chainlink’s Offchain Reporting design, oracle nodes exchange observations offchain and agree on a report. A quorum signs the report; a transmitter submits it in a transaction; the aggregator verifies the signatures and exposes an answer, round identifier, and timestamp. The documented design exposes a median of the reported observations. This reduces the need to put each individual observation in a separate transaction, while preserving onchain verification of the report’s signatures. See the Offchain Reporting documentation.

The consumer contract does not normally repeat the entire aggregation process. It calls a feed proxy’s latestRoundData() and receives the current round data from the feed. Chainlink recommends using the proxy address for the selected feed; the underlying aggregator can change behind that proxy. The EVM reading guide and API reference show the interface and explain why feed addresses are network-specific.

Aggregation is only one part of data quality. Independent node operators can still depend on overlapping exchanges, data providers, or market conventions. A median can resist an outlying observation when enough valid observations remain, but it cannot manufacture liquidity in a thin market, correct a mislabeled asset, or establish that the chosen source reflects the price a particular protocol needs.

Many push feeds combine a deviation trigger with a heartbeat. A deviation threshold is a configured percentage move from the prior published answer that can trigger another report; a heartbeat is a time-based trigger that can call for an update even when the value has not moved far enough to cross that threshold. The feed directory lists parameters such as asset, network, deviation threshold, and heartbeat for individual feeds: check the current Data Feeds directory and the feed address page for the exact pair and network.

These are feed-specific settings, not a universal “updates every N seconds” promise. If a price moves only a small amount, no deviation-triggered publication may occur until the heartbeat condition is reached. If a volatile move crosses the threshold, publication may be requested sooner, but data collection, report transmission, and block inclusion still involve operational and network steps. A heartbeat describes a trigger rule; it does not guarantee that the market reference never becomes stale or that an update lands at an exact instant.

A threshold also does not tell a protocol how much price movement it can safely tolerate. A lending market with fast-moving collateral may need a stricter age limit or a different risk response than an application that uses a slower-moving reference. A protocol must choose its own acceptable age and behavior rather than treating the feed’s trigger parameters as its safety policy.

latestRoundData() returns roundId, answer, startedAt, updatedAt, and answeredInRound. The API reference marks answeredInRound as deprecated. answer is an integer fixed-point value, not necessarily a human-readable dollar amount. Read the feed’s decimals() and description, then interpret the answer for that exact pair and network. For example, if a hypothetical BTC/USD feed returns 6,725,000,000,000 with 8 feed decimals, the scaled answer is 67,250.00000000 USD per BTC.

Feed decimals and token decimals describe different quantities. An ERC-20 amount may use 18 token decimals, while the price answer has, for example, 8 feed decimals. A contract has to scale each value according to its own unit before multiplying them. Assuming that every feed uses eight decimals, or applying a token’s decimals to the oracle answer, can change the calculated value by many orders of magnitude.

Pair direction matters as much as scale. BTC/USD represents dollars per bitcoin: one BTC multiplied by that answer is a dollar value. USD/BTC would be the inverse unit. For a derived pair, both feeds must be scaled and combined with the correct division order; Chainlink’s price denomination example derives BTC/EUR from BTC/USD and EUR/USD. A protocol should also verify that the selected address, pair, chain, and asset match the intended collateral or liability.

The updatedAt field records the timestamp of the latest round update. A consumer can compare it with the current block timestamp and reject an answer older than an application-defined maximum age. It should also check conditions appropriate to the feed and protocol, such as a nonzero update time, a positive answer for a positive-price asset feed, and expected minimum and maximum values. The allowed range depends on the product; a hard-coded bound can itself become unsafe as markets change.

Consider a hypothetical lending market that accepts four units of a collateral token and applies a 75% collateral factor. The feed has 8 decimals and its last answer is 200,000,000,000, or $2,000 per token. The displayed borrowing ceiling is 4 × $2,000 × 75% = $6,000. Suppose the market has moved to $1,820, a 9% decline, while this illustrative feed has a 10% deviation trigger and a 60-minute heartbeat. Neither assumed trigger has necessarily called for a new report yet. At $1,820, the same formula gives $5,460, so the old answer would overstate this example’s ceiling by $540.

If the application also rejects prices older than five minutes and this round is twenty minutes old, a new borrow can be blocked instead of using the $2,000 answer. That check does not update the feed; it changes what the application permits while data is outside its chosen age limit. A protocol may choose separate responses for borrowing, withdrawals, liquidations, or repayment, because pausing every action can create its own harms. The numbers and trigger settings above are invented to show the interaction, not current feed parameters or recommended risk settings.

On an L2, users often submit transactions through a sequencer. During downtime or recovery, users may be unable to transact normally, transactions may be delayed, and orders can later execute after market conditions have changed. A current-looking L2 oracle answer does not establish that the application’s execution path is healthy or that users had equal access to act on it.

Chainlink documents L2 Sequencer Uptime Feeds as a separate status feed. In its documented interface, answer == 0 means the sequencer is up and answer == 1 means it is down. The startedAt timestamp records the status change; the example consumer checks the status and waits for an application-defined grace period after recovery before using a price feed. The exact uptime-feed address and network behavior must be verified for the L2 in use. See the L2 Sequencer Uptime Feed guide.

The grace period gives users and systems time to resume after an outage; it is not a market-data refresh guarantee. It does not mean every pending transaction has completed, that the price is now accurate, or that an application can safely reopen every action at once. L2s differ in their sequencer, forced-transaction, message-relay, and recovery mechanisms, so a protocol should handle the documented network behavior rather than assume all rollups share one outage path.

A quorum, median, deviation trigger, heartbeat, age limit, and sequencer status check each answer a narrower question. They do not guarantee that source markets are liquid, that observations refer to the correct asset, that data providers are independent, or that the reported median matches the price for a particular trade size. A fresh timestamp can accompany a bad or manipulated value; an old value can remain close to the market during a quiet interval.

No update trigger eliminates market gaps. Prices can move sharply between publications, a feed can be unavailable, a chain can be congested, and a contract can contain a bug in scaling, pair selection, staleness logic, or liquidation rules. Some feeds rely on a single source or provider for a particular datum. Chainlink’s quality and risk guidance tells integrators to evaluate source liquidity and dependencies and to design for stale, delayed, missing, or unexpected values.

Circuit breakers and bounds can limit some actions, but they cannot predict every valid market regime. An overly tight bound can reject a legitimate move; a loose bound may not stop a dangerous one. Oracle safeguards do not remove smart-contract, governance, liquidity, bridge, collateral, or liquidation risk. For stablecoins, an oracle price is also separate from whether a holder can redeem at par; the stablecoin depeg guide explains those additional mechanisms.

For a protocol, identify the exact chain, feed proxy, asset pair, quote currency, answer decimals, and contract address. Compare the feed description with the intended asset; check the currently supported address list instead of copying an address from another network. Review the feed’s source model and the latest observations or update history when the use case requires closer monitoring. Chainlink notes that aggregators can differ across networks and that contract source and configuration should be checked.

Next, follow how the answer is used: convert token amounts and price units correctly; inspect updatedAt; define what counts as too old; and determine whether an invalid answer rejects, pauses, or changes only specific operations. On an L2, find the uptime feed, status interpretation, recovery timestamp, grace period, and behavior for transactions delayed by the sequencer. Test both a stale-feed case and an outage/recovery case against the actual contract logic.

For a user evaluating a lending or trading protocol, read its documentation and deployed contract behavior instead of assuming that a familiar oracle name means every risk is covered. Ask which price drives valuation, borrowing, liquidation, or settlement; what happens when the feed is old or unavailable; and who can alter the risk parameters. The protocol’s exact price path—not a dashboard label by itself—determines how an oracle observation affects an account.