How Does Hyperlane Cross-Chain Messaging Work? The Complete Process from Sending to Delivery

Hyperlane Cross-Chain Message Passing (General Message Passing, GMP) is a standardized process that can be executed repeatedly between any supported chains: the application calls the dispatch function on the origin chain's Mailbox to send a message, an off-chain relayer submits the message along with verification metadata to the destination chain, and after verification by the Interchain Security Module (ISM), the Mailbox calls the handle function on the recipient contract to complete delivery. Hyperlane (HYPER) describes the overall framework of the Hyperlane interoperability layer through three components: Mailbox, ISM, and Warp Route.

In multi-chain applications, developers need to understand the complete path from message dispatch to delivery in order to properly configure security modules, estimate fees, and troubleshoot undelivered messages. ISM and Warp Route explains the division of labor between ISM types (such as Multisig and Aggregation) and Warp Route, helping developers choose the appropriate verification strength during the process phase.

Each cross-chain message has a globally unique messageId, and the Mailbox maintains a mapping of delivered messages to prevent replay attacks. Hyperlane vs LayerZero vs Wormhole compares the structural differences among the three protocols in terms of message verification paths and deployment permissions. The message sender prepays the destination chain delivery fee on the origin chain via Interchain Gas Payment (IGP); the relayer pays the gas on the destination chain to complete the process call. The Explorer can trace the full lifecycle of a message from dispatch to process.

What Are the Stages of Hyperlane Cross-Chain Message Passing?

The Hyperlane cross-chain message flow can be summarized into six consecutive stages: dispatch (sending on the origin chain), Merkle tree writing, validator signing (if required by the ISM), relayer indexing and metadata collection, process (submission on the destination chain), and ISM verification with handle (delivery on the destination chain). This flow does not depend on a specific application or a one-time event; any contract integrated with Mailbox can trigger it repeatedly.

The table above shows the complete stage breakdown of Hyperlane GMP from origin chain to destination chain. Dispatch and delivery occur on the Mailbox contracts of the respective chains. Relayers and validators perform off-chain transmission and security attestation functions, while the ISM acts as the message verification gateway on the destination chain.

Figure 1. Hyperlane cross-chain message flow overview: Complete path from origin chain dispatch, through relayer/validator, to destination chain ISM verification and handle delivery.

How Is a Message Sent During the Origin Chain Dispatch Phase?

The origin chain dispatch phase is triggered by the sender contract calling Mailbox.dispatch(). The Mailbox receives three core parameters: destination chain domain ID (destinationDomain), recipient address (recipientAddress, encoded as bytes32), and the message body (messageBody). The Mailbox prepends a standard message header to the body, which includes fields such as version, nonce, origin, sender, destination, and recipient, ensuring the message is uniquely identifiable and tamper-proof.

After dispatch executes, the Mailbox inserts the full message as a leaf into an incremental Merkle tree (maintained by the MerkleTreeHook contract) and emits Dispatch and DispatchId events. The messageId is the keccak256 hash of the message (including the header), returned by the dispatch call and traceable in the Explorer. The nonce is a monotonically increasing counter on the origin chain's Mailbox. Even if the message body is identical, different nonces produce different messageIds.

The sender can query the cross-chain fee via quoteDispatch(), which covers the cost of dispatch on the origin chain and the prepaid interchain gas for delivery on the destination chain. A Post-Dispatch Hook can prepay destination chain gas to the relayer through the InterchainGasPaymaster (IGP) after dispatch. Once dispatch is complete, the message enters a pending-relay state. The messageId is generated from the hash of the full message, and the destination chain's Mailbox prevents duplicate delivery via the delivered(messageId) mapping.

How Do the Relayer and Validator Collaborate to Deliver Messages?

The Relayer and Validator perform distinct but complementary functions in the Hyperlane protocol. The Validator is responsible for security attestation: when the origin chain's Mailbox dispatches a new message, the MerkleTreeHook emits an InsertedIntoTree event. The Validator reads the current Merkle root, signs the checkpoint, and publishes the signature to public storage (e.g., AWS S3 or Google Cloud Storage). The Relayer handles the transport layer: it listens to events from the origin chain's Mailbox, collects the metadata required by the ISM (e.g., validator signatures, Merkle proof), and calls Mailbox.process() on the destination chain to submit the message.

The Validator is only required in Multisig ISM or Economic Security Module scenarios. If the recipient configures an Optimistic ISM, zero-knowledge proof ISM, or another module that does not require validator signatures, the relayer only needs to collect the metadata required by that ISM. Hyperlane does not mandate an enshrined validator set; the recipient can configure the validator addresses and signature threshold in the Multisig ISM themselves.

The Relayer internally consists of an Indexer and a Submitter. The Indexer queries events from the origin chain via RPC and writes them to a local database. The Submitter confirms that gas has been prepaid, retrieves metadata, simulates, and broadcasts the process call. If delivery fails, the relayer automatically retries using an exponential backoff strategy. Validator signatures are publicly accessible; anyone can carry the signatures and call process. The message sender selects the prepaid recipient via the IGP, and the relayer operator must rebalance revenue to the destination chain account.

How Is Delivery Completed During the Destination Chain Delivery Phase?

The destination chain delivery phase is triggered by the relayer calling Mailbox.process(metadata, message). The Mailbox first checks whether the messageId has already been delivered; if it exists in the delivered mapping, the replay is rejected. Then the Mailbox queries the ISM specified by the recipient contract (via recipientIsm() or custom application configuration) and passes the message and metadata to the ISM.verify() function.

After ISM verification passes, the Mailbox calls the recipient contract's handle(origin, sender, body) function, passing the message body and source information to the application layer logic. The recipient contract must implement the IMessageRecipient interface's handle function, which executes business operations such as cross-chain governance voting, asset minting/release, or state updates. Once delivery succeeds, the Mailbox marks the messageId as delivered and emits Process and ProcessId events.

For asset cross-chain applications like Warp Route, the handle function triggers logic for locking, minting, burning, or releasing tokens. For cross-chain governance applications, the handle function records voting weights or executes proposals. The gas for the delivery phase is paid by the relayer on the destination chain, while the sender has already prepaid the corresponding fee on the origin chain via the IGP.

Figure 2. Destination chain delivery sequence: Mailbox process triggers ISM verify; upon verification, recipient handle is called, and replay is prevented via the messageId mapping.

How Does the Destination Chain ISM Verify Cross-Chain Messages?

The ISM (Interchain Security Module) is a smart contract on the destination chain responsible for verifying the authenticity of cross-chain messages. Before delivery, the Mailbox passes the message and the metadata submitted by the relayer to ISM.verify(). The verification logic varies by ISM type. The default ISM is the Multisig ISM, which requires a configured number of validators to sign the origin chain's Merkle root, reaching a threshold. Applications can also deploy custom ISMs or use the Aggregation ISM to combine multiple verification paths.

To verify the ISM configuration, you can query the recipient contract's ISM address, check the validator threshold and ISM type parameters, and confirm the verification status and metadata for a specific message in the Explorer.

Under Multisig ISM, the relayer retrieves checkpoint signatures from validator public storage and submits them along with the Merkle proof. The Economic Security Module provides economic security through EigenLayer AVS; validator fraud may trigger slashing. If verification passes, the ISM returns true, and the Mailbox executes handle; if verification fails, the process transaction reverts, and the relayer will retry according to a backoff strategy.

What Are the Risks and Limitations of Cross-Chain Message Passing?

Hyperlane cross-chain message passing involves structural risks at the mechanism level, which need to be understood from the message layer, transport layer, and economic layer. Message layer risks include: improper configuration of custom ISMs may weaken verification strength; vulnerabilities in the recipient's handle function logic could lead to incorrect state updates. Transport layer risks include: relayer delays or stoppages may leave messages undelivered for a long time (IGP prepaid but relayer hasn't submitted); gas price fluctuations on the destination chain may affect the relayer's willingness to submit; validator downtime in Multisig ISM with a high threshold may hinder liveness.

Economic layer risks include validator fraud potentially triggering HYPER slashing, and incorrect IGP fee configuration may lead to insufficient delivery fees. Message delivery is not instantaneous; it requires waiting for origin chain finality and relayer submission. Reliability depends on IGP prepayment and relayer operational quality.

Before operating, verify the on-chain addresses of Mailbox, ISM, and recipient contracts, and distinguish between protocol default configurations and application custom configurations. For scenarios like Warp Route asset cross-chain, also pay attention to the routing contract and token mapping relationships.

Summary

Hyperlane cross-chain messages follow a repeatable flow: dispatch → attestation → relay → verify → deliver. The origin chain's Mailbox.dispatch() encodes the message and writes it to the Merkle tree; validators sign the checkpoint (in Multisig ISM scenarios); the relayer collects metadata and calls process on the destination chain; after ISM verification, the Mailbox calls handle to complete delivery. The messageId is globally unique, and delivered messages cannot be replayed. The IGP prepays destination chain gas, and the Explorer provides full lifecycle tracking.

FAQ

What is the basic flow of Hyperlane cross-chain messages?

The sender on the origin chain calls Mailbox.dispatch() to send the message. The Mailbox writes it to the Merkle tree and emits events. The relayer listens for events, collects metadata required by the ISM, and calls Mailbox.process() on the destination chain. After ISM verification, the Mailbox calls the recipient's handle function to complete delivery.

On which chains do dispatch and delivery occur?

Dispatch occurs on the Mailbox contract of the origin chain, triggered by the sender contract. Delivery occurs on the Mailbox contract of the destination chain, triggered by the relayer calling process, and after ISM verification, the recipient's handle is called.

What is the difference between the relayer and the validator?

The Validator signs the origin chain's Merkle root checkpoint, providing attestation for security modules like Multisig ISM. The Relayer handles the off-chain transport layer, indexing origin chain events, collecting metadata, and submitting the process call on the destination chain. Their functions are complementary: the relayer is essential for all message deliveries, while the validator is only required for specific ISM types.

How can I track the status of a cross-chain message?

Each message has a unique messageId (the keccak256 hash returned at dispatch). The Hyperlane Explorer allows you to query the full lifecycle status of the message from dispatch to process, including the origin chain send time, relayer submission records, ISM verification results, and destination chain delivery confirmation.

What could cause a message not to be delivered?

Common reasons include: insufficient IGP prepaid fees, the relayer has not yet submitted or is retrying, validator signatures have not reached the Multisig threshold, destination chain gas fees are too high causing relayer delays, or ISM verification failure. You can use the Explorer to view the specific pending reason and retry records for a particular message.

Can a cross-chain message be delivered twice?

No. The Mailbox maintains a delivered(messageId) mapping. Once a messageId has been delivered, it will be rejected during the destination chain's process, preventing replay attacks. The nonce field also ensures that even if the message body is the same, different dispatches produce different messageIds.