Using the Hyperlane CLI
When first deploying with the CLI, a new mailbox uses a Trusted Relayer ISM out of the box so you don’t need to run a relayer or validator. In order to go to production, you’ll need to remove this ISM with the Hyperlane CLI.Prerequisites
- The core config generated by
hyperlane core init.- This config is used to deploy core contracts, including the mailbox. By default, it takes the filepath of
CURRENT_DIR/configs/core-config.yaml.
- This config is used to deploy core contracts, including the mailbox. By default, it takes the filepath of
- The chain that the mailbox was deployed to.
- Access to the private key that currently owns the mailbox.
If you followed the How to Connect Your Chain with
Hyperlane guide, you may have deployed
a mailbox with the owner set to the single private key. In production, it is
advisable to use a multisig.
--chain set to the name of your chain that the mailbox is deployed on:
core read, you should see a similar config with owner set to private key’s address:
CURRENT_DIR/configs/core-config.yaml.
This particular config has a trustedRelayerIsm. This means contracts (e.g., Hyperlane Warp Route) that fallback to the mailbox’s defaultIsm will give permission to relayer address to execute arbitrary messages. This may be undesirable in cases outside of the self-relaying feature.
Follow these steps using the CLI to update the existing default Ism to a different configuration.
Step 1: Update Configuration
Alternatively, you can update therelayer address to something else (e.g., “burn” it by setting it to an inaccessible address).
core-config.yaml
defaultIsm config to a different ISM config. As shown, it is updated to a messageIdMultisigIsm.
core-config.yaml
Step 2: Apply
Using the CLI, execute:Step 3: Confirm
To confirm using the Hyperlane CLI, execute the following:core read, you should see a similar config with the now updated default ISM: