Routing ISM

Developers can use a RoutingISM to delegate message verification to a different ISM. This allows developers to change security models based on message content or application context.

This ISM simply switches security models depending on the origin chain of the message. A simple use case for this is to use different Multisig ISM validator sets for each chain.

Eventually, you could imagine a DomainRoutingIsm routing to different light-client-based ISMs, depending on the type of consensus protocol used on the origin chain.

Interface

RoutingISMs must implement the IRoutingIsm interface.

// SPDX-License-Identifier: MIT OR Apache-2.0
pragma solidity >=0.8.0;

import {IInterchainSecurityModule} from "../IInterchainSecurityModule.sol";

interface IRoutingIsm is IInterchainSecurityModule {
    /**
     * @notice Returns the ISM responsible for verifying _message
     * @dev Can change based on the content of _message
     * @param _message Formatted Hyperlane message (see Message.sol).
     * @return module The ISM to use to verify _message
     */
    function route(
        bytes calldata _message
    ) external view returns (IInterchainSecurityModule);
}

Configure

The hyperlane-monorepo contains a RoutingISM implementation, DomainRoutingIsm and DefaultFallbackRoutingIsm, that application developers can deploy off-the-shelf, specifying their desired configuration.

Customize

The hyperlane-monorepo contains an abstract RoutingISM implementation that application developers can fork.

Developers simply need to implement the route() function.

By creating a custom implementation, application developers can tailor the security provided by a RoutingISM to the needs of their application.

For example, a custom implementation could change security models based on the contents of the message or the state of the application receiving the message.