Fallback behavior on oracle failure
Balancer (v2 + v3)'s assessment for RD-F-051 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No protocol-level fallback behavior on rate provider failure. v2: if getRate() reverts, the affected pool's swap/join/exit reverts. The ComposableStablePool rate caching mechanism does NOT include a try/catch fallback to a secondary oracle — it will revert on exception. Docs recommend ExternalCallLib try/catch for Linear Pool implementations but this was not uniformly enforced in deployed pools. v3: rate refreshed via reloadBalancesAndRates() each operation; a failing rate provider reverts the operation for that pool. No last-known-price or secondary-oracle fallback exists in either version.
Detail #
The August 2023 exploit ($2.1M) demonstrated that the Linear Pool rate caching path could be exploited when rate manipulation occurred. While root cause was rounding not oracle failure, the lack of circuit breaker on rate values contributed. The November 2025 exploit ($128M) further confirmed that Stable Math is the critical path, adjacent to rate scaling. Template: red = no fallback: uses primary oracle result unconditionally.
Sources #
- GitHubComposableStablePoolRates.sol — Balancer v2ComposableStablePoolRates.sol — rate cache without try/catch fallbackretrieved 2026-05-05
- Understanding the Balancer v2 Exploit | OpenZeppelinOpenZeppelin analysis of Balancer v2 exploit — rate caching pathretrieved 2026-05-05
- Balancer hack analysis | Trail of BitsTrail of Bits Nov 2025 hack analysis — v3 unaffected, v2 Stable Math root causeretrieved 2026-05-05
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 →