Cross-Chain Messaging

Introduction

Cross-chain messaging allows application developers to send messages (payload) along with a swap. These swaps are like any other but include a message to a receiver contract on the destination chain, via program or smart contract call.

As described in How Swapping Works, swaps in Chainflip can be initiated via requesting a deposit address or via a call to the Chainflip vault. Both of those methods support cross-chain messaging by defining additional data.

Chains supported

The following chains are supported for cross-chain messaging as destination chains:

• EVM Chains (Ethereum, Arbitrum)
• Solana
• Assethub

Implementation Checklist

• The destination chain needs to be a Chainflip supported CCM-compatible chain.
• The swap must be initiated by either requesting a deposit address or via Vault swap. Either way, the message and the gasBudget parameters must be supplied.
• For CCMs swaps to Solana, the ccm_additional_data is also required. See Solana CCM Additional data.
• The receiver contract on the destination chain needs to be a smart contract or program with the interface described for the destination chain, either EVM or Solana.
• The message must be shorter or equal than 15k bytes and will be passed along the swap completely unmodified from source chain to destination chain.
• The gas_budget represents the amount of gas or compute units that the user requests on the destination chain to execute user logic. The protocol will automatically add its gas requirements on top for the overhead of the transaction verification to make sure the requested gas budget is available for the user logic.
• As part of the broadcast fees, Chainflip will estimate the minimum amount of the destination asset needs to be subtracted to pay for the transaction cost, including the requested gas or compute units.
• The gas budget should to be enough to execute the receiver's contract logic on the destination chain. The estimation depends on the destination chain, EVM or Solana.

Depending on the destination chain there are some extra considerations that need to be taken into account. Check out EVM considerations and/or Solana considerations

Type Reference

CCM parameters must be passed in when requesting a deposit channel via request_swap_deposit_address or when encoding a Vault swap via request_swap_parameter_encoding() RPC call.

/// For CCM message
pub struct CcmChannelMetadata {
	/// A Vec of bytes with maximum length of 15_000. `BoundedVec<u8, ConstU32<15_000>>`
	pub message: CcmMessage,
	/// Gas requested for the execution of user logic on the destination chain.
	pub gas_budget: GasAmount,
	/// Additional parameters for the cross chain message. Only used for Solana CCM.
	/// A Vec of bytes with maximum length of 3_000. `BoundedVec<u8, ConstU32<3_000>>`
	pub ccm_additional_data: CcmAdditionalData,
}