Comment on page
Routing ISM
Smarter interchain security models
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. RoutingISMs must implement the IRoutingIsm interface.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);
}
The hyperlane-monorepo contains a
RoutingISM implementation, DomainRoutingIsm, that application developers can deploy off-the-shelf, specifying their desired configuration.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.The hyperlane-deploy repo contains the tooling and instructions needed to deploy and configure a
DomainRoutingIsm.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.
Last modified 4mo ago