Timelock on sensitive actions
Balancer (v2 + v3)'s assessment for RD-F-033 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Since no active timelock exists (RD-F-032 red): mint (BalancerTokenAdmin — rate-limited by emission schedule but no tx-level delay), pause (Emergency subDAO — immediate), fee collection (ProtocolFeesCollector — no delay), permission grants (AuthorizerWithAdaptorValidation — no delay). None of the five sensitive action types enforce a timelock delay. The deprecated TimelockAuthorizer is not in the execution path.
Sources #
- EtherscanBalancer V3: Authorizer With Adaptor ValidationAuthorizerWithAdaptorValidation — no timelock enforcement on any actionretrieved 2026-05-05
- Balancer Governance OverviewBalancer governance confirms no timelock between Snapshot vote and multisig executionretrieved 2026-05-05
Methodology #
For each sensitive action category (mint / pause / rescue / setOracle / upgrade), determine whether execution requires going through the declared timelock.
See the full factor methodology and distribution across all protocols →