Oracle staleness check present
Balancer (v2 + v3)'s assessment for RD-F-059 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Partial staleness protection. v2 ComposableStablePool implements a rate cache with configurable cache duration — if the cache is older than the configured duration, a fresh rate is fetched from the rate provider. This is a pseudo-staleness mechanism on the cache, not a strict updatedAt check on the underlying oracle feed. The underlying Chainlink feeds (ETH/USD 3600s heartbeat, BTC/USD 3600s, USDC/USD 82800s) have their own SLAs but Balancer does not enforce them on-chain. v3 fetches fresh rates on every operation via reloadBalancesAndRates() — no cache staleness risk, but no heartbeat enforcement on the underlying oracle data source.
Detail #
Template: yellow = staleness check present but threshold >3600s (in this case: cache duration varies per pool configuration; underlying feed heartbeat is not enforced at Balancer layer). Scored yellow because the cache mechanism provides partial protection, even if imperfect.
Sources #
- DocsRate Providers | Balancer v2v2 rate provider docs — cache duration configurationretrieved 2026-05-05
- ComposableStablePoolRates.solComposableStablePoolRates.sol — rate cache with configurable durationretrieved 2026-05-05
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 →