Chainlink's Cross-Chain Interoperability Protocol (CCIP) relies on a single immutable Router contract per blockchain as the sole user-facing entry point, a design choice aimed at preventing the trust-model failures that led to over $2.5 billion in cross-chain bridge exploits between 2021 and 2023. The Router's immutability ensures that integrations can hardcode its address, while internal contracts like OnRamp and OffRamp can be upgraded without breaking user-facing code. This architecture is part of a 28-day Chainlink series, with today's focus on the onchain components: Router, OnRamp, OffRamp, Token Pools, Fee Quoter, Token Admin Registry, and RMN Contract.
The Router: One Per Chain, Immutable
The Router is the single contract users and dApps call to estimate fees via `getFee()` or dispatch cross-chain messages and token transfers via `ccipSend()`. Its immutability is a deliberate security decision: if Chainlink needs to upgrade the OnRamp or OffRamp to add features, fix bugs, or respond to security findings, it can do so without changing the address that every integration, UI, and contract has bookmarked. The Router validates that the destination chain exists in its routing table and checks whether the destination chain is cursed (flagged as compromised) before processing any message, all before fees are collected or state is modified.
The OnRamp: Source-Chain Processing Per Lane
Each unidirectional lane between two chains has its own OnRamp contract on the source chain. When the Router forwards a `ccipSend` call, the OnRamp handles fee collection by calling the Fee Quoter, which calculates the precise fee based on message size, token count, destination gas limit, current gas prices, and LINK/ETH price. It validates parameters such as token count (capped at 10 per message) and gas limit, then checks `isCursed()` on the RMN Contract to ensure the destination is not under active monitoring. If tokens are included, it interacts with the relevant Token Pool to call `lockOrBurn`. After all checks pass, it assigns a sequence number, generates a unique message ID, and emits a `CCIPMessageSent` event. The OnRamp address can change with product updates, so integrating contracts should derive it from the Router rather than hardcoding it.
The OffRamp: Destination-Chain Processing Per Lane
The OffRamp is the destination-chain counterpart that only CCIP DONs can call. Processing happens in two phases: commit and execution. During the commit phase, the Committing DON calls `commit()` with a Commit Report containing a Merkle root of a batch of messages and price update data; the OffRamp stores this root and emits a `CommitReportAccepted` event without executing anything. During the execution phase, the Executing DON provides a Merkle proof for a specific message against a stored root. The OffRamp validates the proof, checks that the source chain is not cursed, and verifies message-level rate limits. If everything passes, it retrieves the relevant Token Pool from the Token Admin Registry and calls `releaseOrMint` for token transfers, or delivers arbitrary bytes to the receiver's `ccipReceive` function for data messages. If execution fails due to insufficient gas or a logic error, the message remains available for permissionless manual execution after a configured time delay, ensuring guaranteed delivery.
The Lane: Independent Configuration Per Direction
A Lane is the unidirectional path between two chains, with each direction configured independently. Each lane has its own settings for source-chain block confirmations (Ethereum mainnet typically uses 64 confirmations, roughly 13 minutes), supported tokens, rate limits per token per direction, and optional sender allowlists. This independence allows institutional deployments to tune risk parameters specifically: a lane connecting a bank's private chain to Ethereum for high-value settlements can have deeper finality, more conservative rate limits, and an allowlist, while a lane between two DeFi protocols can prioritize higher throughput without affecting other lanes.
Token Pools and Rate Limits: Capacity Bucket Model
Each token has its own Token Pool on each chain, deployed by token developers and independent of core CCIP contracts. The OnRamp and OffRamp use the Token Admin Registry to look up the correct pool before calling `lock/burn` or `release/mint`. Rate limits use a capacity bucket model: each pool has a maximum capacity and a refill rate. Transfers draw down capacity, and if insufficient capacity remains, the transfer is rejected until the bucket refills. Crucially, each token pool maintains two independent limits: an outbound rate limit (from this chain to a remote chain) and an inbound rate limit (from a remote chain into this chain), allowing asymmetric risk management.