Hyperlane is a modular interchain messaging protocol. Its chain agnostic interoperability layer between blockchains allows developers to send messages from one blockchain to another. Messages can contain arbitrary bytes and are not limited to text. Hyperlane offers interoperable APIs enabling cross-chain messaging functionality in dApps, the creation of natively interchain tokens, and a SDK and tooling for building unique interchain dApps. Hyperlane is not a traditional asset transfer bridge but an information highway with broad applicability.
Jon Kol, Hyperlane’s Co-Founder, joined us for an AMA on November 21st.
vVv: Before we dive deeper into Hyperlane, tell us about yourself, your background, and what made you switch from the traditional finance sector to Web3?
Jon: I attended UC Berkeley, and if you weren’t an engineering major, you were going to one of two places on Wall Street: a bank’s investment banking division or a consulting firm, like McKinsey, Bain Company, or the Boston Consulting Group. My father could no longer work, and thus I had to help financially support my parents. Upon graduation, I received two offers, and I chose the higher-paying offer from Morgan Stanley as a bond trader. While I was at Morgan Stanley, a school friend introduced me to Ethereum, and after researching it, I was completely infatuated. Having been mistreated by Israeli banks in my home country and later by American banks with Wells Fargo, I strongly disliked banks. And because of that, the implications of Ethereum and their plan to build a parallel financial instrument were the reasons for my obsession with crypto and why I was so adamant to work in this space. In 2017, I left Morgan Stanley, and I’ve been in crypto professionally now for 5 years. Before starting Hyperlane, I spent 3 years co-leading the investment team at Galaxy Digital, Mike Novogratz’s firm.
vVv: As a project founder and venture capitalist, what are your thoughts on the current VC space and the overly inflated early project valuations?
Jon: To explain this pervasive phenomenon, we have this industry emanating from esoteric technology that requires some understanding for proper evaluation. Early on, the foremost experts in the field were the early project founders. Secondary to them were the early venture capitalists, followed by everyone who wanted to get involved. In crypto, we’ve experienced multiple cycles. The first rise throughout 2017 ended in early 2018, and then another larger cycle in late 2020, which grew exponentially in 2021 and peaked in November 2021. Throughout these cycles, there were differential rates of change. The interest in crypto was skyrocketing in terms of time and capital investment. Whether it was individuals purchasing crypto assets or traditional investors, everyone was focusing their attention and capital on crypto. But the space was not changing or evolving at a similar pace. This caused a massive mismatch between the demand and supply of high-quality crypto projects. There was a price increase across the board which continued when people realized they could show minimal performance and extract phenomenal undeserving terms from investors. There was a flow of money and information between people who had lots of capital but were ill-informed about the industry to people who lacked capital but were industry experts. In one regard, it was non-cryoto native investors who were leading crypto funds. The model was that higher crypto expertise equated to more successful capital raises. When crypto funds discovered crypto founders with a slight edge in knowledge, this led to a deluge of capital influx to that project. This insatiable appetite for crypto created an extremely low requirement for project founders who merely had to illustrate a better comprehension of the space to extract money from investors. Most founders were genuine people hoping to build something, but there was no shortage of people who consciously exploited this opportunity. And here we are today, and although it feels like demand has subsided tremendously, it hasn’t. Demand in November 2022 still outweighed that of November 2019, which is positive for the crypto space but not optimal for investors seeking the best projects. Personally, as a crypto investor, times have become more difficult. There’s definitely an increase in demand but an absence of high-quality teams and projects, which makes competition fierce. As a project founder, this is a great period to be in crypto because of the heightened level of interest. There’s a larger talent pool, limitless possibilities, and funding as long as you’re demonstrating progress. Despite this, the current funding climate is much more difficult than it was just eight months ago, which is a good thing because it was a bit too frothy. Thus, we have a situation that is good for a founder but difficult for an investor. It will be good for investors in the long term, as the cream will rise from the founder’s side to the top. Regardless, I think it’s tough not to be optimistic about the long-term prospects of crypto, even with very unfortunate events like the FTX debacle.
vVv: Could you give us a high-level overview of the platform architecture? Specifically, what are the essential parts of the system and requirements for blockchain interoperability protocol?
Jon: There are three main parts, the first of which is mailboxes. Mailboxes send and receive mail between blockchains. From a developer’s perspective, a mailbox is like the on-chain API that connects your contract to all the chains you want to support. They act as connective tissue between different blockchains. On every blockchain, we have the architecture’s second part, validators. These validators are blockchain specific, and there are as many validator sets as there are chains. Each validator set sits and stakes on that specific chain granting verifiable fraud proofs on permissionless latching, a super unique feature only achievable via this method and which we’ll dive into later. Once a message arrives at the mailbox, each validator decides on its validity and signs it. Once a quorum of 2/3 has been signed, we move to our third part of the system, which is completely off-chain and permissionless, a role called the relayer. Unlike the validators, which require a stake, anyone can run a relayer with our open-sourced software. Some early Hyperlane applications are already experimenting with running their own relayers, and we expect a market of relayers to form. Essentially, a relayer watches the mailbox for any message that has reached quorum and if another person is willing to pay for the processing of the message. Relayers take messages from their origin to their destination, or destinations, and initiate the processing. That message hits the mailbox on the destination chain, and then it’s off to its final destination, such as an end user or another contract. That’s how Hyperlane works. These three moving parts are the mailboxes, the validators, and the relayers.
Another unique feature of Hyperlane is our second layer of security, called sovereign consensus. This layer is configurable for each application and allows setting security parameters for messages. An example, in this case, is setting a designated signer. In this way, it doesn’t matter what 1000 validators say. If the designated signers aren’t included, the message cannot be passed and will not be processed. The message will never reach its destination and will be blocked. Another feature is an optimistic model. Imagine, in the case of large transfers adding a 10-hour hold. This would allow the community time to inspect messages to ensure they are not exploits or malicious transactions. In the future, you will be able to incorporate different security models because anyone can write a module, and we will provide a menu of such modules. Developers will be able to implement different security modules based on user action.
Now, imagine going to your bank and withdrawing a small sum; all they require is your PIN number. However, they’ll want an interrogation if you request to withdraw your entire account. Similarly, with Hyperlane, small transactions can be routed through validators, but large transactions could be sent through the optimistic model. That’s a comprehensive overview of how the Hyperlane system works.
vVv: Could you give us an overview of your roadmap and where you currently are? Also, how can we contribute as a community to these different stages?
Jon: In the last few months, we released massive features. The most recent is interchain queries. It lets a developer or user on a specific chain verify information on any other chain in the Hyperlane network. Examples are retrieving the price of Moonbeam or ownership of a ENS.
Before that, we launched interchain accounts. Another great feature that allows developers to execute functions on remote chains without ever deploying a contract on those chains. Until then, Hyperlane and all other interoperability platforms required developers to write contracts on sending and receiving chains. There was no method to communicate or execute functions away from your origin chain without deploying additional contracts. Interchain accounts allow a developer or anyone to designate a contract on one chain and define it as the owner of contracts on any other Hyperlane-supported chain. Imagine a parent DAO on Ethereum owning a child DAO on other Hyperlane chains. You can use this for governance and all other things, such as interchain capital transfers.
Our most recent product release is our message explorer. You can send a message if you’re navigating the interchain space or using a Hyperlane dApp. But what if it doesn’t get processed? Until the middle of October, we did not have a user-friendly solution for this, but now we have our message explorer, which you can find on Hyperlane.xyz. It shows the status of all sent messages and send times. When things fail, this also aids debugging and has been extremely useful for all our developers. It makes developing with Hyperlane much easier.
Another feature we just released but is still a work in progress is called the unified liquidity interface. This allows developers to tap into different interchain liquidity with just a single API.
Coming up in the pipeline is Hyperlane V2, our second version with an anticipated release right before Christmas, a nice gift from our team to our team. V2 introduces the first instance of sovereign consensus that unifies our mailboxes. Currently, our mailboxes are separate, with an inbox and an outbox. In v2, they’ll become a single contract making development, again, a little bit simpler and easier. We do everything with the mindset of “I am hyper-focused on delivering the best experience for our developers and users.” It must be as easy for them to use the platform.
Another thing that should be delivered in December is what we’re calling the trade route API. We are building an interchain highway, which is the network between all chains. We want to make it even easier for people to create trade routes between their new dApps and new chains. The API allows you to create assets that are natively interchain. Whether NFTs or fungible tokens, by placing them into or creating them through the trade route API, those assets never have to be bridged and can move seamlessly between any supported Hyperlane blockchain. The last big feature is the idea of permissionless deployment. You can already deploy Hyperlane on any chain, but it’s not easy. We’re working on truly productizing this feature and allowing anyone to deploy it themselves with great ease.
Those are the most significant things that are going on right now. If you are a developer, there are a bunch of ways in which you can help. The most impactful would be helping us bring Hyperlane into new environments. If you aren’t a developer, you can join our Discord and be part of our community or help with content creation. Anyone who wants to help can contact me on Twitter, Discord, or other platforms.
”Everything we do is with a mindset of “I am hyper-focused on delivering the best experience for our developers and users”
Whether NFTs or fungible tokens, by placing them into or creating them through the trade route API, those assets never have to be bridged and can move seamlessly between any supported Hyperlane blockchain
vVv: On what basis were the security models selected? Which sovereign consensus allows applications to choose and configure?
Jon: We will build smart contracts called interchain security modules or ISM. We will create ones that include an optimistic model and then a designated signer model. Keep in mind that anyone can write their ISM; there is no barrier to writing new ones. Each application selects which one ISM to use; Hyperlane does not force any developer to use specific ISMs.
vVv: How does Hyperlane focus on shifting the interoperability burden from end users to applications?
Jon: We primarily shift the burden by providing developers the tools to handle interoperability on behalf of their users so that users only need to send regular commands and don’t need to switch chains.
vVv: Where is Hyperlane positioned concerning traditional bridges and platforms like the Cosmos Inter-Blockchain Communication protocol (IBC) or the Polkadot parachain ecosystem?
Jon: We are trying to build our own axis, but we are more like a Layer 0 because you can use Hyperlane to perform services such as bridging assets or creating tokens that never need to be bridged and can move natively between all the networks that are connected to all the chains on the interchain highway. One of our original creators is Zaki Manian, from the Cosmos world, co-author of the IBC. We love what IBC is doing, it is an incredible way to build interoperability, but at the same time, it’s very rigid. IBC works well if you conform to its rules and build on its SDK. We want to create a modular network among all existing and future blockchains, so application developers are never restricted or excluded. More importantly, a network that lets application developers create interchain dApps, dApps that a user can interface with from any chain. In crypto, we deal with infrastructure more often than with any other daily technology. And we do not think about it, nor are we bothered by it, because if you were an early adopter, infrastructure was extremely profitable. Hyperlane will allow application developers to bring their dApps to the front, thereby placing infrastructure in the back. We accomplish this by abstracting the interoperability part from the user and transferring it to the dApp.
”We want to create a modular network among all existing and future blockchains, so application developers are never restricted or excluded. More importantly, a network that lets application developers create interchain dApp, dApps that a user can interface with from any chain.
vVv: What kind of attacks is the Hyperlane protocol vulnerable to?
Jon: In the case of interoperability, Hyperlane operates like a narrowly scoped Oracle network and solely relies on the validators. This was our primary concern and the original impetuses for building sovereign consensus. In this attack scenario, a dApp only relies on validators, and the possible total inflicted damage to the dApp exceeds the collective stake of the validators. Imagine your dApp has $100 million of potential damage, but the collective validator stake is only $80 million. There is now an actual economic argument for the attack. We hope that dApps with high stakes will utilize our optional sovereign consensus. In our first version, relayers were exposed to griefing attacks, where attackers could force them to spend their gas tokens. In a few weeks, we’ll launch our second version.
vVv: Can you explain Hyperlane’s difference compared to an oracle provider like Chainlink, and can they provide a similar approach?
Jon: Fundamentally, we are solving the Oracle Problem. The limitation is that blockchains can’t communicate with the outside world. Similar to oracle protocols like Chainlink, Hyperlane organizes information. The main difference is that general oracles like Chainlink provide users with all the information in the world. The trade-offs for generality are design choices to make something fit that could give you good information, for example, the weather in London, the score of the first World Cup game, and what happened on Cosmos. These three queries are very different and in stark comparison to interoperability protocols like Hyperlane, a very narrowly scoped oracle, that only cares about new and pre-existing states on different blockchains. This allows specialization, with certain trade-offs, that is more appealing than a generalized oracle. From a reductionist viewpoint, blockchains introduce constraints to the previously unconstrained digital world. And you have to operate within those constraints. For example, computing isn’t free, memory isn’t free, and bandwidth isn’t free. Focusing solely on reading and writing blockchain states between blockchains makes Hyperlane a better solution than a generalized oracle. However, a generalized oracle could emulate our protocol if they focused similarly. Then it would come down to who can build the most usable and secure system with the best developer tools, etc. If in the interoperability game, someone has a validator system and tells you what they’re doing is not worth realizing, they either don’t know what they’re doing or they’re lying.
vVv: Would off-chain data offerings be a future feature option for Hyperlane?
Jon: It’s not something we’re thinking about in the short term since it changes the trade-offs. With Hyperlane, we are building a modular interoperability platform. Firstly, we’re interoperating between all blockchains. Later, it will be important to operate with non-blockchain systems. Sovereign consensus allows one dApp to use specific security modules when it deals with specific chains and use different security modules for different trade-offs. We could incorporate, for example, a Chainlink oracle feed as one of our modules. A partnership is possible. Now, with one protocol, you can wrap both interoperability between blockchains and interoperability with off-chain systems. Sovereign consensus will allow us to minimize these unfavorable trade-offs in different scenarios.
vVv: If you have information from different blockchains under different constraints, how do you synchronize those messages?
Jon: For this particular reason, our goal is difficult to achieve, and we only tackle challenging problems. And there is a large degree of difference between chains. Currently, we are working on Hyperlane versions to support the Solana VM, the Fuel VM, and the Cosmos SDK. Each of those brings its challenges and differences. EVM solutions will not directly translate to the Solana VM but might work fairly well in the Cosmos case.
For us, synchronization occurs on two levels: by employing different actions in the mailboxes to accommodate the different environments and then by making changes in the relayers to accommodate them. A great advantage of open source is the expert support and user feedback in the various ecosystems. Solana and Cosmos experts submit Github pull requests and provide invaluable feedback.
vVv: Which EVM blockchains are currently supported?
Jon: Currently, our protocol is live and working on the mainnets and testnets of Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Binance, Celo, and Moonbeam. All Hyperlane apps support all of these chains. In the next few months, there will be 4-6 additions. Our most exciting feature, which should be available before the end of 2023, is the ability to add Hyperlane to any blockchain. Hyperlane would be the first interoperability platform in crypto with permissionless deployment.
”Hyperlane would be the first interoperability platform in crypto with permissionless deployment.
vVv: Do you have incentive programs to attract new developers to build on top of Hyperlane?
Jon: We are huge believers in the people who start experimenting at home. We are big fans of hackathons because they allow us to experiment and build with low stakes. We have created a monthly hackathon program called Permathon with a monthly grand prize of 5000 USDC/tether or in DAI awarded to the best submission. To be eligible for the grand prize, submissions must include a demo, how they utilize Hyperlane’s technology, and their experience building with Hyperlane. There will be an additional program that I can’t fully disclose now, but I can state that developers and applications that use Hyperlane will become owners of Hyperlane.
vVv: Earlier, you mentioned validators and their collateral stakes, leading one to assume Hyperlane tokenization. Can you elaborate on that and possible token use cases?
Jon: Yes, correct. One of the security measures is a Proof-of-Stake (POS) protocol. However, I suppose you are familiar with EigenLayer’s amazing work on restaking. In that case, we will add elements of restaking to allow individuals to leverage security from their assets or larger assets like Ethereum.
Addendum: Q&A by vVv community member, Hiroshima Sunset and Jon Kol
Hiroshima: With Web3 gaming expected to take off in the coming years, what role do you foresee Hyperlane playing in this?
Jon: We see Hyperlane playing a big role in gaming projects, as games represent the greatest demand source for writing and reading states across chains in a way that expands beyond token balances and transfers. Game developers are in a challenging environment. Not only do they have to build reliable and performant software, but also a compelling game. The gaming industry has some of the best software engineers, and you’d be hard-pressed to find better developers who can work under material constraints. We want Hyperlane to be something they can easily and quickly integrate, limiting the infrastructure work time and thus increasing game development. And we’re starting to see traction in this realm. In a recent hackathon, we saw the first game that implemented features based on specific chains, i.e., as assets moved to different chains, they adopted different properties. That’s the ingenuity we’ll continue to see and that Hyperlane enables!
Hiroshima: What are your plans for cross-chain NFT protocols? Are you in touch with any of the current major marketplaces and players?
Jon: Hyperlane makes NFT minting as natively interchain assets very easy. And with respect to gaming, it allows developers to assign NFT chain-specific properties. Our current plans are a continuation of a bottoms-up approach, working with new developers and projects and working our way upwards. To that end, you’ll see more activity from Hyperlane, with major players starting next year.
Hiroshima: Where do you store investors’ money? (Is the current $18.5M intact?)
Jon: The vast majority is in our off-chain bank accounts, while a small portion (<10%) is kept on-chain in SAFE multi-sigs.
Hiroshima: What are the most significant obstacles to adoption that you foresee?
Jon: We’re creating a new market and, as in all cases of market creation, you have to deal with product explanations to potential users, which in our case are developers. The biggest obstacle currently, and for the foreseeable future, is developers’ understanding of the implications and potential of interchain dApps.
”The biggest obstacle currently, and for the foreseeable future, is developers' understanding of the implications and potential of interchain dApps.
Hiroshima: Is there a guarantee that all sent messages will be delivered?
Jon: Nothing can be guaranteed. That is also the case for Hyperlane messages. Theoretically, a message may never enter a block on the destination chain. However, Hyperlane relayers can be configured in various ways to give guarantees around delivery, but ultimately the consensus process of a destination chain is the deciding factor.
Hiroshima: How will you transition your protocol from being permissioned to permissionless? And what system will you implement to score participating nodes? Will there be any KYC measures?
Jon: It will happen on several fronts. Even where we stand today, the protocol is very permissionless. Anyone can leverage Hyperlane contracts and run a relayer. The next step is to open up the validator set via POS. Validators will be evaluated on their uptime and correct performance. The protocol will not be able to block validators with the requisite stake from participating. Still, applications can bypass certain validators via sovereign consensus and the Interchain Security Modules (ISMs) of their choice.
Hiroshima: What are your thoughts on the current state of blockchain? Is there room for a monolithic approach when modularity expands?
Jon: Loaded question! Yes, I do, but I don’t think you will see monolithic chains dominating the industry. In my perspective, monolithic chains are likely to dominate sectors, i.e., a monolithic chain specializing in x-type blockspace vs. being generalized. More broadly, I think things have never been better insofar as the general state of the blockchain industry (separating it from the asset/financial side of the industry and the ongoing fiasco w/ FTX). There is an ample amount of uber-talented people working to solve the hardest problems in the industry. I’ve been in crypto for 5 years, and never felt better about it.
Hiroshima: Sovereign consensus allows dApps to use highly permissioned models. Isn’t this contradictory to the ethos of the blockchain?
Jon: You could view it that way, but we firmly believe that giving dApp creators and communities the ability and choice of how to manage their dApp is absolutely in line with the crypto ethos. An app, its developers, and its broader community should have sovereignty over itself, and they should be able to leverage permissionless networks to do that as they please.
We believe and firmly expect that sovereign consensus will be used with great care and caution to heighten interchain security for applications, despite the fact it could be abused. Apps can already use smart contracts to engage in this type of permissioning, yet most choose not to. Similarly, dApps that engage in highly permissioned models may find market disagreements.