Skip to main content

How to Bridge a Token with Hyperlane Warp Routes

This section provides a step-by-step walkthrough for creating an interchain token bridge by deploying Hyperlane Warp Route contracts.

Prerequisites​

1. Configuration​

Warp Route deployment config​

To deploy the route, you will need a Warp Route deployment config file. A valid config will specify:

  • Which token, on which chain, is this Warp Route being created for?
  • Optional: Hyperlane connection details including contract addresses for the mailbox, interchain gas, and interchain security modules.
  • Optional: The token standard - this includes fungible tokens using ERC20 or NFTs using ERC721, as well as ERC4626 yield-bearing tokens. Note ERC721 support is experimental and some Hyperlane tooling won't work for NFTs yet.

The easiest way to create one is with the CLI's config command:

hyperlane warp init

This command provides a walkthrough, prompting you for configuration choices directly in the terminal. You will be asked to select specific options for each part of the configuration, such as the network type, chains to connect, token type, and whether to use trusted ISMs.

tip
  • If your config looks correct, you can now skip to Step 2: Deployment. Or see below for details on how to define your config manually.
  • If you need any help setting up a token bridge, reach out on #developers on Discord or get in touch.

Deployment config schema​

Your config consists of a map of chain names to deployment configs. Each config sets details about the token for which you are creating a Warp Route.

  • type:
    • Set this to collateral to create a basic Warp Route for an ERC20/ERC721 token
    • Set this to collateralVault to create a yield-bearing Warp Route for an ERC20 token that deposits into an existing ERC4626 vault
    • Set this to native to create a Warp Route for a native token (e.g. ether)
  • address:
    • If using collateral, the address of the ERC20/ERC721 contract for which to create a route
    • If using collateralVault, the address of the existing ERC4626 vault to deposit collateral into
  • isNft: If using collateral for an ERC721 contract, set to true.

Optional fields​

You may specify the following optional values in your config entries. If no values are provided, the deployer will attempt to pull these values from elsewhere. In the case of metadata (symbol, name decimals), it will query the contract. For addresses (mailbox, ISM) it will check the registry, either yours (if provided) or the default.

  • symbol: The token symbol
  • name: The token name
  • decimals: The number of decimal places for the token
  • mailbox: The address of the mailbox contract to use to send and receive messages
  • interchainSecurityModule: The address of an interchain security modules to verify interchain messages

Example​

For a minimal Warp deployment config example using local anvil chains, see warp-route-deployment.yaml.

Chain Configurations​

The deployment will require basic information about any chains it will be interacting with. If the target chains are not already in the Hyperlane Registry, you must specify chain metadata for them. See the CLI reference for details.

To see what chains are in the currently known, run the following command:

hyperlane registry list

To create a chain metadata config for any other chains, run the following command:

hyperlane registry init

Or you can define the config manually. See the ChainMetadata type for its schema. See chain-config.yaml for an example.

warning

Where possible, be sure to reuse any existing chains from the registry/CLI in your warp route config instead of setting up a new mailbox.

2. Deploy the Warp Route​

Once your configuration is ready, initiate the Warp Route deployment with:

hyperlane warp deploy

During deployment, the CLI requires access to your private key to sign transactions. You can set this up in one of two ways:

  1. Environment Variable: Set your private key as HYP_KEY to avoid entering it each time:

    export HYP_KEY=<your_private_key>

  2. Manual Entry: Alternatively, you can enter the private key directly when prompted during deployment.

The hyperlane warp deploy command will create two new artifact files:

  1. otherchain-yourchain-addresses.yaml: Contains addresses for the newly deployed Warp Route contracts.
  2. otherchain-yourchain-config.yaml: A config file for interacting with the Warp Route via the CLI and Warp UI.

These files will be located under $HOME/.hyperlane/deployments/warp_routes/.

3. Testing​

You can initiate a test transfer of a single wei with the following command:

hyperlane warp send --relay --symbol TOKEN

The --relay flag is optional and will relay the message to the destination chain.

You can also run a relayer that delivers only for your warp route in the background with:

hyperlane relayer --symbol TOKEN

You can test in either direction between where you have the warp route set. However, if you deployed native and synthetic warp routes, you must select the origin with the native route deployed. By default, the amount sent is 1 of the smallest unit of the token.

tip

Next Steps

Learn More​

  • Check out the Warp Route reference page for more information on the interface and security implications of a Warp Route. The interface section covers calling transferRemote to transfer tokens to a specified recipient on a destination chain. Note that you'll have to prompt for a token approval prior to calling transferRemote.

  • A Warp Route is a type of router application, a pattern enabling you to link multiple contracts across chains together.