CCIP Architecture Overview

The Chainlink Cross-Chain Interoperability Protocol (CCIP) lets users and applications securely send data and tokens from one blockchain to another. CCIP v2 features an upgraded architecture, designed to provide secure-by-default, institutional-grade cross-chain security by combining audited onchain smart contracts, a default Committee Verifier network composed of 16 independent node operators on every lane, and optional Cross-Chain Verifiers (CCVs) for additive verification where required. Together, these security measures enable messages to be proven on the source chain and delivered on the destination chain without relying on a single trusted party.

This page begins with an overview of CCIP v2, before explaining each component and providing an end-to-end example of a cross-chain message.

Overview

• Secure-by-default design — Messages and tokens sent over CCIP are verified by a decentralized Committee Verifier network by default, which is secured by the same proven Chainlink Decentralized Oracle Network (DON) infrastructure that has enabled trillions in transaction value across DeFi. The Committee Verifier is composed of 16 independent node operators, providing a strong security floor without requiring developers to be cross-chain infrastructure security experts.
• Additive security — Additional independent Cross-Chain Verifiers (CCVs) can be configured by developers through lane configuration, token pool requirements, or receiver requirements when an extra attestation is required. CCVs are permissionless to operate and configure, and enable developers and institutions to meet bespoke security, compliance, and operational requirements.
• Permissionless execution — Once valid attestations are generated by CCVs, any party can complete message delivery on the destination chain in a permissionless manner. The Chainlink executor is offered as the default, convenient option, but any executor can be used for destination-chain message delivery.
• Stable entry points — The Router contract address stays fixed across upgrades, while OnRamp and OffRamp contracts can be swapped behind it to introduce new features and capabilities.

Key concepts

These terms appear throughout CCIP v2.

How the pieces fit together

CCIP v2 splits work across three layers. Each has a distinct role; none alone is unilaterally trusted to deliver a message.

Source chain (outbound)

The application interacts with the Router — the stable entry point on the source chain. The Router checks that the destination chain is supported and that the lane is not cursed, collects fees, directs any tokens to their pools, and forwards the request to the OnRamp.

The OnRamp is the protocol's outbound gatekeeper. It assembles the final verifier and executor set for the message, distributes fees, routes token handling to the token pools that lock or burn tokens, registers the message with each required CCV, and emits an event that offchain services watch.

Supporting contracts on the source chain include the Fee Quoter (pricing), the Token Admin Registry (which pool serves each token), token pools (lock or burn tokens during a transfer — one pool per token, deployed by the token issuer), and an Executor contract (quotes execution fees and confirms it can service the message). Each lane configures a default executor; senders may opt out per message via a no-execution address.

Offchain (attestation)

Cross-Chain Verifiers (CCVs) provide independent verification: each monitors source-chain events separately, waits until the message meets its finality requirement (full finality by default, or faster-than-finality if explicitly opted into), checks curse status, and publishes its own attestation tied to the message ID.

• Committee Verifier (Chainlink DON) — a decentralized network of 16 independent node operators where each node independently signs and posts results to an Aggregator, which assembles quorum proofs.
• Additional CCVs — operate independently of the Committee Verifier network. Each has its own offchain service and attestation path; some are tied to specific tokens and apply only when those tokens are transferred. CCVs are permissionless to operate and configure.

The Indexer merges attestations from the Aggregator and other verifier services by message ID, giving executors a single place to look. Executors may bypass the indexer and query verifiers directly. The verifier endpoint addresses are available on the verifier implementation contracts.

Destination chain (inbound)

The OffRamp is the permissionless execution endpoint. Anyone can submit a message with its attestations. The OffRamp does not trust the submitter's verifier list — it re-derives the required CCVs from the receiver (if applicable), token pool, and lane configuration, then verifies each attestation onchain. Only after cryptographic signature verification succeeds does it release or mint tokens and deliver data to the receiver via the Router.

Onchain components

Onchain CCIP contracts fall into three groups: the core protocol contracts every lane depends on, the fee and token infrastructure that supports transfers, and the security and execution contracts that extend verification and delivery.

Core protocol contracts

These three contracts form the backbone of every lane.

Router

The Router is the stable entry point for applications. Its address does not change when ramp contracts are upgraded.

When this chain is the source of a message, the Router validates that the destination chain is supported, checks curse status, collects fees, transfers tokens to their pools, and forwards the message to the OnRamp.

When this chain is the destination of a message, the Router sits between the OffRamp and the receiver. Only registered OffRamps may trigger delivery, and gas for the receiver callback is strictly enforced.

OnRamp

The OnRamp is the outbound gatekeeper. When it receives a message from the Router, it:

• Validates the sender, destination, and receiver address format.
• Builds the final verifier list by merging sender preferences, lane defaults, lane-mandated verifiers, and token-pool requirements — applying lane defaults wherever a layer does not specify its own.
• Selects the executor and confirms all participants accept the message (finality level, verifier set, destination).
• Computes total fees, confirms the sender paid enough, and distributes payments to each CCV, the pool, the executor, and the network fee.
• Instructs token pools to lock or burn tokens.
• Registers the message with each required CCV and collects attestation hints for offchain nodes.
• Encodes the full message, assigns a per-lane sequence number, computes the message ID, and emits an event that offchain services watch.

Curse checks and reentrancy guards apply throughout. Only one token transfer is permitted per message.

OffRamp

The OffRamp is the inbound execution endpoint. Any party can submit a message for execution by providing the encoded message and verifier attestation data.

Before executing, the OffRamp:

• Confirms the source chain is enabled and the originating OnRamp address is on the allowlist.
• Confirms the message is addressed to this OffRamp on this chain.
• Re-derives the required verifier set from the receiver contract (if the message has a callback), the token pool, and lane configuration — then merges and deduplicates them. Receivers can also specify optional verifiers with a quorum threshold.
• Verifies each attestation against the corresponding onchain CCV contract.

Then, for token transfers, it confirms the CCVs verified the transfer and instructs the pool to release or mint tokens to the recipient. For messages with a receiver callback, it delivers the payload via the Router with exact gas enforcement. Pure token-only transfers (no data, no callback) skip the receiver call.

Execution state is tracked per message ID: a successful execution cannot be repeated; a failed one can be retried. Curse status is checked before any execution proceeds.

Fees and token infrastructure

These contracts support pricing, token registration, and cross-chain token movement.

Fee Quoter

The Fee Quoter is the pricing engine for CCIP fees. It stores token and gas price data and per-destination fee configuration. When a message is sent, the OnRamp queries the local Fee Quoter to compute the total fee in the sender's fee token. It also enforces message size limits — maximum payload, gas limit, and token count.

Token Admin Registry

The registry maps Cross-Chain Tokens (CCTs) to their token pools. Token issuers register and manage their own pool assignments without protocol-owner intervention. Each token has a designated administrator (typically the issuer) who can assign or update the pool. Pointing a pool to the zero address removes the token from CCIP. Administrator transfers use a two-step accept pattern.

Registry Module

A permissionless helper that lets token issuers prove admin ownership of their token and register themselves in the Token Admin Registry. The module verifies the caller's admin claim directly against the token contract (via a CCIP-specific admin interface, standard ownership, or access control). On success, the caller is submitted as a pending administrator and must accept the role to complete registration.

Token pool

Token pools are the custody layer for cross-chain token movement.

• Source: Locks or burns tokens when instructed by the OnRamp.
• Destination: Releases or mints tokens when instructed by the OffRamp.

Each token has at most one pool per chain. Pools validate callers against the Router's registered ramp addresses, so they remain compatible with ramp upgrades. Both directions check curse status and enforce per-chain rate limits.

CCIP v2 pools can declare required verifiers, custom fee configurations, and finality policies for their token; V1 pools fall back to lane defaults. V2 pools also maintain separate rate-limit buckets for faster-than-finality transfers. Cross-chain decimal differences are handled automatically, though rounding may leave the recipient with slightly less than was sent.

An optional advanced hooks contract can add sender allowlists, verifier management, or external policy integration.

Security

CCIP's security layer combines Cross-Chain Verifiers (CCVs) for message attestation with the RMN contract as an onchain emergency safeguard. Every CCIP v2 lane includes a default, decentralized Committee Verifier network as the baseline verification layer. The Committee Verifier is composed of 16 independent node operators to provide a strong security floor by default. Additive verification is available by configuring additional CCVs, layered on by lane, token pool, or receiver requirements when extra attestation is required.

Cross-Chain Verifiers (CCVs)

Each CCV consists of a stable resolver contract and one or more versioned implementations behind it. The resolver address never changes; implementations can be upgraded.

• Source chain (outbound): The resolver routes to the outbound implementation for the destination chain. The implementation registers the message with the offchain verifier service and returns attestation hints.
• Destination chain (inbound): The resolver reads a version tag embedded in the attestation data and routes to the correct inbound implementation, which verifies the proof before allowing execution.

Only the registered OnRamp may call a CCV's outbound functions; only a registered OffRamp may call its inbound functions. The CCV checks the caller against the Router's ramp registry — no other contract can invoke these paths. Each CCV quotes fees, enforces a finality policy, checks curse status, and carries an immutable version tag that prevents attestations from one verifier version being replayed in another.

Committee Verifier — destination verification

On the destination chain, the Committee Verifier is the onchain gate that turns offchain committee attestations into a hard check before any tokens are released or data is delivered. The OffRamp calls it only after it has independently confirmed that the Committee Verifier CCV is in the required set for this message; the CCV itself does not decide whether it is required — it decides whether the submitted proof is valid.

The flow has three layers:

1. Resolver routing — The submitter passes the stable CCV resolver address in the ccvs array and the proof bytes in the matching verifierResults entry. The resolver reads the first four bytes of the proof (the version tag issued on the source chain) and forwards to the registered inbound implementation for that version. If no implementation is registered, execution reverts before any signature check runs.
2. Proof contents — The proof encodes the version tag, a two-byte signature-length field, and a concatenation of ECDSA signatures. The version tag is part of the signed data, so a proof cannot be retargeted to a different verifier implementation after signing.
3. Cryptographic validation — The inbound Committee Verifier implementation checks, in order:
   • The source chain is not cursed (RMN check).
   • The version tag in the proof matches this implementation's expected tag.
   • The proof is well-formed (signature length matches the bytes provided).
   • At least quorum valid signatures exist over hash(versionTag ‖ messageId), where message ID is the hash of the full encoded message the OffRamp decoded. Because the message ID commits to the entire payload, a proof for one message cannot authorize another.
   • Each recovered signer is in the allowlisted committee for that source chain, and signatures are strictly ordered by signer address with no duplicates.

If any check fails, the entire execution reverts. CCV verification always completes before token release or receiver delivery. Additional CCV types follow the same resolver pattern but validate their own proof formats instead of committee ECDSA quorum.

For the step-by-step execution flow and function names, see CCIP Message Lifecycle.

Verifier requirements come from five layers, merged on send and re-derived on execute. Lane defaults are configured per lane and act as the fallback whenever another layer does not specify its own verifiers.

1. Sender preferences — optional overrides at send time.
2. Lane defaults — the fallback when a layer above does not specify verifiers: applied when the sender omits a verifier list (including legacy senders), when a receiver has no v2 interface or returns an empty configuration, and when a token pool has no pool-specific requirements (V1 pools always fall back to lane defaults; V2 pools fall back when they return none). For token-only transfers, lane defaults are not applied at the sender layer unless explicitly requested — but they can still apply via the token pool when the pool falls back to defaults.
3. Lane-mandated — always required for every message on the lane, regardless of what other layers specify.
4. Token pool — required by the token's pool; V2 pools can declare their own verifiers, while V1 pools and unconfigured V2 pools fall back to lane defaults.
5. Receiver — required or optional verifiers declared by the destination receiver contract (v2 receivers only); legacy receivers fall back to lane defaults.

RMN Contract

The RMN contract consists of an RMN Proxy and RMN Remote. The proxy is the stable address that Router, OnRamp, OffRamp, token pools, and CCVs use for curse-status checks — it forwards calls to the RMN Remote implementation behind it. The RMN Remote holds a registry of cursed subjects (typically chain selectors) that act as emergency stops; subjects can be cursed or uncursed, and when a subject is cursed, affected operations revert.

Execution

CCIP provides a default Executor service for automated destination-chain delivery, which can be opted out of. Destination-side execution itself is permissionless — the application or any party can complete delivery on the destination chain once the required attestations exist.

Executor

The Executor is an onchain contract operated by an execution service. During fee computation the OnRamp queries it for a per-destination execution fee. The Executor validates that it can service the message — supported destination, acceptable finality, allowed verifiers (if allowlisting is enabled). If it cannot, the send reverts.

Each lane configures a default executor. Fees accumulate on the executor contract and are swept to a fee aggregator.

Senders who do not want automated execution can specify a reserved no-execution address — in that case no execution fee is charged and no executor participates in the send path.

The executor chosen at send time governs automation fees only — which Executor contract is paid to run the default execution service. It does not restrict who may call the OffRamp on the destination chain. Once the required attestations exist, the application or any party can perform destination-side execution directly by submitting the encoded message and verifier results to the OffRamp and paying destination-chain gas. The default executor service automates this step but is not required to complete delivery. Executor-address allowlisting, if desired, can be achieved via application-level controls.

Offchain components

The offchain system bridges the source-chain send event and destination-chain execution. It produces attestations, collects them into a queryable store, and drives automated delivery through the default executor service.

Four components work in sequence.

Verifier services

Each CCV type has a corresponding offchain verifier service. All follow the same event-driven pipeline:

1. Monitor the source chain for send events from the OnRamp.
2. Filter for receipts issued by their CCV's onchain resolver contract.
3. Wait until the message meets the verifier's finality requirement (full finality by default, or faster-than-finality if explicitly opted into and supported by that verifier's onchain policy).
4. Check curse status — cursed lanes are not attested.
5. Produce and publish an attestation bound to the message ID.

This is independent verification — each CCV type monitors, waits, and attests separately.

Committee Verifier (default on every lane): a Chainlink decentralized oracle network (DON) composed of 16 independent node operators. Each node independently signs over the message ID and posts its result to the Aggregator. Multiple nodes operate on the same messages; the Aggregator assembles a quorum result. For faster-than-finality messages, nodes hold the attestation if a reorg occurs before full finality is reached.

Additional CCVs: Independent verification services for additional attestations as required. Each operates independently of the Committee Verifier through its own offchain service and attestation path. Some are tied to specific tokens and only apply when those tokens are transferred. Results are exposed through each verifier's own storage or API.

The finality modes a verifier accepts are governed onchain by that verifier's own policy — not by the offchain service alone. For more on finality tradeoffs, see Execution Latency.

Aggregator

The Aggregator is used exclusively by the Committee Verifier. Each committee node posts its signed attestation over an authenticated channel. The Aggregator validates the signature, persists the record, and checks whether accumulated signatures for a message meet the quorum threshold for the source chain. When quorum is reached, it stores the combined result. Because signed attestations from Committee Verifier nodes are cryptographically verified onchain, the Aggregator cannot alter them without invalidating the proof and therefore does not affect CCIP's security model.

Two read paths:

• By message ID — fetch the assembled result for a specific message.
• By sequence cursor — poll incrementally for all new results since the last checkpoint.

Results are publicly readable. The Indexer and executor services use these APIs to discover Committee Verifier attestations.

Indexer

The Indexer collects attestations from the Aggregator and from other configured verifier services, and stores them in a single queryable store keyed by message ID. This gives executor services one place to check whether a message is ready for delivery, without needing to know which CCV types a message used or where each verifier stores its results.

When a new message appears, the Indexer checks which attestations are still missing and fetches them — from the Aggregator for Committee Verifier results, and from each additional verifier's API for other CCV types. Missing attestations are retried.

Verifier results from known CCVs in the Indexer's configuration are collected. Executor services may bypass the Indexer and query verifier services directly. Similar to the Aggregator, the Indexer cannot alter signed attestations from the Committee Verifier without invalidating the proof, and therefore does not affect CCIP's security model.

Executor service

The default executor service automates destination-chain delivery. It watches the Indexer for messages whose required attestations are ready, then submits them to the OffRamp.

For each message, the service:

• Checks curse status and whether the message has already been executed onchain.
• Fetches attestation results and the required CCV policy from the OffRamp.
• Confirms all required CCVs are present and optional thresholds are met.
• Submits the message and attestations to the OffRamp.

If another party has already successfully executed the message, the service skips it. Failed attempts are retried within a configured window. If a message's receiver CCV requirements can never be satisfied as sent, the default service permanently skips it — though manual execution via the OffRamp remains possible if the policy is later corrected.

This service automates delivery; it is not required. The application or any party can perform destination-side execution directly once attestations exist, because execution is permissionless (see Execution above).

For a step-by-step walkthrough of a single message from send to delivery — including function names and event references — see CCIP Message Lifecycle.