What is Interchain Messaging?

Interchain Messaging (ICM), also known as Teleporter, is a protocol built on top of Avalanche Warp Messaging (AWM) that makes cross-chain communication simple and developer-friendly. While AWM provides the low-level signing and verification primitives, ICM adds a complete protocol layer that handles message formatting, delivery tracking, receipts, and fee management.

Layered Architecture

ICM follows a layered architecture:

┌─────────────────────────────────────────────────────┐
│              dApps / Token Bridges                    │
│         (ERC-20 Bridge, Native Token Bridge,         │
│              Custom Applications)                     │
├─────────────────────────────────────────────────────┤
│         ICM / Teleporter (Protocol Layer)             │
│    TeleporterMessenger · TeleporterRegistry           │
│    Message formatting · Delivery tracking · Fees      │
├─────────────────────────────────────────────────────┤
│       Avalanche Warp Messaging (AWM)                  │
│     BLS Signatures · Warp Precompile · P-Chain        │
│       Validator Signing · Verification                │
└─────────────────────────────────────────────────────┘

• AWM (Bottom Layer): Provides the cryptographic primitives — BLS multi-signatures, the Warp precompile, and P-Chain validator set tracking. This is the foundation that makes cross-chain verification trustless.
• ICM / Teleporter (Middle Layer): Adds a complete messaging protocol on top of AWM. The TeleporterMessenger contract handles encoding messages, tracking delivery with unique IDs, managing receipts, and coordinating fees. The TeleporterRegistry manages protocol versioning.
• dApps (Top Layer): Applications built on ICM, such as the ERC-20 Token Bridge and Native Token Bridge, or any custom cross-chain application. If you want to explore practical token bridging, check out the ERC-20 Bridge and Native Token Bridge courses.

TeleporterMessenger

The core of ICM is the TeleporterMessenger contract, deployed on every chain that participates in cross-chain communication. It provides a single entry point for sending messages via sendCrossChainMessage() and handles delivery on the receiving side.

Key responsibilities:

• Message sending: Accepts cross-chain messages with destination, payload, fee info, and gas requirements
• Delivery tracking: Assigns unique message IDs and tracks which messages have been delivered
• Receipt management: Generates receipts on the destination chain confirming delivery
• Fee coordination: Manages relayer fee deposits and reward claims

The TeleporterMessenger is deployed deterministically, meaning it has the same address on every chain. This simplifies cross-chain interactions since contracts always know where to find it.

ITeleporterReceiver

Any contract that wants to receive cross-chain messages must implement the ITeleporterReceiver interface. This is a single function that the TeleporterMessenger calls when delivering a message:

interface ITeleporterReceiver {
    function receiveTeleporterMessage(
        bytes32 originChainID,
        address originSenderAddress,
        bytes calldata message
    ) external;
}

This simple interface is all that's needed for a contract to participate in cross-chain communication. The TeleporterMessenger handles everything else — signature verification, replay protection, and delivery tracking.

What's Next

In the following pages, we'll dive into the details of how messages are encoded, sent, and received through ICM. Then we'll set up the full ICM infrastructure on your L1 and send your first cross-chain message using Console tools.