Chainlink launched CCIP 2.0 on Sept. 28, adding optional transaction verifiers, configurable settlement speeds and compliance hooks to its Cross-Chain Interoperability Protocol, the infrastructure used to move tokens and messages between blockchains. The release is live on mainnet, though deployment versions vary by route: Chainlink's Ethereum directory lists outbound routes to Arbitrum One, Avalanche and Base at version 2.0.0, while the route to Aptos remains at 1.6.0. The overall CCIP directory counts 78 mainnet networks across multiple protocol versions.

Existing token pools, senders and receivers can keep operating unchanged and continue waiting for full source-chain finality, according to Chainlink's technical documentation. Issuers who want the new pool-level verifier, fee and finality settings must upgrade to v2 token pools. Pools are the contracts that lock or burn tokens on one chain and release or mint them on another. The Router — the contract applications use to access CCIP — keeps the same address, so application-level integrations require no rewrite.

What changes architecturally?

Under version 1, Chainlink's decentralized oracle network handled both committing reports about source-chain transactions and executing messages on the destination chain. Version 2.0 separates signed verification from delivery: once the required attestations exist, any party can submit a message for execution.

The default Committee Verifier consists of 16 independent node operators. Issuers and applications can require additional Cross-Chain Verifiers, or CCVs, to sign transactions before execution, and Chainlink supplies starter kits for running those verifiers on Amazon Web Services or Google Cloud. The onchain Risk Management Network contract remains in place as an emergency-stop mechanism.

Faster transfers are also opt-in. Full source-chain finality stays the default; choosing fewer confirmations means accepting the risk that the source blockchain reorganizes after tokens have already been delivered elsewhere. Chainlink's documentation warns this can cause duplicate execution, unbacked tokens or losses. Legacy pools and receivers cannot opt into faster-than-finality transfers at all.

For regulated assets, an optional AdvancedPoolHooks contract connects pools to Chainlink's Automated Compliance Engine. Issuers can enforce identity, recipient or amount policies before tokens leave the source chain, before release on the destination chain, or both. A rejected destination check leaves the message unexecuted until the condition resolves. Compliance screening is not mandatory across all CCIP transfers.

The fee model becomes modular as well: execution, verifier, token-pool and protocol fees can each contribute to the total. Token issuers can set transfer charges that vary by route or finality setting, including fees deducted from the transferred amount itself.

What must existing issuers do?

The upgrade lands on top of issuer relationships Chainlink already secured. BitGo selected CCIP for WBTC in August, citing issuer-managed rate limits and configurable transfer controls, and Lido chose CCIP for its cross-chain expansion in May.

On launch day, Chainlink's directory still listed the Ethereum pools for WBTC and Lido's wstETH at version 1.6.0, and Coinbase's cbBTC pool on Base at 1.6.1. Those deployments remain compatible with the new protocol's defaults.

Upgrading standard EVM token pools is a multi-step operation. The burn-and-mint migration guide calls for deploying new pools, granting mint-and-burn permissions, configuring counterpart pools and switching the token-to-pool mapping in Chainlink's registry. Old pool addresses must stay recognized until messages already in transit settle. Lock-and-mint deployments add a custody step: locked tokens move from the old pool into a new lockbox contract. The published guides cover standard EVM-to-EVM pools only — issuers running customized pools face an unspecified migration path, a variable worth watching as major issuers decide whether to take up v2 controls.