# Cross-Chain Verifiers Overview
Source: https://docs.chain.link/ccip/concepts/ccvs/overview

> For the complete documentation index, see [llms.txt](/llms.txt).

Cross-Chain Verifiers (CCVs) are CCIP's pluggable verification layer. Each CCV attests that a source-chain message is valid before the destination chain executes it.

Most integrations use CCIP's default **Committee Verifier** without additional configuration. For how verification fits into the end-to-end message lifecycle, see the [Architecture Overview](/ccip/concepts/architecture/overview).

This section explains how to extend verification with **custom or third-party CCVs**. It does not describe default CCIP behavior in depth or provide production deployment guides.

## What CCVs Do

CCVs bridge source-chain events and destination-chain execution:

1. On the **source chain**, the OnRamp calls the CCV's outbound implementation, which runs the verifier's outbound hook and returns verifier data. The OnRamp emits that data in its `CCIPMessageSent` event.
2. **Offchain**, the CCV's verifier service waits for the required confirmation depth, validates the message, and publishes a **VerifierResult** tied to the message ID.
3. On the **destination chain**, the CCV's inbound implementation verifies the attestation data when the OffRamp calls it during `execute()`.

Each CCV consists of a stable onchain **resolver** contract and one or more **versioned implementation** contracts. This pattern lets verification logic upgrade without changing the CCV address that token pools and receivers reference.

## When to Add CCVs

> **CAUTION: Keep the default verifier; add CCVs as defense in depth**
>
> CCIP verifies every message with its default **committee verifier**. Additional CCVs are defense in depth on top of
> it, not a replacement. The recommended security posture is to keep the committee verifier as your default CCV and
> require additional CCVs only where you need them. See [verification models](/ccip/concepts/ccvs/verification-models)
> and the [trust and responsibility model](/ccip/concepts/ccvs/trust-responsibility-model).

Consider additional CCVs when you need:

- **Additive security**: require issuer, institution, or third-party attestation alongside the default verifier
- **External proof sources**: integrate attestations from systems such as CCTP (USDC) or token-specific verification services
- **Policy layering**: combine stricter CCV requirements with Faster-Than-Finality (FTF) on specific lanes

CCV requirements are **additive**. The effective set for a message merges contributions from the sender, token pool, receiver, and lane configuration. All required CCVs must produce valid results before execution proceeds.

## Verification Models

CCIP ships with concrete CCV implementations and supports permissionless custom CCVs:

| Model                 | Operator          | Typical use                                      |
| :-------------------- | :---------------- | :----------------------------------------------- |
| **CommitteeVerifier** | CCIP (default)    | Standard DON-based quorum signatures             |
| **CCTPVerifier**      | Permissionless    | Circle CCTP attestation for USDC transfers       |
| **LombardVerifier**   | Permissionless    | Token-specific external attestation              |
| **Custom CCV**        | External operator | Institution or application-specific verification |

See [Verification Models](/ccip/concepts/ccvs/verification-models) for how each model produces attestations.

## Learn More

- [Verification Models](/ccip/concepts/ccvs/verification-models): Committee, CCTP, Lombard, and custom approaches
- [CCV Interfaces & Guarantees](/ccip/concepts/ccvs/interface-guarantees): Onchain/offchain contracts and protocol requirements
- [Trust & Responsibility Model](/ccip/concepts/ccvs/trust-responsibility-model): Operator and integrator accountability
- [Message Configuration (ExtraArgs)](/ccip/concepts/architecture/message-configuration-extraargs): Sender-side confirmation depth and execution parameters
- [Architecture Overview](/ccip/concepts/architecture/overview): Full message lifecycle and default verification path

> **CAUTION: Disclaimer**
>
> Chainlink CCIP is an interoperability messaging protocol. Chainlink does not hold or transfer any assets. The
> performance and behaviour of applications using Chainlink CCIP may depend on coding, engineering, configuration, and
> other technical implementation choices made by developers, token issuers, Cross-Chain Verifiers, and other
> participants. Users remain responsible for evaluating, configuring, testing, deploying, operating, and maintaining
> their own applications and integrations, including assessing any applicable operational, security, technical, and
> legal or regulatory risks. Please review the [Chainlink Terms of Service](https://chain.link/terms) which provides
> important information and disclosures. By using Chainlink CCIP, you expressly acknowledge and agree to accept these
> terms. Cross-Chain Verifiers (CCVs) may be operated by third parties. The security, availability, governance, and
> operational profile of a CCV varies depending on the verifier selected. Users are solely responsible for evaluating
> any CCVs used in connection with their applications or integrations and determining whether they are appropriate for
> their intended use case. This code represents an example of using a Chainlink product or service. It is provided "AS
> IS" and "AS AVAILABLE" without warranties of any kind, has not been audited, and may omit checks or error handling.
> Each party intending to use this reference implementation must perform its own audits, security and code review, and
> testing before any production deployment and ensure the operation and performance of such code matches expectations.
> Neither Chainlink Labs, the Chainlink Foundation, nor Chainlink node operators are responsible for outcomes due to
> errors in this example or how it is deployed or operated. Use of the Chainlink Network is subject to the Chainlink
> Foundation Terms of Service, which provides important information and disclosures. By using this code, you acknowledge
> and agree to these terms.