CCIP Architecture and Billing

High-Level Architecture

Below is a diagram displaying the basic architecture of CCIP. Routers are smart contracts that provide a simple and consistent interface for users. Users can interact with routers to:

• Call smart contract functions on a different blockchain.
• Transfer tokens to a smart contract or Externally Owned Account (EOA) on a different blockchain.
• Send arbitrary messages and tokens within the same transaction. Use this functionality to transfer tokens and instructions on what to do with those tokens to a smart contract on a different blockchain.

CCIP terminology

CCIP enables a sender on a source blockchain to send a message to a receiver on a destination blockchain.

CCIP components

The figure below outlines the different components involved in a cross-chain transaction:

• Cross-Chain dApps are user-specific. A smart contract or an EOA (Externally Owned Account) interacts with the CCIP Router to send arbitrary data and/or transfer tokens cross-chain.
• The contracts in dark blue are the CCIP interface (Router). To use CCIP, users need only to understand how to interact with the router; they don't need to understand the whole CCIP architecture. Note: The CCIP interface is static and remains consistent over time to provide reliability and stability to the users.
• The contracts in light blue are internal to the CCIP protocol and subject to change.

On-chain components

Router

The Router is the primary contract CCIP users interface with. This contract is responsible for initiating cross-chain interactions. One router contract exists per chain. When transferring tokens, callers have to approve tokens for the router contract. The router contract routes the instruction to the destination-specific OnRamp.

When a message is received on the destination chain, the router is the contract that “delivers” tokens to the user's account or the message to the receiver's smart contract.

Commit Store

The Committing DON interacts with the CommitStore contract on the destination blockchain to store the Merkle root of the finalized messages on the source blockchain. This Merkle root must be blessed by the Active Risk Management before Executing DON can execute them on the destination blockchain. The CommitStore ensures the message is blessed by the Active Risk Management Network and only one CommitStore exists per lane.

OnRamp

One OnRamp contract per lane exists. This contract performs the following tasks:

• Checks destination-blockchain-specific validity such as validating account address syntax
• Verifies the message size limit and gas limits
• Keeps track of sequence numbers to preserve the sequence of messages for the receiver
• Manages billing
• Interacts with the TokenPool if the message includes a token transfer.
• Emits an event monitored by the committing DON

OffRamp

One OffRamp contract per lane exists. This contract performs the following tasks:

• Ensures the message is authentic by verifying the proof provided by the Executing DON against a committed and blessed Merkle root
• Makes sure transactions are executed only once
• After validation, the OffRamp contract transmits any received message to the Router contract. If the CCIP transaction includes token transfers, the OffRamp contract calls the TokenPool to transfer the correct assets to the receiver.

Token pools

Each token has its own token pool, an abstraction layer over ERC-20 tokens that facilitates OnRamp and OffRamp token-related operations. Token pools are configurable to lock or burn at the source blockchain and unlock or mint at the destination blockchain. The mechanism for handling tokens depends on the characteristics of the token in question. Here are a few examples:

• Blockchain-native gas tokens, such as ETH, MATIC, and AVAX, can only be minted on their native chains. These tokens cannot be burned on the source and minted at the destination to transfer these tokens between chains. Instead, the linked token pool uses a "Lock and Mint" approach that locks the token at its source and then mints a wrapped or synthetic asset on the destination blockchain. This synthetic asset represents the locked asset and is essential for redeeming the locked asset.
• A token like LINK is minted on a single chain (Ethereum mainnet) with a fixed total supply. CCIP cannot natively mint it on another chain. In this case, the "Lock and Mint" approach is required.
• Some tokens can be minted on multiple chains. Examples of such tokens include stablecoins like USDC, TUSD, USDT, and FRAX. The linked token pools use a "Burn and Mint" method to burn the token at its source and then mint it natively on the destination blockchain. Wrapped assets such as WBTC or WETH are other examples that use the "Burn and Mint" approach.
• A token with a Proof Of Reserve (PoR) feed on a specific chain poses a challenge for the "Burn and Mint" method when applied to other chains because it conflicts with the PoR feed. For these tokens, "Lock and Mint" is the preferred approach.

Token pools provide rate limiting, which is a security feature enabling token issuers to set a maximum rate at which their token can be transferred.

Active Risk Management (ARM) network contract

The ARM contract maintains the list of ARM nodes' addresses allowed to bless/curse and holds the quorum logic for blessing a committed Merkle Root and cursing CCIP on a destination blockchain. Read the ARM concepts to learn more.

Off-chain Components

Committing DON

The Committing DON has several jobs where each job monitors cross-chain transactions between a given source blockchain and destination blockchain:

• Each job monitors events from a given OnRamp contract on the source blockchain.
• The job waits for finality, which depends one the source blockchain.
• The job bundles transactions and creates a Merkle root. This Merkle root is signed by a quorum of oracles nodes part of the Committing DON.
• Finally, the job writes the Merkle root to the CommitStore contract on the given destination blockchain.

Executing DON

Like the Committing DON, the Executing DON has several jobs where each executes cross-chain transactions between a source blockchain and a destination blockchain:

• Each job monitors events from a given OnRamp contract on the source blockchain.
• The job checks whether the transaction is part of the relayed Merkle root in the CommitStore contract.
• The job waits for the Active Risk Management network to bless the message.
• Finally, the job creates a valid Merkle proof, which is verified by the OffRamp contract against the Merkle root in the CommitStore contract. After these check pass, the job calls the OffRamp contract to complete the CCIP transactions on the destination blockchain.

Separating commitment and execution permits the Active Risk Management network to have enough time to check the commitment of messages before executing them. The delay between commitment and execution also permits additional checks such as abnormal reorg depth, potential simulation, and slashing.

Saving a commitment is compact and has a fixed gas cost, whereas executing user callbacks can be highly gas intensive. Separating commitment and execution permits execution by end users in various cases, such as retrying failed executions.

Active Risk Management (ARM) network

The Active Risk Management (ARM) network is a set of independent nodes that monitor the Merkle roots committed by the Committing DON into the Commit Store.

Each node compares the committed Merkle roots with the transactions received by the OnRamp contract. After the verification succeeds, it calls the ARM contract to "bless"  the committed Merkle root. When there are enough blessing votes, the root becomes available for execution. In case of anomalies, each ARM node calls the ARM contract to "curse"  the system. If the cursed quorum is reached, the ARM contract is paused to prevent any CCIP transaction from being executed.

Read the ARM concepts page to learn more.

CCIP Billing

The CCIP billing model uses the feeToken specified in the message to pay a single fee on the source chain. CCIP uses a gas-locked fee payment mechanism, referred to as Smart Execution, to help ensure the reliable execution of cross-chain transactions regardless of destination chain gas spikes. For developers, this means you can simply pay on the source chain and CCIP will take care of execution on the destination chain.

On each source chain, CCIP maintains a cache of destination gas prices, denominated in each feeToken. To prevent staleness, these prices are routinely updated by either piggybacking user messages or timeouts. CCIP supports fee payments in LINK and in alternative assets, which currently includes blockchain-native gas tokens and their ERC20 wrapped versions. The payment model for CCIP is designed to significantly reduce friction for users and quickly scale CCIP to more blockchains by supporting fee payments that originate across a multitude of chains over time.

Overheads and fees

Users should note that CCIP fees include both gas cost overhead and a flat/basis points premium as follows:

• Destination gas overhead: This is the average overhead incurred on the destination chain by CCIP to process the message and/or token transfer.
• Flat network premium for messages: this fee is a static amount that users pay when sending cross-chain messages.
• Basis point based premium for tokens: This is a percentage-based fee that users pay for cross-chain token transfers. It is calculated using the following expression: tokenAmount x price x bps ratio. price is initially denominated in USD and translated into the feeToken.

Current CCIP premium fees are in line with industry standards within the cross-chain ecosystem, but these values are subject to change. The premium portion of fees paid in alternative assets will have a surcharge of 10% when compared to LINK payments. To understand service limits, read the CCIP Service Limits page.

Execution latency

If the fee paid on the source chain is within an acceptable range of the execution cost on the destination chain, the message will be transmitted as soon as possible after it is blessed by the ARM Network. If the cost of execution increases between request and execution time, CCIP will incrementally increase the gas price to attempt to reach eventual execution, but this might introduce additional latency.

Execution delays in excess of one hour should be rare as a result of Smart Execution. The permissionlessExecutionThresholdSeconds parameter represents the waiting time before manual execution is enabled. If the DON fails to execute within the duration of permissionlessExecutionThresholdSeconds due to extreme network conditions, a user can manually execute their message. If a user wishes to execute in such circumstances, they can manually execute the message through the CCIP Explorer.