Using the Hyperlane CLI
When first deploying with the CLI, new HWR use 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 warp route ID.
- After deployment, the warp route ID is saved to the registry at
$HOME/.hyperlane/deployments/warp_routes/<warpRouteId>. - The format is
SYMBOL/id(e.g.,ETH/yourid). - To list existing warp route IDs:
ls $HOME/.hyperlane/deployments/warp_routes/
- After deployment, the warp route ID is saved to the registry at
- Access to the private key that currently owns the HWR.
If you followed the Deploy a Warp
Route guide, you most likely have
deployed a HWR with a trusted relayer set to a signer address.
warp read, you should see a similar config under interchainSecurityModule containing a trustedRelayerIsm:
trustedRelayerIsm as part of the staticAggregationIsm.
This means that the relayer address will be allowed to call the HWR’s handle() function. In other words, the relayer can execute arbitrary messages on the HWR. This may be undesirable in cases outside of the self-relaying feature.
Warp route configs are stored in your local registry at
$HOME/.hyperlane/deployments/warp_routes/<warpRouteId>/. The warp read command outputs the current on-chain config for reference.Step 1: Configuration
Update the warp route deployment config in your local registry by removing thetrustedRelayerIsm block from modules. Alternatively, you can configure the entire modules block as desired.
warp-route-deployment.yaml
Step 2: Apply
Using the CLI, execute:Step 3: Confirm
To confirm that the trusted relayer was successfully removed using the Hyperlane CLI, run the following command with your token symbol and the chain it is deployed on:warp read, confirm that the trusted relayer ISM has been removed from your HWR (In this example, it should only contain the remaining defaultFallbackRoutingIsm). You should see a similar config under interchainSecurityModule: