Special thanks to NoSleepJon, Paul, Avi & Fezyla for comments & feedback on this post.
TLDR:
Fragmentation limits blockchain ecosystems – Chains operate in isolation, leading to disconnected user experiences, fragmented assets, and isolated innovation.
Interoperability is key – Developers need seamless communication between chains to move assets, data, and smart contract logic across networks.
Hyperlane simplifies cross-chain messaging – Hyperlane enables permissionless, secure messaging between chains, allowing developers to build cross-chain apps without the complexity of setting up custom infrastructure.
The blockchain ecosystem is rapidly expanding with over hundreds of networks like Bitcoin, Ethereum, Solana, and many Layer-2s. But there’s a catch, each chain operates in isolation. For developers, this creates significant hurdles. Building on one chain doesn’t give access to users, assets on others, limiting the potential reach and usability of decentralized apps (dApps). In this fragmented landscape, cross-chain connectivity is critical.
This is where Hyperlane comes in. Hyperlane enables permissionless and secure cross-chain messaging, allowing developers to build apps that communicate across multiple chains without the need to create complex, custom infrastructure.
In this post, we’ll cover:
The current state of the multi-chain ecosystem
The need for permissionless interoperability
How Hyperlane enables permissionless, secure communication between chains
By the end of this post, you’ll have a clear understanding of why cross-chain functionality is a game changer for blockchains and how Hyperlane empowers you to build dApps that seamlessly operate across multiple ecosystems.
Today’s blockchain landscape is filled with well-known layer-1s like Bitcoin, Ethereum, and Solana, each with its own architecture and goals. But scalability challenges remain, which is why Layer-2 solutions such as Ethereum rollups (Optimism, Base, and Arbitrum) have emerged, providing additional layers to improve the base network.
In addition, Rollups as a Service (RaaS) platforms now let developers create customized rollups in just minutes. This ease of customization gives rise to app-specific rollups and appchains, tailored to the unique needs of different projects.
However this growing variety also leads to fragmentation. A dApp or rollup built on one blockchain doesn’t automatically connect with users, assets, or liquidity on another. This creates several challenges for developers:
Cross-Chain Messaging: Managing state and operations across multiple chains is a significant technical challenge. Existing cross-chain solutions often require developers to build complex, custom-built messaging frameworks to coordinate operations across chains. Without an easy way to send data, trigger function calls, or synchronize state between blockchains, building multi-chain dApps becomes a huge challenge.
Isolated innovation: Apps built on one chain remain siloed from others, restricting their reach and limiting the potential for innovation and collaboration across ecosystems.
Complicated User Experience: Developers are forced to build apps that require users to manage multiple wallets, interact with various bridges, and pay different transaction fees across chains. This friction significantly impacts adoption and usability, which directly impacts the app's success.
In a world with many blockchains, interoperability—the ability for blockchains to easily communicate with one another—is key to solving the problems caused by fragmentation. Interoperability allows developers to build applications where assets, data, and smart contracts interactions can move across chains.
With cross-chain interoperability, you can:
Directly transfer assets from one blockchain to another
Use data from one blockchain in an application on another
Execute smart contracts across different networks
Simply put, the ability to connect multiple chains removes barriers and unlocks new possibilities for dApps.
The initial solution to cross-chain problems was bridges—mechanisms designed to transfer tokens from one blockchain to another. As per latest data on DeFi Lama, USD 1.779 billion worth of crypto assets were transferred on bridges in just the last week.
Bridges traditionally follow a lock-and-mint model: assets are locked on the origin chain and an equivalent synthetic token is minted on the destination chain.
While bridges are effective for basic token transfers, they introduced several limitations:
Complexity for Developers: Each bridge typically requires its own infrastructure and custom messaging system. This leads to added operational overhead and complexity.
Centralization and Trust Assumptions: Many bridges rely on centralized validators to operate. These validators approve the transfers and relay messages between chains. This centralization introduces trust dependencies, as users must rely on the validators to accurately and securely process transactions. Moreover, adding new chains often required approval or partnership with bridge operators, leading to bottlenecks.
Limited Functionality: Bridges are primarily designed for token transfers and struggle with more advanced cross-chain use*cases, such as smart contract interactions or data sharing. This limits developers who need more than just token transfers to scale dApps across chains.
Note: This is a high-level overview of bridges, and there are several variations of bridge designs, such as liquidity networks and atomic swaps, which aim to address some of these challenges. We're doing a short trip down the memory lane for this post, please bear that in mind.
After bridges, the industry moved toward interoperability protocols designed to overcome the limitations. These systems allowed for more flexible cross-chain messaging and smart contract interactions.
However these solutions often remained permissioned.
They rely on a set of trusted validators or operators to facilitate communication between blockchains. Developers who want to build cross-chain apps still have to work within the framework of these validators, introducing new trust dependencies and reliance on external parties. In many cases, adding a new chain to the system requires approval or even a formal partnership with the framework's operators. This approval process can create bottlenecks, as developers may need to negotiate terms or wait for the framework to support their desired chain.
While these traditional interoperability solutions represent significant improvements over bridges they remain centralized and permissioned, limiting the full potential of cross-chain scalability.
What's truly needed is a way to connect chains without the bottlenecks created by centralized or permissioned systems. Permissionless interoperability allows any blockchain to communicate with another, without requiring approvals or relying on centralized intermediaries or validators.
Hyperlane is designed to provide exactly this type of permissionless interoperability. It enables developers to connect chains, run their own infrastructure, and build across ecosystems.
With Hyperlane’s permissionless interoperability, you get several benefits, including:
No approval required: Developers don’t have to wait for central entities to add new chains or set up new connections. They can do it themselves.
Run your own operators: Instead of relying on a fixed validator/agent set chosen by a third party, developers can operate their own validators, reducing reliance on centralized trust.
More flexibility: Developers can build apps that connect seamlessly across multiple chains, with full control over how data and assets flow between them.
This decentralized approach mirrors how anyone can deploy a smart contract on Ethereum without needing permission. Hyperlane removes the complexity and restrictions, allowing developers to build cross-chain applications with less friction and more scalability.
Now, let's take a deeper look at Hyperlane, How it works under hood and what cross-chain communication with Hyperlane looks like.
Hyperlane is a protocol for secure, permissionless communication between different blockchains, allowing developers to build apps that work seamlessly across multiple chains.
Hyperlane simplifies cross-chain messaging by providing a streamlined, secure framework for transfering data and assets between chains. This eliminates the need for complex, custom solutions and accelerates the development of cross-chain apps.
With Hyperlane’s messaging capabilities, developers can:
Transfer Assets: Move tokens across chains with ease.
Share Data: Seamlessly use information from one chain in applications on another.
Execute Smart Contracts: Enable contract interactions across multiple networks without added complexity.
What sets Hyperlane apart is that it’s fully permissionless, allowing anyone to add their own chain and operate the entire infrastructure themselves. This gives them full control over cross-chain communication, removing bottlenecks and ensures scalability.
Let’s take a closer look at how this works by exploring the key components of Hyperlane.
Let’s break down the 3 main components to understand how the protocol works:
Mailbox Contracts are smart contracts deployed on each blockchain that manage the sending, receiving, and processing of cross-chain messages. They serve as an entry and exit point for messages. A key feature is their permissionless nature - anyone can deploy a Mailbox. This enables developers to integrate cross-chain communication into their dApps without needing approval or access, ensuring a decentralized, open system for messaging between blockchains.
Validators: In Hyperlane, validators help secure cross-chain messaging by signing checkpoints (Merkle roots) when new messages are sent from the Mailbox. These signatures let Relayers deliver messages to other chains. Hyperlane’s validator set is open– anyone can become a validator if they are included in the Multisig ISM specified by the receiving chain's contract.
Relayers: Relayers are off-chain actors responsible for transporting messages between chains. They pick up the message from one chain’s Mailbox contract and deliver it to another.
The Interchain Security Module (ISM) is a customizable security framework that verifies cross-chain messages. Think of ISMs as security Lego blocks—each one is a smart contract that can be mixed and matched based on your app’s security requirements.
For instance:
Multisig ISM: Specifies which validators must agree to validate a message.
Routing ISM: Adjusts security settings based on message type or content.
Optimistic ISM: Adds a delay in message verification for more security.
With ISMs, you can configure and combine these blocks to create a tailored security framework.
When a cross-chain message is sent using Hyperlane, it starts at the origin chain’s Mailbox Contract, which packages the message. Validators then sign off, verifying its legitimacy, and Relayers transport it to the destination chain’s Mailbox. Once the message arrives, the Interchain Security Module (ISM) ensures that the message is properly verified and processed.
Each of these components—Mailbox, Validators, Relayers, and ISM—work together to enable secure, permissionless communication between blockchains.
This process allows developers to send assets, share data, and interact with smart contracts across multiple networks, all while maintaining control over the infrastructure.
As blockchains grow cross-chain applications will become essential for unlocking the full potential of decentralized technologies. Hyperlane makes it easy for developers to build cross-chain apps, without the complexities of custom infrastructure or needing permission.
On another post, we’ll dive deeper into the protocol’s inner workings and explain how messages and assets are transferred between chains. If you have any questions, feel free to reach out to me!
See you on the next one! 👋
(Fun fact: The banner features a photo of the Sombrero Galaxy, one of the cutest spiral galaxies, named for its resemblance to a Mexican hat. )
Special thanks to NoSleepJon, Paul, Avi & Fezyla for comments & feedback on this post.
TLDR:
Fragmentation limits blockchain ecosystems – Chains operate in isolation, leading to disconnected user experiences, fragmented assets, and isolated innovation.
Interoperability is key – Developers need seamless communication between chains to move assets, data, and smart contract logic across networks.
Hyperlane simplifies cross-chain messaging – Hyperlane enables permissionless, secure messaging between chains, allowing developers to build cross-chain apps without the complexity of setting up custom infrastructure.
The blockchain ecosystem is rapidly expanding with over hundreds of networks like Bitcoin, Ethereum, Solana, and many Layer-2s. But there’s a catch, each chain operates in isolation. For developers, this creates significant hurdles. Building on one chain doesn’t give access to users, assets on others, limiting the potential reach and usability of decentralized apps (dApps). In this fragmented landscape, cross-chain connectivity is critical.
This is where Hyperlane comes in. Hyperlane enables permissionless and secure cross-chain messaging, allowing developers to build apps that communicate across multiple chains without the need to create complex, custom infrastructure.
In this post, we’ll cover:
The current state of the multi-chain ecosystem
The need for permissionless interoperability
How Hyperlane enables permissionless, secure communication between chains
By the end of this post, you’ll have a clear understanding of why cross-chain functionality is a game changer for blockchains and how Hyperlane empowers you to build dApps that seamlessly operate across multiple ecosystems.
Today’s blockchain landscape is filled with well-known layer-1s like Bitcoin, Ethereum, and Solana, each with its own architecture and goals. But scalability challenges remain, which is why Layer-2 solutions such as Ethereum rollups (Optimism, Base, and Arbitrum) have emerged, providing additional layers to improve the base network.
In addition, Rollups as a Service (RaaS) platforms now let developers create customized rollups in just minutes. This ease of customization gives rise to app-specific rollups and appchains, tailored to the unique needs of different projects.
However this growing variety also leads to fragmentation. A dApp or rollup built on one blockchain doesn’t automatically connect with users, assets, or liquidity on another. This creates several challenges for developers:
Cross-Chain Messaging: Managing state and operations across multiple chains is a significant technical challenge. Existing cross-chain solutions often require developers to build complex, custom-built messaging frameworks to coordinate operations across chains. Without an easy way to send data, trigger function calls, or synchronize state between blockchains, building multi-chain dApps becomes a huge challenge.
Isolated innovation: Apps built on one chain remain siloed from others, restricting their reach and limiting the potential for innovation and collaboration across ecosystems.
Complicated User Experience: Developers are forced to build apps that require users to manage multiple wallets, interact with various bridges, and pay different transaction fees across chains. This friction significantly impacts adoption and usability, which directly impacts the app's success.
In a world with many blockchains, interoperability—the ability for blockchains to easily communicate with one another—is key to solving the problems caused by fragmentation. Interoperability allows developers to build applications where assets, data, and smart contracts interactions can move across chains.
With cross-chain interoperability, you can:
Directly transfer assets from one blockchain to another
Use data from one blockchain in an application on another
Execute smart contracts across different networks
Simply put, the ability to connect multiple chains removes barriers and unlocks new possibilities for dApps.
The initial solution to cross-chain problems was bridges—mechanisms designed to transfer tokens from one blockchain to another. As per latest data on DeFi Lama, USD 1.779 billion worth of crypto assets were transferred on bridges in just the last week.
Bridges traditionally follow a lock-and-mint model: assets are locked on the origin chain and an equivalent synthetic token is minted on the destination chain.
While bridges are effective for basic token transfers, they introduced several limitations:
Complexity for Developers: Each bridge typically requires its own infrastructure and custom messaging system. This leads to added operational overhead and complexity.
Centralization and Trust Assumptions: Many bridges rely on centralized validators to operate. These validators approve the transfers and relay messages between chains. This centralization introduces trust dependencies, as users must rely on the validators to accurately and securely process transactions. Moreover, adding new chains often required approval or partnership with bridge operators, leading to bottlenecks.
Limited Functionality: Bridges are primarily designed for token transfers and struggle with more advanced cross-chain use*cases, such as smart contract interactions or data sharing. This limits developers who need more than just token transfers to scale dApps across chains.
Note: This is a high-level overview of bridges, and there are several variations of bridge designs, such as liquidity networks and atomic swaps, which aim to address some of these challenges. We're doing a short trip down the memory lane for this post, please bear that in mind.
After bridges, the industry moved toward interoperability protocols designed to overcome the limitations. These systems allowed for more flexible cross-chain messaging and smart contract interactions.
However these solutions often remained permissioned.
They rely on a set of trusted validators or operators to facilitate communication between blockchains. Developers who want to build cross-chain apps still have to work within the framework of these validators, introducing new trust dependencies and reliance on external parties. In many cases, adding a new chain to the system requires approval or even a formal partnership with the framework's operators. This approval process can create bottlenecks, as developers may need to negotiate terms or wait for the framework to support their desired chain.
While these traditional interoperability solutions represent significant improvements over bridges they remain centralized and permissioned, limiting the full potential of cross-chain scalability.
What's truly needed is a way to connect chains without the bottlenecks created by centralized or permissioned systems. Permissionless interoperability allows any blockchain to communicate with another, without requiring approvals or relying on centralized intermediaries or validators.
Hyperlane is designed to provide exactly this type of permissionless interoperability. It enables developers to connect chains, run their own infrastructure, and build across ecosystems.
With Hyperlane’s permissionless interoperability, you get several benefits, including:
No approval required: Developers don’t have to wait for central entities to add new chains or set up new connections. They can do it themselves.
Run your own operators: Instead of relying on a fixed validator/agent set chosen by a third party, developers can operate their own validators, reducing reliance on centralized trust.
More flexibility: Developers can build apps that connect seamlessly across multiple chains, with full control over how data and assets flow between them.
This decentralized approach mirrors how anyone can deploy a smart contract on Ethereum without needing permission. Hyperlane removes the complexity and restrictions, allowing developers to build cross-chain applications with less friction and more scalability.
Now, let's take a deeper look at Hyperlane, How it works under hood and what cross-chain communication with Hyperlane looks like.
Hyperlane is a protocol for secure, permissionless communication between different blockchains, allowing developers to build apps that work seamlessly across multiple chains.
Hyperlane simplifies cross-chain messaging by providing a streamlined, secure framework for transfering data and assets between chains. This eliminates the need for complex, custom solutions and accelerates the development of cross-chain apps.
With Hyperlane’s messaging capabilities, developers can:
Transfer Assets: Move tokens across chains with ease.
Share Data: Seamlessly use information from one chain in applications on another.
Execute Smart Contracts: Enable contract interactions across multiple networks without added complexity.
What sets Hyperlane apart is that it’s fully permissionless, allowing anyone to add their own chain and operate the entire infrastructure themselves. This gives them full control over cross-chain communication, removing bottlenecks and ensures scalability.
Let’s take a closer look at how this works by exploring the key components of Hyperlane.
Let’s break down the 3 main components to understand how the protocol works:
Mailbox Contracts are smart contracts deployed on each blockchain that manage the sending, receiving, and processing of cross-chain messages. They serve as an entry and exit point for messages. A key feature is their permissionless nature - anyone can deploy a Mailbox. This enables developers to integrate cross-chain communication into their dApps without needing approval or access, ensuring a decentralized, open system for messaging between blockchains.
Validators: In Hyperlane, validators help secure cross-chain messaging by signing checkpoints (Merkle roots) when new messages are sent from the Mailbox. These signatures let Relayers deliver messages to other chains. Hyperlane’s validator set is open– anyone can become a validator if they are included in the Multisig ISM specified by the receiving chain's contract.
Relayers: Relayers are off-chain actors responsible for transporting messages between chains. They pick up the message from one chain’s Mailbox contract and deliver it to another.
The Interchain Security Module (ISM) is a customizable security framework that verifies cross-chain messages. Think of ISMs as security Lego blocks—each one is a smart contract that can be mixed and matched based on your app’s security requirements.
For instance:
Multisig ISM: Specifies which validators must agree to validate a message.
Routing ISM: Adjusts security settings based on message type or content.
Optimistic ISM: Adds a delay in message verification for more security.
With ISMs, you can configure and combine these blocks to create a tailored security framework.
When a cross-chain message is sent using Hyperlane, it starts at the origin chain’s Mailbox Contract, which packages the message. Validators then sign off, verifying its legitimacy, and Relayers transport it to the destination chain’s Mailbox. Once the message arrives, the Interchain Security Module (ISM) ensures that the message is properly verified and processed.
Each of these components—Mailbox, Validators, Relayers, and ISM—work together to enable secure, permissionless communication between blockchains.
This process allows developers to send assets, share data, and interact with smart contracts across multiple networks, all while maintaining control over the infrastructure.
As blockchains grow cross-chain applications will become essential for unlocking the full potential of decentralized technologies. Hyperlane makes it easy for developers to build cross-chain apps, without the complexities of custom infrastructure or needing permission.
On another post, we’ll dive deeper into the protocol’s inner workings and explain how messages and assets are transferred between chains. If you have any questions, feel free to reach out to me!
See you on the next one! 👋
(Fun fact: The banner features a photo of the Sombrero Galaxy, one of the cutest spiral galaxies, named for its resemblance to a Mexican hat. )
EdaZero-Knowledge Proofs in Plain English
TL;DRZero-knowledge proofs (ZKPs) can cryptographically prove a statement is true without revealing the statement itself. They offer a new level of privacy in digital transactions, allowing for verification without compromising sensitive data.Zk-SNARKs, which stand for Succinct Non-interactive Arguments of Knowledge, are a type of ZKPs. ‘ Succinct’ and ‘Non-interactive’ highlight their efficient performance, while ‘Zero-knowledge’ refers to their privacy-enhancing feature. They are becoming i...
EdaA Developer's Guide to Intents & The Open Intents Framework
If you were online last week, you probably came across The Open Intents Framework. And even before that, you may have heard about intents. Either way, this post is here to break it all down, making the concept digestible for anyone interested. I aim for this post to be a zero-to-one guide on intents, explaining their role in Ethereum's multi-chain future, and how The Open Intents Framework makes them easier to build with. We’ll cover:Why Ethereum needs intents – Scaling introduced fragme...
EdaEigenLayer: Intersubjective Faults, Token forking, bEIGEN & more
Special thanks to Soubhik & Jessy from EigenLayer for comments & feedback on this post. EigenLayer is giving me a lot to write about. It’s been a few weeks since they released their token whitepaper, EIGEN The Universal Intersubjective Work Token, which introduces many new ideas.Yes - I’ve read the 43 page whitepaper, hopefully it will make your life easier (and give me some interesting dinner conversation topics). In this post, I aim to answer the following:Background info: What is EigenLaye...
EdaZero-Knowledge Proofs in Plain English
TL;DRZero-knowledge proofs (ZKPs) can cryptographically prove a statement is true without revealing the statement itself. They offer a new level of privacy in digital transactions, allowing for verification without compromising sensitive data.Zk-SNARKs, which stand for Succinct Non-interactive Arguments of Knowledge, are a type of ZKPs. ‘ Succinct’ and ‘Non-interactive’ highlight their efficient performance, while ‘Zero-knowledge’ refers to their privacy-enhancing feature. They are becoming i...
EdaA Developer's Guide to Intents & The Open Intents Framework
If you were online last week, you probably came across The Open Intents Framework. And even before that, you may have heard about intents. Either way, this post is here to break it all down, making the concept digestible for anyone interested. I aim for this post to be a zero-to-one guide on intents, explaining their role in Ethereum's multi-chain future, and how The Open Intents Framework makes them easier to build with. We’ll cover:Why Ethereum needs intents – Scaling introduced fragme...
EdaEigenLayer: Intersubjective Faults, Token forking, bEIGEN & more
Special thanks to Soubhik & Jessy from EigenLayer for comments & feedback on this post. EigenLayer is giving me a lot to write about. It’s been a few weeks since they released their token whitepaper, EIGEN The Universal Intersubjective Work Token, which introduces many new ideas.Yes - I’ve read the 43 page whitepaper, hopefully it will make your life easier (and give me some interesting dinner conversation topics). In this post, I aim to answer the following:Background info: What is EigenLaye...
i write & code 🌸 developer advocate 👩💻 https://twitter.com/edatweets_
i write & code 🌸 developer advocate 👩💻 https://twitter.com/edatweets_
Share Dialog
Share Dialog
Subscribe to Eda
Subscribe to Eda
>100 subscribers
>100 subscribers
No activity yet