Timelock on sensitive actions
Hyperlane's assessment for RD-F-033 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
U18 re-scored following Timelock confirmation. A 24h Timelock exists (0xBE8B8dc0510F80f0Dfb805302c1A60DaEE8f3434, proposer=Core Governance Safe). However, the ProxyAdmin v1 (controlling the live Mailbox) is owned by the 3-of-6 Safe (0x12C5AB61) which can call upgrades WITHOUT routing through the Timelock — the Timelock is a separate governance layer deployed 2025-07-18, not necessarily in the existing Mailbox upgrade path. Mailbox.sol onlyOwner functions (setDefaultIsm, setDefaultHook, setRequiredHook) route through whoever owns the Mailbox — not confirmed to be behind the Timelock. Scored yellow: Timelock exists with 24h delay for proposer-gated actions but direct upgrade path via ProxyAdmin v1 owner Safe bypasses it.
Sources #
- GitHubHyperlane Mailbox.sol sourceMailbox.sol: setDefaultIsm(), setDefaultHook(), setRequiredHook() all use onlyOwner modifierretrieved 2026-05-17
- ProxyAdmin v1 — upgrade path without TimelockProxyAdmin v1 0x75EE15 owner is Safe 0x12C5AB61 (3-of-6); no evidence the Safe routes upgrades through the Timelockretrieved 2026-05-17
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 →