Timelock duration on upgrades
Balancer (v2 + v3)'s assessment for RD-F-032 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
NO ACTIVE TIMELOCK. The v2 Vault's current Authorizer is AuthorizerWithAdaptorValidation (0x6048A8c631Fb7e77EcA533Cf9C29784e482391e7) which has no timelock logic — confirmed by Etherscan source inspection (no getMinDelay() or timelock functions). The TimelockAuthorizer (0x9E3cD0606...) is flagged DEPRECATED in balancer-deployments mainnet.json and is NOT registered as the Vault's Authorizer. Data cache confirms timelock_delay_seconds: null. Effective timelock delay = 0.
Sources #
- GitHubBalancer Deployments Registry — TimelockAuthorizer DEPRECATEDbalancer-deployments mainnet.json — TimelockAuthorizer status: DEPRECATEDretrieved 2026-05-05
- Balancer V3: Authorizer With Adaptor Validation — EtherscanAuthorizerWithAdaptorValidation — no getMinDelay() function, no timelock logicretrieved 2026-05-05
Methodology #
Read the timelock delay (in hours) between a queued upgrade proposal and its executable state.
See the full factor methodology and distribution across all protocols →