1. Introduction to Hyperliquid
Hyperliquid consists of anEVM named HyperEVM and a L1 network called HyperCore. These networks function together under the same HyperBFT consensus to act as a singular network.
HyperCore includes fully onchain perpetual futures and spot order books. Every order, cancel, trade, and liquidation happens transparently with one-block finality inherited from HyperBFT. HyperCore currently supports 200k orders / second
The HyperEVM brings the familiar general-purpose smart contract platform pioneered by Ethereum to the Hyperliquid blockchain. With the HyperEVM, the performant liquidity and financial primitives of HyperCore are available as permissionless building blocks for all users and builders.

HyperCore
HyperCore, or Core, is a high-performance Layer 1 that manages the exchange’s onchain order books with one-block finality. Communication withHyperCore is done via L1 actions or actions, as opposed to the usual RPC calls which are used for EVM chains. Full list of L1 actions here: Exchange endpoint.
HyperEVM
HyperEVM, or EVM, is an Ethereum Virtual Machine (EVM)-compatible environment that allows developers to build decentralized applications (dApps). You can interact with HyperEVM via traditionaleth_ RPC calls (full list here: HyperEVM JSON-RPC).
HyperEVM has precompiles that let you interact with HyperCore, where spot and perpetual trading happens (and is probably why you are interested in going to Hyperliquid). If you are not listing on HyperCore, then HyperEVM is your almost standard EVM network - you just need to switch block sizes.
Block Explorers:
HyperEVM and HyperCore have their own block explorers. You can find (a list of explorers here).
2. Hyperliquid API
Hyperliquid supports several API functions that users can use on HyperCore to query information, following is an example.- The
tokenIdis the address of the token onHyperCore. - The
evmContractis the address of theERC20token onHyperEVM. - The
deployerTradingFeeShareis the fee share for the deployer of the token.
3. HyperCore Actions
An action as defined by Hyperliquid is a transaction that is sent to theHyperCore - as it updates state on the HyperCore it needs to be a signed transaction from the wallet of the action sender.
You need to use ethers-v6 to sign actions - https://docs.ethers.org/v6/api/providers/#Signer-signTypedData
ethers-v5 EIP-712 signing is not stable: https://docs.ethers.org/v5/api/signer/#Signer-signTypedData
Experimental feature (this method name will change) This is still an experimental feature. If using it, please specify the exact version of ethers you are using (e.g. spcify “5.0.18”, not “^5.0.18”) as the method name will be renamed from _signTypedData to signTypedData once it has been used in the field a bit.You can use the official Hyperliquid Python SDK to interact with
HyperCore.
LayerZero also built an in-house minimal TypeScript SDK that focuses on switching blocks, deploying the HyperCore token, and connecting the HyperCore token to a HyperEVM ERC20 (OFT).
4. Accounts
You can use the same account (private key) on bothHyperEVM and HyperCore. HyperCore uses signed Ethereum transactions to validate data.
5. Multi-Block Architecture
HyperEVM and HyperCore are separate entities, so they have separate blocks, interleaved by their creation order.
HyperEVM Blocks
HyperEVM has two kinds of blocks:
- Small Blocks: Default, 1-second block time, 2M gas limit. For high throughput transactions. OFT deployments are typically larger than 2M gas.
- Big Blocks: 1 transaction per block, 1 block per minute, 30M gas limit. For deploying large contracts.
L1 action of type evmUserModify:
Flagging a user for big blocks means all subsequent HyperEVM transactions from that user will be big block transactions until toggled off. To toggle back to small blocks, set
usingBigBlocks to false.Alternatively, use bigBlockGasPrice instead of gasPrice in transactions.HyperCore Blocks
HyperCore has its own blocks, which means there are 3 block types in total.
As HyperCore and HyperEVM blocks are produced at different speeds, with HyperCore creating more than HyperEVM, the blocks are created in not a strictly alternating manner.
For example, the block sequence might look like this:
6. Precompiles and System Contracts
Hyperliquid uses precompiles in two ways: System Contracts and L1ActionPrecompiles. System Contracts:0x2222222222222222222222222222222222222222: System contract address for theHYPEtoken.0x200000000000000000000000000000000000abcd: System contract address for a created Core Spot token (asset bridge).0x3333333333333333333333333333333333333333: TheCoreWriterfor sending transactions to HyperCore.
0x0000000000000000000000000000000000000801:SpotBalanceprecompile for reading token balances0x0000000000000000000000000000000000000810:CoreUserExistsprecompile for checking account activation
spotBalance(address user, uint64 token): Returns balance information for a user’s token holdings on HyperCorecoreUserExists(address user): Checks if a user account is activated on HyperCoreCoreWriter: Writes to the first producedHyperCoreblock after the production of the EVM block
The Composer implementation uses these precompiles directly for reliable HyperCore interaction.
7. Token Standards
- Token standard on HyperEVM:
ERC20(EVM Spot) - Token standard on HyperCore:
HIP-1(Core Spot)
8. The Asset Bridge: Linking EVM Spot (ERC20) and Core Spot (HIP-1)
For tokens to be transferable betweenHyperEVM and HyperCore, the EVM Spot (ERC20) and Core Spot (HIP-1) must be linked. This creates an asset bridge precompile at an address like 0x2000...abcd (where abcd is the coreIndexId of the HIP-1 in hexadecimal).
Linking Process:
requestEvmContract: Initiated by the HyperCore deployer, signaling intent to link HIP-1 to an ERC20.finalizeEvmContract: Initiated by the HyperEVM deployer (EOA) to confirm the link.
0x2000...abcd) acts like a lockbox.
- To send tokens from HyperEVM to HyperCore: Transfer ERC20 tokens to its asset bridge address on HyperEVM.
- To send tokens from HyperCore to HyperEVM: Use the
spotSendL1 action, targeting the asset bridge address on HyperCore.
HyperCore, the deployer must mint the maximum supply (e.g., u64.max via API) of HIP-1 tokens to the token’s asset bridge address on HyperCore (or to their deployer account and then transfer).
u64.max is the maximum value for a u64 integer, which is 2^64 - 1. It’s a 20-digit number: 18,446,744,073,709,551,615 (18.4 quintillion, or 18 + 18 zeros)- Initial state:
[AssetBridgeEVM: 0 | AssetBridgeCore: 0] - Fund HyperCore bridge:
[AssetBridgeEVM: 0 | AssetBridgeCore: X] - User bridges
X*scaletokens from EVM to Core: User sendsX*scaleERC20 to EVM bridge. - New state:
[AssetBridgeEVM: X*scale | AssetBridgeCore: 0]
9. Communication between HyperEVM and HyperCore
- HyperEVM reads state from HyperCore: Via
precompiles(e.g., perp positions). - HyperEVM writes to HyperCore: Via
eventsat specificprecompileaddresses AND by transferring tokens through the asset bridge.
10. Transfers between HyperEVM and HyperCore
Spot assets can be sent from HyperEVM to HyperCore and vice versa. They are calledCore Spot and EVM Spot. These are done by sending an ERC20::transfer with asset bridge address as the recipient.
To move tokens across:
- Send tokens to the asset bridge address (
0x2000...abcd) on the source network (HyperEVM or HyperCore).- On HyperEVM, this is an
ERC20::transfer(assetBridgeAddress, value) - The event emitted is
Transfer(address from, address to, uint256 value)→Transfer(_from, assetBridgeAddress, value); - The
Transferevent is picked up by Hyperliquid’s backend.
- On HyperEVM, this is an
- The tokens are credited to your account on the destination network.
- Then, on the destination network, send tokens from your address to the final receiver’s address.
11. Hyperliquid Composer
The Composer facilitatesX-network → HyperCore OFT transfers.
Why a Composer?
Users might want to hold tokens on HyperEVM and only move to HyperCore for trading. Auto-conversion in lzReceive isn’t ideal. An lzCompose function allows this flexibility.
Mechanism:
- A LayerZero message sends tokens to Hyperliquid.
lzReceiveon the OFT on HyperEVM mints tokens to theHyperLiquidComposercontract address. - The
composeMsginSendParam(from the source chain call) contains the actual receiver’s address on Hyperliquid. - The
HyperLiquidComposer’slzComposefunction is triggered. - The Composer:
- Transfers the received EVM Spot tokens (ERC20) from itself to the token’s asset bridge address (
0x2000...abcd). ThisTransferevent signals Hyperliquid’s backend to credit the tokens on HyperCore. - Performs an
CoreWritertransaction (to0x33...33) instructing HyperCore to execute aspot transferof the corresponding HIP-1 tokens from the Composer’s implied Core address (derived from its EVM address) to the actual receiver’s address (fromcomposeMsg) on HyperCore.
- Transfers the received EVM Spot tokens (ERC20) from itself to the token’s asset bridge address (
Transfer event is what Hyperliquid nodes/relayers listen to in order to credit the receiver address on Core.
Token Decimals
HyperCore::HIP1 decimals can differ from HyperEVM::ERC20 decimals. The Composer handles scaling. Amounts on HyperCore will reflect HIP-1 decimals. Converting back restores ERC20 decimals.12. LayerZero Transaction on HyperEVM
LayerZero OFT transfers to Hyperliquid use the compose pattern to enable automatic bridging from HyperEVM to HyperCore. How Compose Enables HyperCore Transfers:- OFT Delivery: The LayerZero message delivers tokens to the
HyperLiquidComposercontract address on HyperEVM - Compose Message: The
SendParam.composeMsgcontains the final recipient’s address and any native HYPE amount needed - Automatic Bridging: The Composer’s
lzComposefunction automatically bridges tokens from HyperEVM to HyperCore and transfers them to the final recipient
composeMsg uses a standardized 64-byte format that tells the Composer where to send tokens on HyperCore:
- Activation Check: Uses
coreUserExists()precompile to verify receiver is activated on HyperCore - Bridge Capacity Check: Uses
spotBalance()precompile to check asset bridge capacity - Dual Asset Support: Handles both ERC20 tokens and native HYPE transfers
- Error Recovery: Failed messages are stored in
failedMessagesmapping for later refund
- Failed Message Storage: Messages that fail decoding are stored for crosschain refund
- Automatic Refunds: Failed transfers refund tokens to receiver on HyperEVM
- Gas Protection: Minimum gas requirements prevent out-of-gas failures
- Bridge Capacity Protection: Prevents token locking when bridge capacity is insufficient