# CCIP Architecture - Overview
Source: https://docs.chain.link/ccip/concepts/architecture/overview
Last Updated: 2025-08-05

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

CCIP is a cross-chain messaging protocol built on Chainlink and secured by its decentralized oracle networks (DONs). It provides the following core capabilities:

- **Token Transfers**: Transfer tokens to an externally owned account (EOA) or a receiving contract.
- **Data Transmission**: Send arbitrary data (i.e., bytes) to a receiving contract.
- **Programmable Token Transfers**: Transfer tokens along with instructions for handling them to a receiving contract (referred to as a programmable token transfer or PTT).

CCIP supports several token transfer mechanisms—including Burn-and-Mint, Lock-and-Mint, and Lock-and-Unlock—using a common interface. Token developers can enable permissionless cross-chain transfers of their tokens via the Chainlink CCT (Cross-Chain Token) standard (detailed documentation is available here).

> \*\*NOTE: Terminology\*\*
>
>
>
> While this documentation references concepts like "smart contracts" and "Externally Owned Accounts (EOAs)", the implementation of these ideas varies across different blockchain families (e.g., EVM-based, Move-based, SVM-based). For instance:
>
> - In **EVM-based chains** such as Ethereum, "smart contracts" are code deployed on the EVM with logic called via functions. Smart contracts are stateful (they store their state internally), can receive both data and tokens directly, and execute code when called. [Externally Owned Accounts (EOAs)](https://ethereum.org/en/developers/docs/accounts/#types-of-account) are user-controlled addresses with private keys that can hold tokens but cannot execute code.
>
> - In **SVM-based chains** such as Solana, the equivalent to "smart contracts" are "programs," but they function differently. Programs are deployed code that executes when invoked through "instructions." Unlike EVM contracts, Solana programs are stateless—they store state in separate "accounts" that they have authority over (often [Program Derived Addresses or PDAs](https://solana.com/docs/core/pda)). On Solana, wallet accounts can hold tokens, but programs themselves cannot directly receive tokens. Instead, tokens are held in token accounts (often [PDAs](https://solana.com/docs/core/pda)) that programs can control. This separation of code, state, and token ownership is a fundamental architectural difference from EVM chains.

## High-level Architecture

CCIP delivers cross-chain messages from a source chain to a destination chain by combining offchain consensus and onchain execution components. The architecture is composed of two primary layers:

1. **Offchain Architecture**
   - Decentralized Oracle Network (DON) with nodes that perform distinct roles:
     - Commit: Observes and validates source-chain events to build a consensus-based report.
     - Execution: Validates pending messages and optimizes them for execution on the destination chain.

2. **Onchain Architecture**
   - Router:
     - Each blockchain has a single immutable Router contract that serves as the unified interface for users and decentralized applications (dApps).
   - On the source blockchain, onramp functionality consists of:
     - Providing fee estimates.
     - Locking or burning tokens.
     - Dispatching the message (data and/or tokens).
   - On the destination blockchain, offramping functionality consists of:
     - Accepting and verifying commit reports from the Committing DON.
     - Releasing or minting tokens to the receiver.
     - Routing the processed message to the designated receiver.

**Note:** These high-level descriptions outline the core principles of CCIP. The detailed architectures for offchain and onchain architecture—and variations across implementations (e.g., on Solana, the Router incorporates OnRamp functionalities)—can be found in the relevant documentation.

(Image: Image)