Since launching the interchain messaging API, we have worked closely with developers to support the emerging interchain app ecosystem. Our quickstart lets anyone deliver their first message in <5 minutes, from the browser or command-line. Ease of use guides every design decision for our platform.

interchain messages API

To use this API, a contract on the source chain sends messages and a contract on the destination chain receives them. Despite extensive offchain tooling, managing deployments across many chains has been a consistent source of friction. In addition, legacy contract systems not designed for Hyperlane require app-specific middleware to receive messages and benefit from interchain composability.

To eliminate these hurdles, we developed two new APIs that do not require deployment on multiple chains: interchain accounts and interchain queries. Both of these primitives leverage a simple idea: if messages are delivered in a format that recipients already interpret, developers will benefit from universal interchain composability.

Contracts often have conditional control flow on internal state associated with the message sender. For example, ERC20.transfer ensures the msg.sender has sufficient balance in storage. If all Hyperlane messages are relayed as EVM messages from the same middleware contract, source chain message senders are indistinguishable. Instead, an account can be inserted between Hyperlane message and EVM message recipient that uniquely identifies the origin chain and sender address: an interchain account.

interchain accounts API

The code of an interchain account is a hybrid of ownable access control and multicall functionality. In essence, the interchain account acts as a proxy for the origin chain’s sender address. Legacy systems no longer need to integrate Hyperlane because interchain accounts emulate local contract interactions.

This enables contracts to custody native assets and tokens on other networks without using an asset bridge. Building an interchain asset portfolio management system only requires deployment to a single chain. Existing DAOs, which typically dispatch calls via governance, can use interchain accounts for crosschain governance. A multi-collateral stablecoin can use interchain accounts to rebalance reserves of any remote collateral on a Hyperlane network. The possibilities are abundant.

For other use cases, interchain accounts may not be appropriate. Contracts also frequently do external state lookups to compose with other applications. For example, fetching the market exchange rate between 2 assets on Uniswap. Liquidity for asset pairs varies wildly across networks, and a developer may want to rely on a remote network’s exchange rate. This is possible with the messaging API, but has proven cumbersome due to managing contracts on multiple chains.

For designs that require reading remote state, we present the interchain query API. Using this primitive, developers can make calls against any remote contract on a Hyperlane network. In effect, this generalizes the EVM CALL opcode to be interchain.

interchain queries API

Because this round trip traverses two blockchains, it is inherently asynchronous. To resume control flow in Solidity, developers provide a function to process the return value of the query. This pattern is commonly referred to as a callback, but in future could be expressed using async await like syntax. Please refer to the docs for more detailed usage and security assumptions.

Hyperlane didn’t invent interchain accounts, nor queries. In fact, they originated in the Cosmos community and there is progress toward integration to the IBC protocol (here and here). We are focused on bringing interoperability to every developer and every ecosystem. To that end, we will continue to make the best features from protocols like IBC accessible through Hyperlane.

Today, developers can use Hyperlane interchain accounts and queries between an ever-expanding list of supported networks. We are excited to continue iterating on developer primitives with the rest of the ecosystem to push forward what’s possible at the application layer.

Since launching the interchain messaging API, we have worked closely with developers to support the emerging interchain app ecosystem. Our quickstart lets anyone deliver their first message in <5 minutes, from the browser or command-line. Ease of use guides every design decision for our platform.

interchain messages API

To use this API, a contract on the source chain sends messages and a contract on the destination chain receives them. Despite extensive offchain tooling, managing deployments across many chains has been a consistent source of friction. In addition, legacy contract systems not designed for Hyperlane require app-specific middleware to receive messages and benefit from interchain composability.

To eliminate these hurdles, we developed two new APIs that do not require deployment on multiple chains: interchain accounts and interchain queries. Both of these primitives leverage a simple idea: if messages are delivered in a format that recipients already interpret, developers will benefit from universal interchain composability.

Contracts often have conditional control flow on internal state associated with the message sender. For example, ERC20.transfer ensures the msg.sender has sufficient balance in storage. If all Hyperlane messages are relayed as EVM messages from the same middleware contract, source chain message senders are indistinguishable. Instead, an account can be inserted between Hyperlane message and EVM message recipient that uniquely identifies the origin chain and sender address: an interchain account.

interchain accounts API

The code of an interchain account is a hybrid of ownable access control and multicall functionality. In essence, the interchain account acts as a proxy for the origin chain’s sender address. Legacy systems no longer need to integrate Hyperlane because interchain accounts emulate local contract interactions.

This enables contracts to custody native assets and tokens on other networks without using an asset bridge. Building an interchain asset portfolio management system only requires deployment to a single chain. Existing DAOs, which typically dispatch calls via governance, can use interchain accounts for crosschain governance. A multi-collateral stablecoin can use interchain accounts to rebalance reserves of any remote collateral on a Hyperlane network. The possibilities are abundant.

For other use cases, interchain accounts may not be appropriate. Contracts also frequently do external state lookups to compose with other applications. For example, fetching the market exchange rate between 2 assets on Uniswap. Liquidity for asset pairs varies wildly across networks, and a developer may want to rely on a remote network’s exchange rate. This is possible with the messaging API, but has proven cumbersome due to managing contracts on multiple chains.

For designs that require reading remote state, we present the interchain query API. Using this primitive, developers can make calls against any remote contract on a Hyperlane network. In effect, this generalizes the EVM CALL opcode to be interchain.

interchain queries API

Because this round trip traverses two blockchains, it is inherently asynchronous. To resume control flow in Solidity, developers provide a function to process the return value of the query. This pattern is commonly referred to as a callback, but in future could be expressed using async await like syntax. Please refer to the docs for more detailed usage and security assumptions.

Hyperlane didn’t invent interchain accounts, nor queries. In fact, they originated in the Cosmos community and there is progress toward integration to the IBC protocol (here and here). We are focused on bringing interoperability to every developer and every ecosystem. To that end, we will continue to make the best features from protocols like IBC accessible through Hyperlane.

Today, developers can use Hyperlane interchain accounts and queries between an ever-expanding list of supported networks. We are excited to continue iterating on developer primitives with the rest of the ecosystem to push forward what’s possible at the application layer.