Timelock on sensitive actions
Chainlink CCIP'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 #
Most sensitive actions route through RBACTimelock (2-day delay). However: (1) OnRamp.sol withdrawFeeTokens() is owner-callable with no evidence of timelock gating — routes to fixed fee aggregator address; (2) rate limit changes are applied 'immediately' without timelock per docs; (3) bypasser role (MCMS at 0x177A28...) can execute any action without the 2-day delay in break-glass scenarios. Not all sensitive paths are timelocked.
Sources #
- DocsRate Limit Management Overview | Chainlink DocumentationRate limit changes: 'changes are applied on-chain and take effect immediately' — no timelock on rate limit updatesretrieved 2026-05-16
- OnRamp.sol — Code4rena 2024-11-chainlinkOnRamp.sol — withdrawFeeTokens() function confirmed owner-callable at lines 499-510, routes to fee aggregatorretrieved 2026-05-16
- smartcontractkit/ccip-owner-contracts READMEccip-owner-contracts README — bypasser role 'expected to only become active in break-glass emergencies where waiting for minDelay would be harmful'; calls bypasserExecuteBatch with no delayretrieved 2026-05-16
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 →