CCIP Architecture - Key Concepts

This page explains the high-level, chain-agnostic concepts behind Chainlink CCIP. We recommend reading these concepts before diving deep into the architecture pages.

Prerequisites

Before diving into Chainlink CCIP, ensure you understand these fundamental blockchain concepts:

• Accounts / Addresses: Many blockchains distinguish between user-controlled addresses (called Externally Owned Accounts (EOAs) on EVM blockchains) and onchain program addresses (often called contract accounts in EVM ecosystems). Even if the name or the underlying account model differs, the principle is that a user's private key or authority controls one address (EOA) while the other is controlled by onchain code or logic (contract account).

• Smart Contracts: On EVM-based blockchains, these are pieces of logic (often written in languages like Solidity) that get compiled into bytecode and deployed onchain. Other blockchains—such as SVM-based (e.g., Solana) or MVM-based (e.g., Sui or Aptos) chains—may refer to these as "modules," "programs," or simply "onchain code." The basic idea is the same: executable code that lives on the blockchain and enforces rules without centralized control.

• Decentralized Applications (dApps): dApps are applications that use onchain logic to manage data and transactions.

• Token Standards: Many chains use standards (like ERC-20 on EVM-based blockchains) or equivalents (e.g., SPL tokens on Solana) to represent fungible tokens.

• Merkle Trees: A data structure that summarizes and verifies large information sets with small cryptographic proofs. To learn more, try this tutorial.

Blockchain Families

When you see references to "smart contracts" or "onchain programs," they are executed within a virtual machine (VM). Different blockchains implement different VMs with unique design choices:

• EVM (Ethereum Virtual Machine): Used by Ethereum and many other EVM-compatible chains. Contracts are typically written in languages like Solidity or Vyper, compiled to EVM bytecode, and executed in a single-threaded environment. Read this page to learn more.

• SVM (Solana Virtual Machine): Solana uses the Sealevel parallelization engine to execute onchain programs compiled to Berkeley Packet Filter (BPF) bytecode. This parallel processing approach can handle multiple simultaneous transactions. Read this page to learn more.

• MVM (Move Virtual Machine): Aptos, Sui, and other Move-based chains use the Move language and runtime. Move is designed to emphasize resource safety, access control, and predictable execution. Read this page to learn more.

Cross-Chain dApps

Cross-chain dApps are decentralized applications designed to run on—or interact with—multiple blockchains. By leveraging CCIP for cross-chain interoperability, these dApps can:

• Execute transactions, send data, and transfer tokens between different blockchains.
• Provide their users with access to features or liquidity across multiple ecosystems via a unified experience.
• Specialize in the strengths of each underlying chain, such as high throughput, low fees, or specialized contract (or module) functionality.

Because of this multi-chain support, cross-chain dApps can offer broader functionality than dApps confined to a single blockchain.

Blockchain Finality

Blockchain finality is the assurance that past transactions included on a given blockchain are extremely difficult or impossible to revert. Finality varies across different blockchains. Some blockchains offer instant finality, while others require multiple block confirmations.

Finality is crucial for cross-chain transfers, both for arbitrary messaging and non-intents-based token transfers. It ensures that funds are released/minted or that any specified action is executed on the destination chain only after the source chain action (such as a lock or burn) is finalized. This minimizes loss of funds (in the case of token transfers) or unintended actions (in the case of arbitrary messaging) due to source chain reorganizations.

To learn more about finality and how CCIP handles this, read the CCIP Execution Latency conceptual guide.

Lane

A lane in CCIP is a conceptual unidirectional path from one specific blockchain (the source) to another (the destination). For example, the lane from Blockchain A to Blockchain B is distinct from the lane from Blockchain B to Blockchain A. This concept helps in configuring settings that apply uniquely to each path, such as rate limits or other parameters. For instance, sending a message from an EVM blockchain to an SVM blockchain may require different parameters compared to sending a message in the reverse direction.

Node Operators

Organizations with specialized expertise in running Chainlink nodes. Each operator can run multiple nodes across different decentralized oracle networks.

Decentralized Oracle Network (DON)

A decentralized oracle network (DON) consists of multiple independent Chainlink nodes. These nodes monitor and retrieve data from specified sources (e.g., a source chain), reach consensus off-chain, and post results to a blockchain (e.g., a destination chain) in a trust-minimized manner. For more details on the DONs used in CCIP, refer to the CCIP Offchain architecture page.

Risk Management Network

The Risk Management Network is a unique architectural feature of CCIP that reinforces system security through a defense-in-depth approach based on established engineering principles such as N-version programming. On blockchains where RMN is enabled, a distinct set of node operators—separate from those of the core CCIP DONs—manages RMN functions.

The RMN runs a minimal, separate implementation of the Chainlink node software using a different programming language than the primary CCIP system. This client diversity enhances robustness and minimizes external dependencies, thereby reducing the risk of supply chain attacks.

On the blockchains where RMN is enabled, the RMN nodes independently verify and attest to source chain actions. The core CCIP components on the destination chain verify these attestations. For more details, refer to the following section.