Oracle staleness check present
Falcon Finance's assessment for RD-F-059 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No on-chain staleness check confirmed in verified USDf ERC20 or sUSDf ERC4626 contracts. Neither contract calls oracles. AVAX, USDT, USDC feeds have 24h heartbeats; stale prices could persist up to 24h without on-chain rejection.
Detail #
USDf impl (0x3aDf...) and sUSDf impl (0x0D132bEE...) readContract interfaces: no updatedAt comparison, no latestRoundData staleness check, no maxStaleness state variable. Oracle calls (if any) must occur in an unidentified minting controller. AVAX/USD heartbeat=86400s; USDT/USD heartbeat=86400s; USDC/USD heartbeat=82800s — all near 24h without on-chain staleness enforcement. ETH/BTC are 3600s (1h) which is more reasonable. Pashov/Zellic audits cover USDf/sUSDf only; no staleness check mentioned.
Sources #
- EtherscansUSDf Implementation Contract — EtherscanEtherscan 0x0D132bEE412E6619a4863AEEdad97541BfDa3F34 readContract — no oracle staleness functionsretrieved 2026-05-12
Methodology #
Determine whether the protocol rejects oracle reads older than a declared maximum age (i.e., checks `updatedAt > block.timestamp - maxStaleness`).
See the full factor methodology and distribution across all protocols →