Multisig ISM

The MultisigISM is one of the most commonly used ISM types. These ISMs verify that m of n Validators have attested to the validity of a particular interchain message.

​

Multisig Module Types

There are two types of MultisigISM modules:

enum Types {
    ...
    MERKLE_ROOT_MULTISIG,
    MESSAGE_ID_MULTISIG,
    ...
}

​

MerkleRootMultisigIsmMetadata

Type: Types.MERKLE_ROOT_MULTISIG

Format of metadata:

​

MessageIdMultisigIsmMetadata

Type: Types.MESSAGE_ID_MULTISIG

Format of metadata:

​

Interface

MultisigISMs must implement the IMultisigIsm interface.

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

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

interface IMultisigIsm is IInterchainSecurityModule {
    /**
     * @notice Returns the set of validators responsible for verifying _message
     * and the number of signatures required
     * @dev Can change based on the content of _message
     * @param _message Hyperlane formatted interchain message
     * @return validators The array of validator addresses
     * @return threshold The number of validator signatures needed
     */
    function validatorsAndThreshold(
        bytes calldata _message
    ) external view returns (address[] memory validators, uint8 threshold);
}

​

Configure

The hyperlane-monorepo contains MultisigISM implementations (including a legacy version and more gas-efficient versions deployable via factories) that application developers can deploy off-the-shelf, specifying their desired configuration.

To configure a MultisigISM instance:

1. Developers define the set of n Validators on each origin chain.
2. A threshold is set, specifying the number (m) of Validator signatures required to confirm a message.

Validator signatures are not specific to an ISM. In other words, developers can configure their MultisigISM to use any validator that’s running on Hyperlane.

​

Customize

For more specific use cases, developers can fork the abstract MultisigISM implementation provided in the Hyperlane monorepo. The primary customization involves implementing the validatorsAndThreshold() function.

Custom implementations allow developers to adjust the security model to meet the needs of their application. For example, a custom implementation could vary the number of signatures required, based on the content of the message being verified.