Timelock duration on upgrades
Hyperlane's assessment for RD-F-032 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
U18 RESOLVED ON-CHAIN — PIPELINE BUG CONFIRMED. Upgrade Timelock 0xBE8B8dc0510F80f0Dfb805302c1A60DaEE8f3434 creation tx 0xd11c92e4... emitted MinDelayChange(oldDuration=0, newDuration=86400). getMinDelay()=86400 seconds (24h) confirmed. The pipeline fetch of getMinDelay()=0 was a bug (yearn-finance precedent confirmed here). 24h delay EXISTS but is below the 48h+ best practice for a $132M bridge protocol. Proposer is Core Governance Safe (6-of-10). Scored yellow: Timelock exists with 24h delay; below 48h+ peer norm. Note: this Timelock was deployed 2025-07-18 — it is not in the ProxyAdmin v1 upgrade path for the existing Mailbox (ProxyAdmin v1 owner Safe 0x12C5AB61 controls upgrades directly); the Timelock is the operative upgrade governance mechanism for future protocol actions.
Sources #
- EtherscanUpgrade Timelock creation tx — getMinDelay=86400s confirmedTimelock creation tx 0xd11c92e46a80881758a4a03d0d3096f607ce1b9b7f6f0154c1d99d316728f923: MinDelayChange event newDuration=86400; proposer=0x562Dfaac (Core Governance Safe 6-of-10); executor=0x0000...0000 (open)retrieved 2026-05-17
- Hyperlane Upgrade Timelock EtherscanTimelock contract 0xBE8B8dc0... — OZ TimelockController Solidity 0.8.22, created 2025-07-18 block 22949258retrieved 2026-05-17
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 →