The Fallback Design Spectrum
Fallback strategies exist on a spectrum between two extremes:Pattern 1: Hard Revert (Default)
The simplest and safest fallback. If the primary feed is stale or invalid, revert. Nothing executes against bad data.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.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.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.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.

