Skip to main content
No oracle network is immune to delays, outages, or edge cases. A well-designed protocol anticipates these scenarios and responds correctly — not by proceeding with bad data, but by degrading gracefully to a safe state while maintaining as much functionality as possible. This page covers every fallback pattern available to protocols consuming IFÁ Labs feeds, from simple secondary oracle integration to full circuit breaker architectures.

The Fallback Design Spectrum

Fallback strategies exist on a spectrum between two extremes:
The right position on this spectrum depends on your protocol’s risk profile. A lending protocol running liquidations should sit far left. A price display dashboard can sit far right. Most production protocols need different strategies for different operations.

Pattern 1: Hard Revert (Default)

The simplest and safest fallback. If the primary feed is stale or invalid, revert. Nothing executes against bad data.
Use when: Liquidations, collateral valuation, minting, settlement — any operation where executing with bad data causes direct financial harm. Trade-off: Zero tolerance for oracle issues. If the feed is stale, the function reverts — users cannot execute until the feed recovers.

Pattern 2: Secondary Oracle Fallback

Attempt the primary oracle first. If it fails freshness or validity checks, try a secondary source before reverting.
When using a secondary oracle as fallback, emit an event when fallback is triggered. Off-chain monitoring should alert your team immediately — fallback usage is a signal that the primary feed has an issue requiring investigation.

Pattern 3: Median of Multiple Oracles

For maximum price accuracy and manipulation resistance, aggregate prices from multiple independent oracles and take the median. A single manipulated or stale oracle cannot move the median significantly if the others are healthy.
Use when: High-value lending protocols, large stablecoin vaults, or any protocol where the cost of a manipulated price is significant enough to justify the additional gas and integration complexity.

Pattern 4: Tiered Operations by Data Quality

Different protocol operations have different tolerance for oracle uncertainty. Structure your protocol so that the strictness of price requirements scales with the risk of the operation.
Use when: Complex protocols with multiple operation types — lending, borrowing, liquidation, deposits, withdrawals — that have genuinely different risk profiles and should not be constrained by the strictest possible staleness requirement across all functions.

Pattern 5: Automatic Protocol Pause with Guardian Recovery

When the primary feed fails in a way that cannot be resolved by a fallback — both primary and secondary are stale simultaneously — automatically pause sensitive operations and require guardian intervention to resume.
Always keep withdrawal and position-closing functions available even when the protocol is paused due to oracle issues. Users must be able to exit positions safely regardless of oracle state. Blocking withdrawals during a pause traps user funds and creates additional risk.

Pattern 6: TWAP as Fallback

For protocols that cannot rely on spot prices alone, a Time-Weighted Average Price (TWAP) derived from on-chain DEX pools provides a manipulation-resistant fallback that is independent of the oracle infrastructure entirely.
TWAP prices from DEX pools are manipulation-resistant for longer periods (30+ minutes) but can be manipulated at the block level with sufficient capital. Use TWAP as a fallback for short-term oracle outages — not as a replacement for a reliable oracle network.

Choosing the Right Pattern


Fallback Implementation Checklist

1

Define operation tiers

Categorize every protocol function by its tolerance for oracle uncertainty. Liquidations are Tier 1 — strictest. Display functions are Tier 4 — most lenient.
2

Choose a pattern per tier

Select the appropriate fallback pattern for each operation tier. You may use different patterns for different tiers within the same protocol.
3

Implement withdrawal safety

Confirm that withdrawals and position-closing functions remain available under all oracle failure scenarios — including full protocol pause.
4

Wire up the guardian

Define who the guardian is — a multisig, a timelock, or a governance contract — and confirm they can respond to a pause event within your acceptable recovery time window.
5

Emit events on fallback usage

Every time a fallback path is taken, emit an event. Off-chain monitoring should alert your team immediately when fallback is triggered.
6

Test all failure modes

Use Foundry’s vm.mockCall to simulate stale prices, missing feeds, and secondary oracle failures. Every fallback path should have a test that exercises it.
7

Document your runbook

Write a response procedure for every fallback scenario — what triggers it, what the guardian should check, what actions are available, and when to resume.

Testing Fallback Logic with Foundry


Next Steps

Cross-Chain Price Consistency

Ensure consistent pricing across chains for multi-network protocols.

Running Price Monitoring

Detect oracle issues before they reach your fallback logic.