# What is Chainlink CCIP? The *Chainlink Cross-Chain Interoperability Protocol (CCIP)* provides a single simple interface through which dApps and web3 entrepreneurs can securely meet all their cross-chain needs, including token transfers and arbitrary messaging. Chainlink CCIP connects blockchain networks via **lanes.** The lane is a unique combination of source blockchain to destination blockchain path, e.g., from blockchain A to blockchain C. To transfer messages in reverse order, from blockchain C to blockchain A using Chianlink CCIP, you will need to use a different lane, the one which is unique to the C -> A path.

Example of bi-directional CCIP lanes between two blockchains

Chainlink CCIP will always support bi-directional lanes for each new chain added in the future. The logical question is how CCIP knows through which lane to transfer a CCIP cross-chain message. It's actually quite simple - each blockchain supported by CCIP has a unique **chain selector**.

## How you can use CCIP? We said multiple times that by using Chainlink CCIP, you can send **cross-chain messages**. But what can a cross-chain message consist of? With Chainlink CCIP, one can: * Transfer (supported) tokens * Send any kind of data * Send both tokens and data CCIP sender can be: * EOA * Any smart contract CCIP receiver can be: * EOA * Any smart contract that implements `CCIPReceiver.sol`

**Note**: If you send a message and token(s) to EOA, only tokens will arrive. The **Router** is the primary contract CCIP users interface with. This contract is responsible for initiating cross-chain interactions. One router contact exists per chain. When transferring tokens, callers have to approve the router contract to be able to "spend" (transfer) the caller's tokens. 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. ## Processing the CCIP Message

We will now see what the workflow of a CCIP Message looks like in a couple of steps. ### Step 1: Prepare 1. The Sender prepares a CCIP Message (`EVM2AnyMessage`) for their cross-chain transaction to a destination blockchain (`chainSelector`) of choice. A CCIP message includes the following information: * Receiver * Data payload * Tokens and amounts * Fee token * Additional parameters (`gasLimit`, `strict`) 2. The Sender calls `Router.getFee()` to receive the total fees (gas + premium) to pay CCIP and approves the requested fee amount. 3. The Sender calls `Router.ccipSend()`, providing the CCIP Message they want to send along with their desired destination `chainSelector`. In the case of token transfers, the amount to be transferred must be approved to the Router. ### Step 2: Send 1. The Router validates the received Message (e.g., valid and supported destination `chainId` and supported tokens at the destination chain). 2. The Router receives and transfers fees to the `OnRamp`. 3. The Router receives and transfers tokens to its corresponding Token Pool. If the sender has not approved the tokens to the Router, this will fail. 4. The Router forwards the Message to the correct `OnRamp` (based on destination `chainSelector`) for processing: * Validate the message (number of tokens, `gasLimit`, data length …) * \[For token transfers] Ensure that the transferred value does not hit the aggregate rate limit of the lane. * Sequence the message with a sequence number. * For each Token included in the Message: instruct the token pool to lock/burn the tokens. This will also validate the token pool rate limit for this lane. 5. The `OnRamp` emits an event containing the sequenced message. This triggers the DONs to process the message. 6. A `messageId` is generated and returned to the Sender. ### Step 3: Committing DON 1. Nodes in the Committing DON listen for events of Messages that are ready to be sent 2. Messages must be finalized to be considered secure against reorg attacks. 3. Triggered by time or number of messages queued in the `OnRamp`, the Committing DON creates a Report with a commitment of all messages ready to be sent, in a batch. This commitment takes the form of a Merkle Root 4. Upon consensus in the Committing DON, the Report containing the Merkle Root is transmitted to the `CommitStore` contract on the destination chain 5. The Risk Management Network “blesses” the Merkle Root in the `CommitStore`, to make sure it is a correct representation of the queued messages at the `OnRamp`. #### Merkle Root & Merkle Proof

* **Merkle Root:** the root hash of the Merkle Tree. It is a commitment to all the leaves (Messages `M1`-`M4`) in the tree. Each node in the tree is the hash of the nodes below it. * **Merkle Proof:** to prove that Message M1 is included in the Merkle Root (commitment), a Prover provides the following elements as proof to a Verifier (who only has the root hash): * `M1` * `H(M2)` * `H(H(M3),H(M4))` Using this Merkle Proof, a Verifier can easily verify that, indeed, `M1` is included in the commitment (root hash) that it possesses. ### Step 4: Executing DON 1. Nodes in the Executing DON listen for events of Messages that are ready to be sent, similar to the Committing DON 2. Messages must be **finalized** to be considered secure against reorg attacks. 3. In addition to the time or number of messages queued in the `OnRamp`, the Executing DON also monitors the `CommitStore` to make sure the messages are ready to be executed at the destination chain, i.e., are the messages included in a blessed on-chain commitment? 4. If conditions are met, the Executing DON creates a Report with all messages ready to be sent, in a batch. It accounts for the `gasLimit` of each message in its batching logic. It also calculates a relevant Merkle Proof for each message to prove that the message is included in the Merkle Root submitted by the Committing DON in the `CommitStore`. Note that Executing DON batches can be any subset of a Committing DON batch. 5. Upon consensus, the Report is transmitted to the `OffRamp` contract on the destination chain ### Step 5: Execute 1. For each message in the batch received, the `OffRamp` verifies using the provided Merkle Proof whether the transaction is included in the blessed commitment in the `CommitStore`. 2. If tokens are included in the transaction, the `OffRamp` validates the aggregate rate limit of the lane and identifies the matching Token Pool(s). 3. `OffRamp` calls the `TokenPool`’s `unlock`/`mint` function. This will validate the token pool rate limit, unlock or mint the token and transfer them to the specified receiver. 4. If the receiver is not an EOA and has the correct interface implemented, the `OffRamp` uses the Router to call the receiver’s `ccipReceive()` function 5. The receiver processes the message and is informed where the message comes from (blockchain + sender), the tokens transferred, and the data payload (with relevant instructions). 6. Based on the data payload, the receiver might transfer the tokens to the final recipient (end-user) ## CCIP as an International Flight Now, do you need to know in details how the processing of CCIP Message works? Absolutely not, you just need to send the cross-chain Message by interacting with the Router contract and Chainlink CCIP will deliver it, the same as when sending a package you just drop it at the Post Office, mark to whom you are sending it and pay for fees.

Just as international travel involves various checkpoints and procedures to ensure a safe and verified journey from one country to another, Chainlink CCIP ensures secure and verified communication between different blockchain networks. #### Pre-Boarding at JFK Airport: The Committing Phase Before any plane takes off, a series of rigorous checks are in place—mirroring the initiating phase of CCIP. Here, the **Router** acts as our check-in desk, where users present their cross-chain requests, akin to passengers confirming their flight details. Travelers check in their luggage, which is then handled by the airport staff. As with any luggage on a long-haul flight, the cross-chain message undergoes a meticulous security protocol. Similarly, in CCIP, the **OnRamp** contract checks the validity of the destination blockchain address, message size, gas limits, and sequence numbers, ensuring that the 'luggage' (or data payload) is prepared correctly for its journey. Passport and Visa verification are much comparable to the **Commit Store** smart contract, which stores the Merkle root of finalized messages and ensures they are 'blessed' by the Risk Management Network for authenticity and security before being executed on the destination chain. #### In-Flight: The Cross-Chain Transit During the flight, passengers and luggage are in transit, similar to the cross-chain message being propagated across networks. The **Executing DON** works behind the scenes, analogous to the flight crew, ensuring the smooth passage of the cross-chain interaction. As we know, the duration of a flight can vary - flying east might chase the sun, shortening our perceived day, while westward travel extends it. Similarly, the delivery time of a cross-chain message depends on the source blockchain finality. We remember from the CCIP Masterclass #1 that finality refers to the state of irreversibility and permanent record of a transaction on the blockchain. #### Touchdown at Barcelona Airport: The Executing Phase On arrival, the **OffRamp** contract ensures the message is authentic, verifying the proof against the committed and blessed Merkle root. Similarly to the final checks by the **Risk Management Network**, behind the scenes (unseen by the passenger) the suitcase or our cross-chain message undergoes various security checks, ensuring that the message adheres to the rules and regulations of the destination blockchain. Finally, the **Router** on the destination chain assumes the role of border control, delivering the message data and/or tokens to the receiver's address, akin to a traveler receiving their stamped passport and entering a new country. This entire process, while complex, remains largely invisible to the end-user, who simply experiences the seamless transfer of their digital assets from one blockchain to another. From the moment of check-in to the joy of retrieval, the journey of a cross-chain message through CCIP is a marvel of modern cryptography, ensuring that what we entrust to the network is what we receive. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://cll-devrel.gitbook.io/ccip-masterclass-2/getting-started/what-is-chainlink-ccip.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.