Native Transfers

Spot assets can be sent between the L1 and the EVM. Spot assets on the L1 are called native spot while ones on the EVM are called EVM spot. The spot deployer can link their native spot asset to any ERC20 contract deployed to the EVM. The native spot asset and ERC20 token can be deployed in either order. The only native transfer currently enabled on mainnet is for HYPE.

In order for transfers between the two to work the system address (0x2222222222222222222222222222222222222222) must have the total non-system balance on the other side. For example, to deploy an ERC20 contract for an existing native spot asset, the system contract should have the entirety of the EVM spot supply equal to the max native spot supply. Once this is done the spot deployer needs to send a spot deploy action to link the token to the EVM:

/**
 * @param token - The token index to link
 * @param address - The address of the ERC20 contract on the evm.
 * @param evmExtraWeiDecimals - The difference in Wei decimals between native and EVM spot. E.g. native PURR has 5 weiDecimals but EVM PURR has 18, so this would be 13. evmExtraWeiDecimals should be in the range [-2, 18] inclusive
 */
interface RequestEvmContract {
  type: “requestEvmContract”;
  token: number;
  Address: address;
  evmExtraWeiDecimals: number;
}

After sending this action, the L1 will store the pending EVM address to be linked. The deployer of the EVM contract must then verify their intention to link to the L1 token in one of two ways:

1. If the EVM contract was deployed from an EOA, the EVM user can send an action using the nonce that was used to deploy the EVM contract.

2. If the EVM contract was deployed by another contract (e.g. create2 via a multisig), the contract's first storage slot must store the L1 deployer's address. This can be done at initialization by defining the first state variable in solidity.

The confirm the final, the EVM deployer sends the following action (note that this not nested in a spot deploy action).

/**
 * @param input - One of the two EVM deployer options above
 */
interface FinalizeEvmContract {
  type: “finalizeEvmContract”;
  input: {"create": {"nonce": number}} | "firstStorageSlot"};
}

Once a token is linked, it can be converted between native and EVM spot by sending the token to the system address (0x2222222222222222222222222222222222222222). This can be done on the L1 using a spotSend action (or via the frontend) and on the EVM by using an ERC transfer. There are currently no checks that the system address has sufficient supply or that the contract is a valid ERC20, so be careful when sending funds.

EVM PURR has been deployed as 0xa9056c15938f9aff34CD497c722Ce33dB0C2fD57

HYPE is a special case as the native gas token on the EVM. HYPE is received on the EVM side of a transfer as the native gas token instead of an ERC20 token. To transfer back to the L1, HYPE can be sent as a transaction value. The EVM transfer address 0x222..2 is a system contract that emits event Received(address indexed user, uint256 amount) as its payable receive() function. Here user is msg.sender, so this implementation enables both smart contracts and EOAs to transfer HYPE back to the L1. Note that there is a small gas cost to emitting this log on the EVM side.

Attached is a sample script for deploying an ERC20 token to the EVM and linking it to a native spot token.

39KB

erc20_example.py