Chainlink's CCIP 2.0 lets a token issuer require an additional verifier before tokens finish moving from one blockchain to another. A sending pool may already have locked or burned the tokens when that check becomes decisive: without the verifier's attestation, the receiving chain cannot release or mint them.

Announced on Sept. 28 , the feature adds optional Cross-Chain Verifiers (CCVs) alongside CCIP's default Committee Verifier. An issuer or third party can operate one and make its approval a condition of delivery.

That gives the operator's rules and uptime a direct role in a holder's exit path. Chainlink's launch material does not identify a named production asset and lane using an issuer-run required CCV, so the mechanism is not evidence of a holder's transfer being blocked.

CCIP's OnRamp assembles the applicable verifier requirements of a token transfer, and the token pool locks or burns the tokens. The OnRamp then records the message for offchain verifier services.

Those services watch the source event, apply their finality and verification rules, and publish attestations tied to the message ID.

On the destination chain, CCIP's OffRamp checks the required attestations before the pool releases or mints tokens. Its checks draw on the lane and token-pool settings and, when a receiver contract is involved, that receiver's requirements.

Sender preferences can add to the source-side verifier set. A token-only transfer has no receiver callback whose verifier preferences must be checked. This sequence places the lock or burn before verification and the destination release after it.

A source transaction may have succeeded while destination delivery remains pending, so Chainlink says all required CCVs must return valid results before execution proceeds. Its trust model warns that an unresponsive verifier can stall every message requiring its attestation.