CCIP Best Practices

Before you deploy your cross-chain dApps to mainnet, make sure that your dApps follow the best practices in this document. You are responsible for thoroughly reviewing your code and applying best practices to ensure that your cross-chain dApps are secure and reliable. If you have a unique use case for CCIP that might involve additional cross-chain risk, contact the Chainlink Labs Team before deploying your application to mainnet.

Verify destination chain

Before calling the router's ccipSend function, ensure that your code allows users to send CCIP messages to trusted destination chains.

Example: For an example of how to verify the destination chain, refer to the Transfer Tokens with Data - Defensive example.

Verify source chain

When implementing the ccipReceive method in a contract residing on the destination chain, ensure to verify the source chain of the incoming CCIP message. This verification ensures that CCIP messages can only be received from trusted source chains.

Example: For an example of how to verify the source chain, refer to the Transfer Tokens with Data - Defensive example.

Verify sender

When implementing the ccipReceive method in a contract residing on the destination chain, it's important to validate the sender of the incoming CCIP message. This check ensures that CCIP messages are received only from trusted sender addresses.

Note: Depending on your use case, this verification might not always be necessary.

Example: For an example of how to verify the sender of the incoming CCIP message, refer to the Transfer Tokens with Data - Defensive example.

Verify router addresses

When you implement the ccipReceive method in the contract residing on the destination chain, validate that the msg.sender is the correct router address. This verification ensures that only the router contract can call the ccipReceive function on the receiver contract and is for developers that want to restrict which accounts are allowed to call ccipReceive.

Example: For an example of how to verify the router, refer to the Transfer Tokens with Data - Defensive example.

Using extraArgs

The purpose of extraArgs is to allow compatibility with future CCIP upgrades. To get this benefit, make sure that extraArgs is mutable in production deployments. This allows you to build it offchain and pass it in a call to a function or store it in a variable that you can update on-demand.

If extraArgs are left empty, a default of 200000 gasLimit will be set.

Setting gasLimit

The gasLimit specifies the maximum amount of gas CCIP can consume to execute ccipReceive() on the contract located on the destination blockchain. It is the main factor in determining the fee to send a message. Unspent gas is not refunded.

To transfer tokens directly to an EOA as a receiver on the destination blockchain, the gasLimit should be set to 0 since there is no ccipReceive() implementation to call.

To estimate the accurate gas limit for your destination contract, consider the following options:

• Leveraging Ethereum client RPC by applying eth_estimateGas on receiver.ccipReceive(). You can find more information on the Ethereum API Documentation and Alchemy documentation.
• Conducting Foundry gas tests.
• Using Hardhat plugin for gas tests.
• Using a blockchain explorer to look up the gas consumption of a particular internal transaction.

Example: For an example of how to estimate the gas limit, refer to the Optimizing Gas Limit Settings in CCIP Messages guide.

Setting allowOutOfOrderExecution

The allowOutOfOrderExecution parameter enables you to control the execution order of your messages on the destination blockchain. This parameter is part of EVMExtraArgsV2 and is available only on lanes where the Out of Order Execution property is set to Optional or Required. Refer to the Supported Networks page to determine if your target lane supports this feature.

Best Practices

• When allowOutOfOrderExecution is Optional:

  • You can set allowOutOfOrderExecution to either true or false, depending on your application's requirements.
    • true: Messages can be executed in any order relative to other messages from the same sender. If a previous message has not yet been executed on the destination chain, it does not block the execution of subsequent messages.
    • false: Messages are executed in order. CCIP ensures that preceding messages are processed before executing the current message.

• When allowOutOfOrderExecution is Required:

  • You must set allowOutOfOrderExecution to true. This setting acknowledges that messages may be executed out of order. If set to false, the message will revert and will not be processed.
  • This requirement is enforced on lanes where technical constraints necessitate out-of-order execution, such as mitigating issues related to zero-knowledge proof limitations. For more information, see the proof overflow problem.

Decoupling CCIP Message Reception and Business Logic

As a best practice, separate the reception of CCIP messages from the core business logic of the contract. Implement 'escape hatches' or fallback mechanisms to gracefully manage situations where the business logic encounters issues. To explore this concept further, refer to the Defensive Example guide.

Evaluate the security and reliability of the networks that you use

Although CCIP has been thoroughly reviewed and audited, inherent risks might still exist based on your use case, the blockchain networks where you deploy your contracts, and the network conditions on those blockchains.

Review and audit your code

Before securing value with contracts that implement CCIP interfaces and routers, ensure that your code is secure and reliable. If you have a unique use case for CCIP that might involve additional cross-chain risk, contact the Chainlink Labs Team before deploying your application to mainnet.

Soak test your dApps

Be aware of the Service Limits and Rate Limits for Supported Networks. Before you provide access to end users or secure value, soak test your cross-chain dApps. Ensure that your dApps can operate within these limits and operate correctly during usage spikes or unfavorable network conditions.

Monitor your dApps

When you build applications that depend on CCIP, include monitoring and safeguards to protect against the negative impact of extreme market events, possible malicious activity on your dApp, potential delays, and outages.

Create your own monitoring alerts based on deviations from normal activity. This will notify you when potential issues occur so you can respond to them.