Special thank you to NoSleepJon, Paul, & Connor for comments & feedback on this post.
I’m still finding my feet in this field, and my notes are all over the place—so consider this my attempt to organize the chaos. If you’re new to Hyperlane and cross-chain apps, start with this post for the “why.” Here, I’ll dive into the “how.” I’ll keep it straightforward, and hopefully useful enough to recycle for future talks.
In this post I want to answer the following:
Why you should care about interoperability & Hyperlane?
What’s an interoperability protocol and how does it work?
Where to get started?
Blockchains today are like islands—they don’t naturally communicate. This creates:
Disconnected apps: Apps on one chain can’t interact with others.
Fragmented assets: Tokens and liquidity are stuck on separate networks.
User friction: Managing multiple wallets, bridges, and fees is confusing and frustrating.
Interoperability changes this by enabling seamless communication between chains. It allows developers to build apps that connect across networks, transfer assets and data easily, and unlock new opportunities for innovation and better user experiences.
This is where Hyperlane comes in.
Hyperlane offers permissionless, secure cross-chain messaging, meaning:
Permissionless: Anyone can connect new chains or run their own infrastructure without needing approval from central entities.
Secure: Messages between chains are verified with customizable security models.
Simplified: Move assets and data between chains without needing to build or maintain complex, custom solutions.
Now, let’s dive into how it all works under the hood.
Hyperlane is a protocol for secure, permissionless communication between different blockchains. It works by combining a few key components that handle cross-chain messaging and security.
Mailbox Contracts
Agents: Relayers and Validators
Interchain Security Modules
Here’s a breakdown of how they fit together:
Relayers
Validators
The process starts when the sender calls the dispatch()
function on the origin chain’s Mailbox contract.
Once dispatch()
is called, the Mailbox contract emits a Dispatch
event. This signals that the message is ready for transport. Validators observe the message and confirm it with a signature.
Relayers monitor the origin Mailbox for Dispatch
events. When detected, the relayer collects the event data and initiates the next steps.
Message Collection: The relayer collects this message and verifies that the sender has paid the required gas for delivery. If additional security metadata is required, such as in the case of a multisig ISM, the relayer collects signatures from validators to ensure integrity.
Message Preparation & Simulation: Before sending the message, the relayer prepares the necessary ISM metadata to ensure the message is valid. It simulates the transaction to confirm success. If the simulation passes, the message is queued for submission.
Message Submission: Finally, the relayer submits the message, along with the necessary verification data, to the Mailbox contract on the destination chain. This function triggers the next step in the cross-chain messaging process, passing the message to the ISM for verification.
On the destination chain, the Mailbox checks if the recipient contract specifies a custom ISM by implementing the ISpecifiesInterchainSecurityModule
interface. If so, it retrieves the specified ISM; otherwise, it uses the default ISM.
After retrieving the appropriate ISM, the Mailbox contract on the destination chain verifies the message using the selected ISM (e.g., Multisig signatures, Merkle proofs, ZK proofs, etc.).
If valid, the message is approved; if invalid, it is rejected.
Once verified, the Mailbox calls the recipient contract’s handle()
function. The recipient contract processes the message based on its logic, such as transferring assets or triggering specific actions in the application.
Yes, and it’s easier than you think! Hyperlane is designed to be permissionless, meaning you don’t need approval from anyone to connect a new chain. Here’s how it works:
Deploy Hyperlane core contracts:
You’ll deploy core contracts to your chain, including: the Mailbox, which handles sending and receiving messages and supporting contracts like the Interchain Gas Paymaster (IGP) for handling gas payments, the Default ISM (if you’re not using a custom one).
These contracts are the backbone of Hyperlane’s cross-chain messaging.
Set up the ISM
The ISM is customizable depending on the security requirements of the application. You can use the default settings or customize according to your needs.
Configure Agents
Set up the agents—relayers and validators—to monitor, verify, and transport cross-chain messages.
👉 And that’s it! Hyperlane ensures you can connect chains quickly and on your own terms. You can check out the docs for more info on the steps.
Warp Routes build on Hyperlane’s infrastructure, letting you use cross-chain messaging in a straightforward way.
They allow any ERC20, ERC721, or native tokens to move effortlessly between chains. Warp Routes provide predefined paths for transferring assets and sending messages between blockchains, so you don’t have to set everything up from scratch.
Abstract away the complexity: Warp Routes act as an abstraction layer over Hyperlane's core messaging and modular security. While Hyperlane handles the heavy lifting of cross-chain messaging—such as routing, message verification, and security—Warp Routes simplify this by pre-configuring the pathways for certain assets.
Simplicity: Instead of setting up individual connections or configuring security modules for each chain, Warp Routes let you use these pre-established routes.
👉 Check out our docs for details on how to deploy and use Warp Routes.
Interoperability can feel overwhelming with all the buzzwords, but it doesn’t have to be. I hope this post gave you a clear, straightforward explainer and the tools (or at least some curiosity) to keep exploring.
Check out the Hyperlane Bounties for some ideas & starting points
Follow Hyperlane for the latest updates, research, and insights into cross-chain interoperability
See you on the next one!