[Sample] What should we verify before changing a price oracle?

SAMPLE CONTENT — Placeholder for reviewing the Security Decisions series. This is a hypothetical example, not an approved protocol recommendation.

The decision

What should we verify before changing a price oracle? Check the feed identity, chain, units, freshness policy, and how every consumer behaves when a price is unavailable or invalid.

When it arises

A protocol switches a collateral price feed or changes its oracle adapter before an upgrade.

Failure path

The replacement feed uses a different decimal scale. The adapter assumes the previous scale. Borrowing and liquidation calculations consume a mis-scaled price and act on incorrect collateral values.

What to verify

Confirm the feed address and supported network. Read its decimals and update characteristics. Define an application-specific freshness threshold using update timestamps. Test invalid values, stale updates, unavailable reads, and configured fallback behavior. For an applicable L2 deployment, review sequencer status and recovery handling. Simulate the exact configuration change before execution.

Evidence to request

Feed documentation, addresses per chain, adapter code, configuration diff, consumer inventory, test cases, transaction calldata, change owner, and a documented rollback or recovery plan where feasible.

Scope and limits

A code review can evaluate the integration assumptions and tested failure behavior. It cannot guarantee continuous data availability or economic safety under every market condition.

Relevant example — hypothetical

A team replaces an eight-decimal feed with an eighteen-decimal source. Testing the consumer with both scales reveals that its normalization logic needs to change.

Related reading

Chainlink Data Feeds overview: https://docs.chain.link/data-feeds/overview

QuillAudits blog: https://www.quillaudits.com/blog

Next step

Request a review of the complete oracle change, including its dependent contracts and operational configuration.