What is ICM?

Learn about Avalanche Interchain Messaging, a protocol for cross-chain communication.

Avalanche Interchain Messaging (ICM) enables native cross-Avalanche L1 communication and allows Virtual Machine (VM) developers to implement arbitrary communication protocols between any two Avalanche L1s.

Use Cases

Use cases for ICM may include but is not limited to:

Oracle Networks: Connecting an Avalanche L1 to an oracle network is a costly process. ICM makes it easy for oracle networks to broadcast their data from their origin chain to other Avalanche L1s.
Token transfers between Avalanche L1s
State Sharding between multiple Avalanche L1s

Elements of Cross-Avalanche L1 Communication

The communication consists of four steps: signing, aggregation, delivery and verification. Figure 1 shows signing, aggregation and verification.

Validators of the origin L1 sign one Warp message. A signature aggregator, for example a relayer, aggregates the signatures into one BLS signature. The destination L1 accepts the message only if the signers hold 67% or more of the stake weight, the default quorum.

Signing Messages on the Origin Avalanche L1

ICM is a low-level messaging protocol. Any type of data encoded in an array of bytes can be included in the message sent to another Avalanche L1. ICM uses the BLS signature scheme, which allows message recipients to verify the authenticity of these messages. Therefore, every validator on the Avalanche network holds a BLS key pair, consisting of a private key for signing messages and a public key that others can use to verify the signature.

Off-Chain Signature Aggregation

BLS can aggregate the signatures of many signers into one multi-signature. This aggregation happens off chain: no block records it. A signature aggregator, for example a relayer, requests a signature from the validators of the origin L1. It aggregates the signatures into one BLS signature and records the signers in a bit set (Figure 1). The VM sets the aggregation method, for example VM-to-VM messages or an off-chain relayer. The destination L1 then verifies one short signature, not one signature for each validator.

Delivery of Messages to the Destination Avalanche L1

The messages do not pass through a central protocol or trusted entity, and there is no record of messages sent between Avalanche L1s on the primary network. This avoids a bottleneck in Avalanche L1-to-Avalanche L1 communication, and non-public Avalanche L1s can communicate privately.

It is up to the Avalanche L1s and their users to determine how they want to transport data from the validators of the origin Avalanche L1 to the validators of the destination Avalanche L1 and what guarantees they want to provide for the transport.

Verification of Messages in the Destination Avalanche L1

When an Avalanche L1 wants to process another Avalanche L1's message, it will look up both BLS Public Keys and stake of the origin Avalanche L1. The authenticity of the message can be verified using these public keys and the signature.

The destination L1 sets the quorum: the part of the stake weight of the origin L1 that must sign a message. On Subnet-EVM, the quorum is quorumNumerator in the warpConfig of the Warp precompile, out of 100. The default is 67, and a value of 0 also means 67. The minimum is 33 and the maximum is 100. The C-Chain uses the default, 67. One value applies to the messages from all origin L1s. For example, L1 A sets quorumNumerator to 70. Then L1 A accepts a message from L1 B only if validators with 70% or more of the stake weight of L1 B signed it. For a message from the C-Chain or the X-Chain, the destination L1 uses its own validator set, unless requirePrimaryNetworkSigners in its warpConfig is true. The P-Chain uses a fixed quorum of 67/100 for the Warp messages in RegisterL1ValidatorTx and SetL1ValidatorWeightTx.

Since both the public keys and stake weights of all validators are recorded on the primary network's P-Chain, they are readily accessible to any virtual machine run by the validators. Therefore, the Avalanche L1s do not need to communicate with each other about changes in their respective sets of validators. Each L1 reads the validator set of the origin L1 from the P-Chain, at the P-Chain height in the ProposerVM header of its block. Therefore, ICM introduces no additional trust assumption other than that the validators of the origin Avalanche L1 are participating honestly.

Reference Implementation

XSVM is a proof-of-concept VM in the AvalancheGo repository. It shows how a VM uses ICM. XSVM transfers assets between any two Avalanche L1s that run it.