Chainlink CCIP

The scheduled date is the outside bound. Kill criteria are checked every day, and a trigger reopens the memo that week.

APPROVED WITH LIMITS, AS A DEPENDENCY, WITH THE OPPOSITE VERDICT OF ITS NEAREST COMPETITOR. CCIP is Chainlink’s cross-chain messaging layer — like LayerZero, reviewed separately in this registry and rejected, it is infrastructure other protocols build bridges and cross-chain products on, not itself a directly-allocable position, and its tracked TVL likely double-counts value already reflected in downstream integrators pending entity resolution. The decisive difference from LayerZero: CCIP runs an independent Risk Management Network on every message by default, with its own node operators and its own codebase, that can halt cross-chain activity network-wide if it detects a message the primary oracle network did not independently verify. That directly targets the failure mode that let LayerZero’s April 2026 incident succeed — a single-verifier configuration an integrator chose or defaulted into. CCIP does not let an integration skip this check. The live governance gap is that the multisig signers who control CCIP’s security configuration are not publicly disclosed, which this cap prices as a bounded, disclosed risk rather than a disqualifying one.

Kill criteria: the events that revoke this verdict
• Any confirmed exploit of CCIP’s Committing or Executing DON, or of the Risk Management Network infrastructure
• The Risk Management Network node-operator set is found to overlap with the primary DON operators, breaking the independence claim
• Multisig signer identities remain undisclosed at the next review, escalating a standing transparency gap unresolved past 12 months
• A specific Ketju-relevant integration is found to bypass or under-configure the default Risk Management Network check

The research file

Mechanism

CCIP uses two structurally distinct systems for every message. Chainlink’s existing Decentralized Oracle Networks (the Committing and Executing DONs) transmit and execute cross-chain messages. A separate Risk Management Network independently re-observes each message and can ”curse,” or emergency-halt, cross-chain activity if it detects a Merkle root containing messages it did not independently verify. Unlike LayerZero’s DVN model, where an integrator opts into extra verifiers and many default to a single LayerZero-run DVN, the RMN check runs by default and is not something an integration can under-configure away.

Independence of the Risk Management Network

Per Chainlink’s own technical documentation, the RMN uses a distinct set of node operators with no nodes shared with the transactional DONs, and is built in Rust by a separate internal team, versus Go for the primary system — deliberate diversity in both personnel and implementation language, not a rebadged committee drawing on the same infrastructure. This is the architectural feature that most directly addresses the exact failure mode the Kelp DAO/LayerZero incident exploited.

Governance

Security-critical CCIP configuration changes route through an on-chain RBACTimelock using a ManyChainMultiSig structure, one signature set covering many chains. Node operators can veto a pending change during the timelock window, or fast-track approval for urgent fixes. That is a real, documented accountability mechanism, but the specific multisig signer identities are not publicly disclosed — Chainlink frames this as standard industry practice, but it remains a genuine transparency gap the timelock’s existence does not close.

Incident record and dependency framing

No confirmed CCIP protocol-level exploit was identified through this review’s 2026-08-17 cutoff. Market behavior after the LayerZero incident is a relevant, if secondary, signal: CCIP is reported to have gained more than $2.5B in TVL from protocols migrating away from LayerZero, including Kraken Bitcoin. Like LayerZero, this entry should be modeled as a dependency rather than a directly exitable position: CCIP itself holds no client funds to withdraw or redeem, so there is no bridge-level exit queue or redemption gate to test. Any Ketju-approved position that routes through a CCIP-secured integration inherits that integration’s own withdrawal and redemption terms, and this approval does not certify a position that has been custom-configured to bypass the default RMN path.

Comparison

Against LayerZero V2 (rejected in this registry), CCIP’s always-on, independently-coded RMN is a structurally stronger default because verification isn’t something an integrator can skip or under-configure the way the Kelp DAO deployment did. The remaining open weakness is governance opacity — undisclosed multisig signers — rather than a gap in the verification architecture itself, which is why this registry treats CCIP as approvable with a cap rather than rejected outright.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Chainlink — CCIP’s defense-in-depth security and the Risk Management Network · primary · accessed 2026-08-17
  Supports: RMN independence, separate codebase and team
• Chainlink — CCIP: the secure and decentralized cross-chain standard · primary · accessed 2026-08-17
  Supports: architecture overview
• Chainlink Documentation — CCIP · primary · accessed 2026-08-17
  Supports: governance, timelock references
• Chainlink Documentation — cross-chain token setup with production multisig governance · primary · accessed 2026-08-17
  Supports: ManyChainMultiSig, RBACTimelock, veto quorum
• The Block — Chainlink CCIP gains over $2.5 billion in TVL from protocols migrating from LayerZero · secondary · accessed 2026-08-17
  Supports: migration signal, Kraken Bitcoin

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.