Comment on page
Warp Route API
Move your token between chains
Developers can use Hyperlane's Warp API to permissionlessly deploy "Warp Routes", contracts that allow ERC20 tokens to move effortlessly between chains.
Unlike other token wrapping protocols, Warp Routes are secured by Hyperlane's modular Interchain security modules protocol, allowing developers to specify the security model that governs the minting, burning, and unwrapping of their interchain token.
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 Messaging API 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 the
HypERC20Collateral contract.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;
}
The deployer of a Warp Route can optionally specify the Interface (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 list of known Routes so as to avoid recommending an insecure Route. The reference UI supports a minor modification to the TokenList standard so that curators can create lists of "safe" Routes.
Last modified 7mo ago