Security-Council threshold reduction (RT)
Chainlink CCIP'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 #
F182 (batch-24, Cat 6B): Security-Council threshold reduction RT signal. Highest-salience Cat 6B factor for CCIP. Threshold: any MCMS threshold reduction, RBACTimelock delay reduction, or new signer addition within 14 days of another change fires the signal. Current posture: No MCMS threshold reduction detected since CCIP mainnet launch (July 2023). September 2023 incident (Chainlink multisig signer rotation, one signer removed from a related LINK multisig) resolved as 'routine periodic rotation, threshold maintained at 4-of-9' per Chainlink spokesperson — this was NOT a threshold reduction; it was a signer removal with threshold unchanged. However: (1) MCMS signer count and threshold are not publicly disclosed, making ongoing monitoring harder than for transparent Gnosis Safe multisigs; (2) the 2023 community concern shows even benign rotations can go undisclosed for days; (3) post-KelpDAO-migration, CCIP is now the highest-value bridge target making any threshold reduction immediatel
Sources #
- URL
- CCIP Onchain Architecture - UpgradabilityCCIP upgradability docs — MCMS signer identities and threshold deliberately not disclosed publiclyretrieved 2026-05-16
- ManyChainMultiSig — EtherscanManyChainMultiSig 0xE53289F32c8E690b7173aA33affE9B6B0CB0012F — publicly readable; signer count/threshold deliberately undisclosed in docsretrieved 2026-05-16
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 →