Skip to main content

Warp Route Interface

Developers can use Hyperlane to permissionlessly deploy Warp Routes - contracts that allow any ERC20, ERC721, or native tokens to move effortlessly between chains.

Unlike other token wrapping protocols, Warp Routes are secured by Hyperlane's modular security protocol, allowing developers to specify the security model that governs the minting, burning, and unwrapping of their interchain token.

Overview​

A Hyperlane Warp Route allows a particular token to be moved between chains according to a security model specified by the deployer.

Each Warp Route consists of one contract deployed on every chain that the token can move between. These contracts use the Mailbox to send interchain messages to one another.

When a user transfers from the canonical origin chain to a non-canonical destination chain, their tokens are locked in a HypERC20Collateral contract, which sends a message to the destination chain to mint wrapped tokens.

When a user transfers between non-canonical chains, their wrapped tokens are burned on the origin chain, which sends a message to the destination chain to mint wrapped tokens.

Finally, if a user transfers from a non-canonical origin chain back to the canonical destination chain, their wrapped tokens are burned on the origin chain, which sends a message to the destination chain to release the tokens locked in theHypERC20Collateral contract.

Interface​

Hyperlane Warp Route exposes the following token interface. Warp Route tokens implement this interface, in addition to the standard ERC20 interface.

/// @notice An interchain extension of the ERC20 interface
interface IHypERC20 is IERC20 {
  /**
    * @notice Transfers tokens to the specified recipient on a remote chain
    * @param _destination The domain ID of the destination chain
    * @param _recipient The address of the recipient, encoded as bytes32
    * @param _amount The amount of tokens to transfer
    */
  function transferRemote(
    uint32 _destination,
    bytes32 _recipient,
    uint256 _amount
  ) external payable;
}

Security considerations​

The deployer of a Warp Route can optionally specify the interchain security modules (ISMs) that are used to verify interchain transfer messages.

This means that each Warp Route may have a unique security configuration. Users transferring interchain tokens should understand the trust assumptions of a Route before using it.

Similarly, Warp front-ends should maintain a curated list of known good routes so as to avoid supporting insecure ones. See the Warp UI deployment docs details.

Deploy your Warp Route​

Ready to deploy your Warp Route? It's easy - follow the step-by-step guide.