Chainlink’s CCIP 2.0 allows token issuers to make an additional verifier’s approval a condition of completing a transfer between blockchains, creating a possible delay after tokens have already been locked or burned on the source chain.
The feature, announced on Sept. 28, introduces optional Cross-Chain Verifiers (CCVs) alongside CCIP’s default Committee Verifier. An issuer or third party can operate a CCV and require its approval before tokens are released or minted on the receiving network.
That means the rules and availability of an issuer’s, or external operator’s, service can become part of a holder’s exit route. Chainlink’s launch material does not identify a named production asset and lane using an issuer-operated required CCV, so the feature alone does not show that any holder’s transfer has been blocked.
Where transfers can stall
CCIP’s OnRamp first determines which verifier requirements apply to a transfer, while the token pool locks or burns the tokens. The OnRamp then records the message for offchain verifier services.
Those services monitor the source-chain event, apply their own finality and verification rules, and issue attestations linked to the message ID. The OffRamp on the destination chain checks the required attestations before the token pool releases or mints the assets.
The checks are based on the lane and token-pool configuration and, where a receiver contract is used, that contract’s own requirements. Sender preferences may also add to the verifier set on the source side. Token-only transfers do not involve a receiver callback with additional verifier preferences.
As a result, the lock or burn can happen before verification is complete, while release on the destination chain comes afterwards. Chainlink says issuers can reject a transfer before that source-side action, but required attestations can also delay delivery after the initial transaction has succeeded.
Every required CCV must provide a valid result before execution can continue. Chainlink’s trust model warns that an unresponsive verifier could stall all messages that depend on its attestation.
The default Committee Verifier consists of 16 independent node operators. Adding another CCV can provide an extra check, but the issuer or application must consider who controls its contracts and offchain service, which rules it applies and whether it remains available. Chainlink assigns external CCV operators responsibility for implementation, maintenance and uptime.
Options when delivery stops
Destination-chain execution is permissionless once all required proofs are available and any optional verifier quorum has been reached. Chainlink’s default executor usually submits the transaction, but anyone can do so, including through the manual execution path.
Changing the executor or paying the destination-chain gas does not bypass a missing required CCV attestation. The OffRamp continues to verify the proofs before releasing or minting tokens.
If the necessary attestation has not been assembled, the message can remain marked UNTOUCHED, meaning no execution has been recorded. If an attempted execution fails within the OffRamp’s protected path, it can be marked FAILURE.
Chainlink says failed attempts can be retried once the underlying issue is resolved. Its default executor retries failures during a configured window currently set at eight hours, although that period applies to the automated service.
The manual execution guide explains how to check verifier status and execution state, including situations where the indexer has not collected an external verifier’s result. Chainlink’s published process does not set out a general automatic cancellation, refund or return of source-chain tokens if a required verifier never attests. Any remedy would depend on the arrangements for the specific asset.
On EVM chains, a configured Chainlink Automated Compliance Engine hook can reject a transfer before the source pool locks or burns the tokens, causing the source transaction to revert. A separate destination postflight hook can reject release or mint after the transfer has begun, leaving the tokens undelivered until the policy issue is resolved and execution is retried.
Chainlink’s mainnet directory lists supported networks and tokens, but does not show whether a particular production lane requires an issuer-operated verifier or has enabled a destination ACE gate. A partner announcement or previous asset migration does not establish those settings. Without the token pool, route and verifier configuration, the feature cannot be attributed to the issuer of a named asset.
CCIP 2.0 also offers transfers faster than source-chain finality. Full finality remains the default, while Chainlink’s FTF guide says the faster option can expose a transfer to duplicate destination execution after a sufficiently deep reorganisation. Other required CCVs may apply their own reorganisation rules, but the faster setting does not remove the need for mandatory attestations.
