Stale Oracle Price Explained in Detail
An oracle can keep returning a value after it stops updating. That value may be validly encoded but unsafe for current decisions.
For Chainlink-style feeds, updatedAt is the key timestamp auditors check.
Smart contract example
require(block.timestamp - updatedAt <= maxStaleness, "stale");
The max staleness should match the asset and protocol risk.
Stale Oracle Price in Auditing
Stale prices can trigger bad liquidations, undercollateralized borrowing, incorrect minting, or blocked withdrawals. The code may look safe because it read an oracle, but the value can be outdated.
Auditors test oracle failure and delayed-update paths.
Red flags in code
-
No
updatedAtor freshness check. -
updatedAt == 0is accepted. -
Fallback price can remain active indefinitely.
-
L2 sequencer downtime is ignored.
-
Sensitive actions continue when the feed reverts or stops updating.
How to test or review it
-
Mock old timestamps and expect sensitive actions to revert or pause.
-
Test zero timestamp, reverted feed, and unchanged price during volatile conditions.
-
Check fallback activation and expiry.
-
Verify governance can update stale feed configs safely.
-
Review liquidation and borrowing behavior under stale data.
Keep learning this topic
Chainlink Oracle
A Chainlink oracle integration reads price or rate data from Chainlink Data Feeds, usually through AggregatorV3Interface.
Oracle Manipulation
Oracle manipulation occurs when an attacker distorts a data source that a smart contract trusts, causing the contract to make decisions from unsafe data.
Liquidation
Liquidation is a protocol action that repays or closes an undercollateralized borrow position and transfers collateral according to the protocol's rules.
Practice this in real audit scenarios
Definitions help, but auditors need reps. SCH turns concepts like Stale Oracle Price into exploit labs, code review habits, and report-writing practice.
Start the free trial or see the full smart contract auditing course.