Chainlink Expands CCIP With Configurable Security
Chainlink has introduced CCIP 2.0, a major update to its Cross-Chain Interoperability Protocol designed to give applications more control over how cross-chain transactions are verified.
CCIP allows blockchains to exchange messages and move supported assets between networks. Chainlink's existing infrastructure uses decentralized oracle networks to observe activity on one blockchain, reach consensus about what happened and communicate the result to another network. Chainlink — CCIP Cross-Chain Interoperability Protocol
The new version adds configurable verification policies, allowing applications to specify required and optional cross-chain verifiers. Chainlink's developer documentation describes CCIP 2.0 policies in terms of required verification networks and optional verification networks that can be subject to a defined threshold. Chainlink — CCIP 2.0 Verification Policy Documentation
KelpDAO Hack Highlighted Single-Verifier Risk
The CCIP 2.0 rollout comes months after the April 2026 attack on KelpDAO's rsETH bridge, which resulted in the loss of approximately 116,500 rsETH worth about $292 million, according to LayerZero's subsequent incident report. LayerZero — KelpDAO Incident Report
LayerZero said the affected KelpDAO application used a 1-of-1 decentralized verifier network (DVN) configuration, meaning LayerZero Labs' DVN was the only verifier required to approve the cross-chain message. According to LayerZero, attackers compromised infrastructure used by its DVN and ultimately caused it to attest to a forged message. The destination contract then accepted the attestation and released the rsETH.
LayerZero attributed the attack to the DPRK-linked TraderTraitor threat actor, also known as UNC4899, citing investigations by Mandiant, CrowdStrike and independent security researchers. LayerZero — Final KelpDAO Incident Report
LayerZero and Kelp Disagreed Over the Configuration
The incident also triggered a dispute over responsibility for the security configuration.
LayerZero said KelpDAO had selected a single-verifier setup despite LayerZero's recommendation to use multiple independent DVNs with redundancy. In its April incident statement, LayerZero argued that a multi-DVN configuration could have prevented the forged message from being accepted because an attacker would have needed agreement from multiple independent verification systems.
The supplied report says KelpDAO subsequently disputed that characterization, arguing that LayerZero personnel had reviewed its configuration and had not objected to the setup. KelpDAO also indicated that it planned to move rsETH to Chainlink infrastructure.
The disagreement is important because it illustrates the difference between a cross-chain protocol's available security controls and the configuration selected by an individual application. A system can provide multiple verification options while an application chooses to rely on only one.
CCIP 2.0 Adds More Verification Choices
CCIP 2.0 addresses this type of configuration issue by allowing applications to define additional verification requirements.
Under the new model, companies can use their own verification infrastructure or work with external providers. The supplied report identifies Infosys and Nethermind among potential outside verification providers, giving institutions more flexibility in designing their cross-chain security policies.
At the same time, Chainlink's core CCIP infrastructure continues to use a decentralized network of 16 independent professional node operators. Chainlink says these operators validate cross-chain transactions through decentralized consensus and use geographically distributed infrastructure.
This creates a layered approach: applications can add their own verification requirements while the underlying Chainlink infrastructure continues to provide its own decentralized validation.
What Happens When a Cross-Chain Transfer Is Verified?
A cross-chain bridge generally needs some mechanism to establish that an event occurred on the source blockchain before an action can be completed on the destination blockchain.
For example, if a user transfers a token from Ethereum to another network, the destination system needs evidence that the corresponding source-chain transaction actually occurred. Verifiers or verification networks provide that confirmation before the destination-side transaction is finalized.
This creates a critical security dependency. If the verification mechanism accepts a false message, the destination system could release or mint assets that were never legitimately deposited on the source chain.
Chainlink describes CCIP as a defense-in-depth system in which decentralized observation and validation are separated across multiple components. Its published architecture says CCIP is designed to avoid dependence on a single observer, endpoint or infrastructure provider.
CCIP's Security Model Is Also Changing
One notable change in CCIP 2.0 concerns Chainlink's Risk Management Network (RMN).
The RMN previously operated as a separate monitoring and validation layer for CCIP. Chainlink's earlier documentation described it as an independent network that continuously monitored and validated the behavior of the primary CCIP network, providing an additional security layer.
According to the supplied report, CCIP 2.0 changes that role, with independent checks instead being available through the new optional verifier framework. That means the security model for users and applications can depend on the verification configuration they select.
This makes configuration more important under the new architecture. Developers and institutions can add additional verification requirements, but they also need to understand which verifiers are required, how many must agree and what security assumptions those providers introduce.
Existing CCIP Users Move to the New Version
The supplied report says existing Chainlink users were automatically migrated to CCIP 2.0.
The transition does not mean every application is immediately using the new optional verification features. Chainlink has said that different applications and asset issuers can use additional security controls depending on their requirements.
The company has also highlighted adoption of other CCIP 2.0 features by major protocols. The supplied report names Aave and Maple as early adopters of some of the upgrade's capabilities, although it says Chainlink had not yet identified an institution using the new external verifier configuration.
Why CCIP 2.0 Matters for Cross-Chain Finance
Cross-chain infrastructure has become increasingly important as assets, applications and financial products operate across multiple blockchain networks. But the movement of assets between chains introduces additional security assumptions that do not exist in a single-chain transaction.
The KelpDAO exploit demonstrated the consequences that can follow when a bridge configuration depends on one verification path. LayerZero subsequently said it would no longer allow its own DVN to act as the sole required attestor for applications using its infrastructure. LayerZero — Post-Incident Security Changes
CCIP 2.0 takes a different approach by making verification more configurable while maintaining Chainlink's own decentralized infrastructure underneath. For developers, the change provides more control over security assumptions. For institutions, it creates additional options for designing cross-chain systems around specific risk, compliance and operational requirements.
The broader takeaway is that bridge security is increasingly moving beyond simply asking whether a protocol is decentralized. The specific verification configuration, infrastructure dependencies and redundancy built into each application can determine how a cross-chain system responds when one component fails or is compromised.
