Hooking-Up The Chains: Introducing Hyperlane Hooks

One Interface. Any Protocol. Hooks.

The interoperability space continues to be fragmented, complex, and frustrating building experience. You need to choose between multiple bridge/interoperability providers with known and unknown tradeoffs. You need to trust the bridge not to rug you. You need to build your own integrations for native bridges. It’s a mess.

Hyperlane is here to simplify the interchain building experience. You don’t need to settle for any protocol and go through drawn-out integration processes anymore. You don’t need to trust any one provider or risk being locked-in to their bridge anymore. You don’t need to worry about native bridge integrations anymore.

We believe in arming Hyperlane developers with the most comprehensive set of plug-and-play interoperability options. With Hyperlane: Access any bridge through one interface.

TLDR

• Hooks allow you to easily integrate and dispatch messages through any native/canonical bridge or external bridge. Native bridges will always be the most secure bridge option, and you’ll be able to use them all through one interface.
• Hyperlane is the first interoperability protocol to fully modularize message dispatch and verification.
• You can aggregate Hooks and require consensus among x out of y bridges to verify messages.
• The first hooks built in-house will support OP Stack and an ERC-5164 adapter for cross chain bridges. Importantly, anyone can build Hooks and we encourage the community to contribute.

Leveling Up Modular Security

As per the last post on Modular Security, we are convinced of the benefits of modularizing the security. Developers should use the best security for their applications whenever that is available, there is no one size fits all.

• Sometimes that means using security modules developed and operated by the Hyperlane core team. Other times its folks’ developing themselves, as is the case with fraud proofs for a canonical rollup bridge.
• But there are also existing message bridges that can be leveraged for security. In those cases, you send the Hyperlane message over this message bridge to its equivalent ISM, using that bridge to secure your message.

ISMs are what enables this vision to come true, and operate on the destination chain. However, on the origin chain a message sender was still required to make an explicit call to that external bridge, whether AMB or canonical. This felt unnecessary. We needed something.

Meet Hooks

ISMs unlocked modular security in destination chains, now Hooks allow modular security for dispatch on the origin chain. They generalize into arbitrary post-dispatch hooks that modularize logic that can be executed upon the sending of a message. Now, Interchain gas payments are also just a post-dispatch hook.

• Before the launch, developers would have to build these hooks themselves (to use other bridges and pay relayers) and then call them separately outside the context of a mailbox (i.e. build an aggregation layer yourself).
• Now, developers can just configure these hooks and compose them. That makes using Hyperlane with other security models (like rollup bridges and general bridging protocols) way easier, leading to the more optimal interoperability.

The benefit of modular hooks is easy evolution of best practices over time as well as composition. Most importantly, developers can focus on a single interface to cater to a variety of security needs, even as those needs evolve. No longer will you need to refactor your code base just because you want to utilize a new protocol. Future proof interoperability.

What Can I Do With Hooks?

You can use Hooks to dispatch messages through any native/canonical bridge or external bridge provider.

To get a better grasp of Hooks before we dive into some examples, let’s cover the basics of how they work in conjunction with ISMs. The IPostDispatchHook on the origin chain, and a corresponding HookISM on the destination chain. The IPostDispatchHook provides you the postDispatch method which can be passed to the Mailbox, which will call it automatically after dispatch and transport the message along a particular transport layer/bridge to the HookISM. The ISM just authenticates the msg.sender and stores messageId, upon which the message can then be delivered successfully by the relayer via the Hyperlane Mailbox.

The diagram below illustrates this well. In each case where you’re utilizing Hooks everything else stays unchanged, and IPostDispatchHook and HookISM, alongside the External Provider Source and Destination, are changed to fit the protocol that the Hook is leveraging.

A diagram of a Hyperlane message with Hooks being used

Native Rollup Bridges

This is the most straightforward usage of Hooks, leveraging the rollups’ own bridge in sending a message from L1 to L2, or vice-versa.

Below we illustrate the case of the OpStackHook, built for OpStack chains. We can see the OpStackHook fitting in as the IPostDispatchHook and OpStackISM as HookISM, while the L1CrossDomainMessenger and L2CrossDomainMessenger act as the External Providers on the OpStack chain.

Diagram with the OpStackHook, which lets you leverage the rollup bridge

A similar Hook can be constructed for any rollup framework, and an Arbitrum Orbit hook is currently in construction as well as a Polygon hook.

Example usage of this type of Hook looks like this:

bytes32 messageId = mailbox.dispatch(opStackDomain, recipient, payload, bytes(""), opStackHook);

External Message Bridges

What if you want to use an external bridge, and not just the rollups’ existing one? With Hyperlane, all ERC-5164 compatible interoperability protocols can be used.

This diagram illustrates a Hooks’ example with an external bridge.

As per the code below, the 5164ISM is writing the messageId to storage, which then enables it to be passed through the protocol’s verification mechanism.

contract ERC5164Ism is AbstractMessageIdAuthorizedIsm {
    // ============ Constants ============

    uint8 public constant moduleType =
        uint8(IInterchainSecurityModule.Types.NULL);
    // corresponding 5164 executor address
    address public immutable executor;

    // ============ Constructor ============

    constructor(address _executor) {
        require(Address.isContract(_executor), "ERC5164Ism: invalid executor");
        executor = _executor;
    }

    /**
     * @notice Check if sender is authorized to message `verifyMessageId`.
     */
    function _isAuthorized() internal view override returns (bool) {
        return msg.sender == executor;
    }
}

Interchain Gas Payments

In the Hyperlane stack, we have the InterchainGasPayMaster, which handles paying gas to relayers who are transporting and processing user transactions. With Hooks, IGP interactions is further simplified: the process of paying for Gas, and the code needed to execute it is cut in half.

Before Hooks

// lookup gas amount, igp, and hook for destination
uint256 gasAmount = ...;
IInterchainGasPaymaster igp = ...;
IMessageHook hook = ...;

uint256 quote = igp.quoteGasPayment(destination, gasAmount);
bytes32 messageId = mailbox.dispatch(destination, recipient, body);
igp.payForGas{value: quote}(messageId, destination, gasAmount, msg.sender);
hook.postDispatch(destination, messageId); // old interface that does not allow for behavior dynamic with message content

After Hooks

uint256 quote = mailbox.quoteDispatch(destination, recipient, body);
mailbox.dispatch{value: quote}(destination, recipient, body);

By default, the Hook will pay for 200k of gas, streamlining the experience for developers sending messages especially in the beginning. For more granular control, the gasAmount can be overwritten with metadata.

bytes memory metadata = StandardHookMetadata.formatMetadata(
    1, // msg.value
    uint256(300000), // gas limit
    msg.sender, // refund address,
    bytes("")
);

Additionally, these hooks now standardize the passing of msg.value, either via the external bridges or the Hyperlane relayer.

Composing Hooks

Hooks can be composed in a manner similar to ISMs, akin to building with security legos. The main advantage is that everything can be done from the same interface which is often considered Hyperlane's most unique feature.

Routing per destination chain

With RoutingHook senders can easily specify different bridges per destination chain. Allowing developers to express more granular control in their interchain actions. Use the native rollup bridge when interacting with Optimism and use Hyperlane when interacting with a new rollup or another chain like Solana.

Another example of this type of composing action is setting different IGPs per destination chains, which allows you to use different relayers for different transactions.

Aggregation

With AggregationHook senders can specify multiple hooks to be called, especially useful for AggregationISM. For example, you can aggregate external interop providers like Wormhole, Axelar, LayerZero and require 2 out of 3 of them to reach consensus to verify messages. This is especially useful in the interchain governance use case, which needs to protect against any single bridge failure.

What’s Next

Hooks are already on testnet, and will imminently be on mainnet with the V3 launch (wrapping up audits).

The examples mentioned above are some use cases of what can be achieved with Hooks, but they are not limited to just those. With Hyperlane you can customize your interchain security, integrate native rollup bridges, expand to multi-bridge architecture, all through one interface.

Start building with Hooks now.

More about Hyperlane

Hyperlane is the first Permissionless Interoperability layer, enabling anyone to connect any blockchain, out-of-the-box. With Hyperlane, developers can build Interchain Applications, apps that abstract away the complexity of interchain interactions and serve users on any connected chain. Additionally, Hyperlane’s modular security stack gives developers the power to customize their interchain security. Hyperlane development is open-source and led by core developers at Abacus Works.

Go Interchain with Hyperlane

Start building with our Docs.
Experiment with Hyperlane in 5 minutes with our Quickstarts.
Join our Discord if you have any questions.
Apply to join our crew Here.
Find us on Twitter.