Timelock duration on upgrades

Chainlink CCIP's assessment for RD-F-032 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

RBACTimelock minimumDelay = 172,800 seconds (48 hours / 2 days). Confirmed via Etherscan verified contract source code. Proposer is a ManyChainMultiSig (0x20D64e2a787f8264238C2bCCbA81dC19665CCA62). Executor is open — any party can execute after delay expires with no veto. 48 hours materially exceeds the 24h standard threshold.

Sources #

Etherscan
CCIP RBACTimelock — EtherscanRBACTimelock at 0x9A709B7B69EA42D5eeb1ceBC48674C69E1569eC6 — minimumDelay = 172800 seconds confirmed in verified source code (BSL 1.1, v0.8.19)retrieved 2026-05-16
Docs
Onchain Architecture - Upgradability (EVM) | Chainlink DocumentationChainlink docs — 'review period' enforced by RBACTimelock before execution; node operators can veto during windowretrieved 2026-05-16

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 →

rubric_version v1.7.0 protocol chainlink-ccip factor RD-F-032 score green collected_at 2026-05-16 01:55:09