Skip to content

Back to the catalog

Chainlink launches new version of its crypto bridge tech 'CCIP' to give apps more control over their security
coindesk.comarticle

Chainlink launches new version of its crypto bridge tech 'CCIP' to give apps more control over their security

Chainlink released CCIP 2.0, redesigning its cross-chain bridge so apps can layer custom or third-party verifiers (e.g. Infosys, Nethermind) on top of its default 16-operator quorum network, replacing the separate Risk Management Network as the independent safety check. The launch follows the April $292M Kelp DAO hack, in which Lazarus Group allegedly fooled a single-verifier LayerZero bridge setup to drain rsETH - CoinGecko data showed nearly half of active LayerZero apps used the same single-verifier arrangement. The article contrasts single-verifier trust models with Chainlink's quorum-based design as a mitigation for that bridge attack class.

TL;DR Chainlink's CCIP 2.0 lets apps stack custom verifiers atop its 16-operator quorum network, directly addressing the single-verifier trust flaw Lazarus Group exploited to drain $292M from Kelp DAO's LayerZero bridge.
Document

What it is

Chainlink's CCIP 2.0, released Monday (Sept. 28, 2026), an upgrade to its cross-chain bridging protocol. The security-relevant change for an integrator is not the addition of optional verifiers (Infosys, Nethermind, or self-run) — it is the removal of the Risk Management Network as an independent, always-on second check, and what that means for teams that add nothing.

The default-posture change

Before CCIP 2.0, a transfer was validated by two separate networks: the main verifier set plus the Risk Management Network double-checking it. In 2.0 the RMN no longer plays that role. A user who configures no extra verifiers now relies on one network — Chainlink's default 16 independent node operators, which must reach quorum on every transfer. That 16-operator quorum is still far stronger than the single verifier that sank Kelp DAO, but it is one layer where there were two. Chainlink's position is that the independent-check role can now be filled by the optional verifiers instead — meaning restoring a genuinely independent second check is now an opt-in action, not a default.

flowchart TD
    A[CCIP transfer] --> B{Verifiers configured?}
    B -->|No, default| C[16-op quorum only<br/>one network]
    B -->|Yes, opt-in| D[16-op quorum<br/>+ custom/3rd-party verifier<br/>independent 2nd check restored]

What to do

  • If you already integrate CCIP: existing integrations continue to work under 2.0 with no changes required, per Chainlink.
  • If you relied on the RMN as your independent safeguard: it no longer serves that function. To keep an independent second check, add an optional verifier (self-run or a provider such as Infosys/Nethermind) on top of the default network.

Caveats

  • Chainlink has not named any institution using the new optional verifiers yet; it cites only Aave and Maple adopting other features of the upgrade. So the opt-in verifier path is unproven in production at the time of writing.
  • CoinDesk issued a correction (Sept. 28, 14:41 UTC): an earlier version wrongly said existing users were automatically moved to CCIP. They are not automatically moved.

Organisations named here

  • Kelp DAO

Technologies named here

  • Kelp DAO bridge
  • Chainlink CCIP 2.0
  • LayerZero
  • Chainlink Risk Management Network
  • Infosys
  • Chainlink CCIP
  • Nethermind
  • Ethereum
  • Chainlink

Techniques named here

  • Single-verifier bridge exploitation

Threat actors named here

  • Lazarus Group