Understanding Chainlink CCIP in 15 bullet points
Tags: web3, chainlink, beginners, ccip
Published: 2023-12-31 17:55:49

So, it has been quite some while now that Chainlink has gone live on [testnet](https://docs.chain.link/ccip/supported-networks/v1_2_0/testne) with [Chainlink CCIP](https://chain.link/cross-chain) – its offering for cross-chain communication. I have had my eyes on it for quite some while now. At [EthIndia’23](https://twitter.com/bruv_wazzup/status/1733007978012246170/photo/1), I finally had the chance to build with it. 

Considering I have had a hiatus of sorts with Web3 articles, this would be the perfect way to come back with another one. This is the first article in a series of architecture where we will build something with Chainlink CCIP and we will do it end-to-end. 

But before we get on with the code and the mini-project, I feel some introduction is in order. I have always been a fan of concise articles (though my recent ones have been on the longer side). So, I thought why not try to explain Chainlink CCIP in 15 points. 

## Chainlink CCIP in 15 bullet points
Keep in mind that this is no substitute for the Chainlink Documentation. I would always refer my reader to it for an in-depth understanding. This is more of a [Traversy Media](https://www.youtube.com/@TraversyMedia)-like Crash Course for Chainlink CCIP. So here goes…

1. Chainlink CCIP uses a library called `Client` on top of which the `RouterClient` is built using the `IRouterClient` interface.
2. Extra payment as gas fees for cross-chain transactions is graciously accepted. It offers no refund.
3. On-Ramp is `sending message and/or token`. Off-Ramp is `receiving message and/or token`.
4. For the on-ramp, `IRouterClient` needs to be implemented.
5. There is a specific on-ramp contract for EVM-to-EVM messages. It is a specialized version of CCIP’s EVM to Any and implements `IEVM2AnyOnRamp`. The `IEVM2AnyOnRamp` inherits from `IEVM2AnyOnRampClient`. 
6. Similarly, there is a specific off-ramp contract for EVM-to-EVM messages. It is a specialized version of CCIP’s Any to EVM and implements `IAny2EVMOffRamp`.
7. The `IEVM2AnyOnRampClient` is similar to `IRouterClient` but with the difference that it is used only by the Router to route the message and spend the tokens while `IRouterClient` is called by the Initial sending contract.
8. Intuitively think of yourself as a passenger on a train with `IRouterClient` as the starting point, `IEVM2AnyOnRamp` as the first hop from where it goes to `IAny2EVMOffRamp` and then to the terminus `IAny2EVMMessageReceiver`. In between the `IEVM2AnyOnRamp` and `IAny2EVMOffRamp` there is an `IRouter` junction station. You, the passenger, are the message transported from the starting to the terminal station.
9. Chainlink provides an abstract contract called `ChainlinkReceiver`. This contract inherits but does not implement the `IAny2EVMMessageReceiver` interface. The idea is that the developer can override and implement the `_ccipReceive()` function with custom business logic. This is called by `ccipReceive()` external function defined in `ChainlinkReceiver` contract. Only the Router can call this external function (courtesy of the `onlyRouter()`) modifier defined in the contract.
10. A Contract inheriting `ChainlinkReceiver` needs to pass in the router address through constructor initialization. This address is defined as `immutable` in the `ChainlinkReceiver` contract. This means that once initialized, it cannot be changed. This is meant to provide gas optimization.
11. Where does the **“Risk Management Network”** come here? The RMN is a network of nodes that run parallel to the Chainlink CCIP infrastructure. It helps to make sure that the transactions arising from the source chain and terminating on the destination chain are valid. 
12. I will not go too deep into it. But if one were to try to understand it, picture a DAO where every node is a network and a CCIP transaction is a proposal. Every node has a weight (or “voting power”). If the Nodes “bless” (or vote “for”) the transaction (or “proposal”) to reach a quorum, then the transaction is valid. Otherwise, it is “cursed”. 
13. To be more precise, there is a Merkle root of transactions for each chain whose validity the RMN nodes need to decide. If a Merkle root is invalidated (or “cursed”), CCIP functions on that specific chain are paused. For most parts, Smart Contract Devs trying CCIP for applications won’t have to touch the RMN.
14. To know if a Cross-chain transaction is successful, one needs to browse the CCIP explorer. Once finality is achieved and indexed on the CCIP explorer, the destination smart contract will have received the intended message.
15. At this time, the token transfer is ERC20. It consists of the sender contract spending (or “burning”) the tokens on the source chain. The destination chain needs to mint the token independently.

## What’s next?
Well, next is the New Year. Best wishes for the upcoming year and may 2024 be the year my readers achieve their dev dreams. On a serious note, in the next article, we will dive into the Code for Chainlink CCIP and demo it with NFT token transfer and more. Till then, keep building awesome things on Web3 and WAGMI!