Security-Council threshold reduction (RT)
Hyperlane's assessment for RD-F-182 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
RD-F-182 monitors for Security Council multisig threshold reductions, timelock removals, or new-signer additions. Hyperlane's Upgrade Timelock (0xBE8B8dc0...) was deployed with getMinDelay()=0 seconds per profile — structurally equivalent to a timelock removal (the timelock provides zero delay protection). This zero-delay Timelock is a static finding from deploy time, not a new real-time event — so the signal would not fire as a real-time alert TODAY. However, the posture is yellow: if either Safe multisig had a threshold reduction (e.g., Core Governance 6-of-10 reduced to 4-of-10, or Operations Multisig 4-of-9 reduced to 3-of-9), RD-F-182 would fire immediately given the existing zero-delay timelock background condition.
Sources #
- EtherscanHyperlane Upgrade Timelock EtherscanUpgrade Timelock 0xBE8B8dc0... — TimelockController; getMinDelay()=0 seconds per Etherscan read — zero delay providing no protectionretrieved 2026-05-17
- Hyperlane Protocol Profile00-profile.md §6 — Timelock getMinDelay()=0 seconds; zero-delay Timelock provides no protection; critical flag notedretrieved 2026-05-17
Methodology #
Detect in real-time whether the bridge/protocol Security Council multisig executes a threshold reduction (e.g. 3/5 → 2/5), timelock removal, or new-signer addition within ≤14 days of either of those events.
See the full factor methodology and distribution across all protocols →