Fallback behavior on oracle failure
Uniswap (v2 + v3)'s assessment for RD-F-051 — scored not_applicable on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No oracle dependency; fallback concept N/A. V3 TickMath bounds (MIN_SQRT_RATIO/MAX_SQRT_RATIO) are internal AMM invariant limits preventing invalid states — not oracle fallback logic. V2 MINIMUM_LIQUIDITY constant is an internal safety invariant. Neither version has a primary oracle to fall back from.
Detail #
UniswapV3Pool.sol: no try/catch or fallback oracle logic; TickMath bounds are internal invariants that cause swap reversion if price moves outside valid tick range. UniswapV2Pair.sol: MINIMUM_LIQUIDITY = 1000 is a one-time deploy-time burn to prevent zero-liquidity state. Neither constitutes oracle fallback behavior.
Sources #
- GitHubUniswapV3Pool.sol — no oracle fallback logicUniswapV3Pool.sol swap() function: no oracle fallback; pricing reverts if tick exceeds TickMath bounds — internal invariant, not oracle fallback.retrieved 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 →