Verification Models

CCIP supports multiple Cross-Chain Verifier (CCV) models. Each model follows the same high-level pipeline — monitor source-chain events, wait for the required finality, produce a VerifierResult — but attestation mechanics differ.

For resolver contracts, version tags, and interface requirements shared across models, see CCV Interfaces & Guarantees.

CommitteeVerifier (Default)

The CommitteeVerifier is CCIP's default CCV, operated by the CCIP decentralized oracle network.

Attestation flow:

1. Offchain verifier nodes monitor CCIPMessageSent events filtered to their CCV's resolver contract.
2. Each node waits until the message meets its configured finality requirement (full finality by default, or a custom depth for faster-than-finality transfers).
3. Each node independently signs a hash over the CCV's version tag and the MessageID (which commits to the full encoded message).
4. Signatures are sent to an Aggregator, which assembles a quorum result and exposes the combined VerifierResult via a read API.

Reorg handling: When a faster-than-finality message is reorged before full finality, the CommitteeVerifier quarantines affected messages and pauses new attestations until the source chain reaches finality. This reorg quarantine is specific to the default committee verifier. Third-party CCVs may not provide equivalent protection — see Trust & Responsibility Model.

CCTPVerifier

The CCTPVerifier integrates Circle's Cross-Chain Transfer Protocol attestation for USDC.

Instead of DON quorum signatures, the offchain verifier polls Circle's external attestation API, matches the response to the message using data from the CCIPMessageSent receipt, and serves the result via API for executors to retrieve.

Use this model when USDC transfers should carry Circle's native cross-chain attestation in addition to, or as part of, CCIP's verification stack.

LombardVerifier

The LombardVerifier supports token-specific verification through an external attestation service.

Like CCTPVerifier, the offchain component polls an external API, matches attestations to messages, and publishes VerifierResults for execution. Configuration includes supported tokens and remote adapter paths.

Use this model when a token issuer or protocol requires verification tied to an external attestation provider.

Custom CCVs

CCVs are permissionless. Any party can deploy onchain resolver and implementation contracts plus the corresponding offchain verifier service, provided they conform to CCIP's interface specifications.

Custom CCVs are appropriate when:

• An institution requires its own verification committee or attestation source
• An application needs verification logic that the default models do not cover
• A token pool or receiver mandates a specific third-party verifier

Custom operators must implement both onchain contracts (outbound registration, inbound verifyMessage) and offchain infrastructure (event monitoring, attestation publishing). Failure to meet protocol specifications can stall or fail user transactions.

Comparing Models

Learn More

• Cross-Chain Verifiers Overview
• CCV Interfaces & Guarantees
• Architecture Overview: Verification stage in the message lifecycle