Fallback behavior on oracle failure
Falcon Finance's assessment for RD-F-051 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No on-chain fallback oracle behavior identified. USDf ERC20 and sUSDf ERC4626 contracts do not call oracles. No try/catch or secondary-oracle fallback pattern in audited contracts. Fallback on oracle failure appears to rely on manual/operational intervention.
Detail #
Etherscan inspection of USDf impl (0x3aDf34C09DAC24E4BAeFB1b1df4C2992edC2b789) and sUSDf impl (0x0D132bEE412E6619a4863AEEdad97541BfDa3F34) shows no oracle interface calls, no try/catch oracle patterns, and no staleness-check logic. Both Pashov (Feb 2025) and Zellic (Feb-Mar 2025) audits cover USDf/sUSDf — neither report mentions oracle fallback logic. Docs risk-management page describes 'dual-layered approach combining automated systems and manual oversight' but does not specify oracle fallback protocol.
Sources #
- AuditFalcon Finance Zellic Audit Report (USDf/sUSDf)Zellic audit Feb 2025 — covers USDf/sUSDf; no oracle fallback finding or design discussionretrieved 2026-05-12
- USDf Implementation Contract — EtherscanEtherscan 0x3aDf34C09DAC24E4BAeFB1b1df4C2992edC2b789 readContract — no oracle interface functionsretrieved 2026-05-12
Methodology #
Identify the declared fallback behavior (pause, secondary source, last-known-price, revert) when the primary oracle reverts or reports a stale value.
See the full factor methodology and distribution across all protocols →