hazehaze

Deploying to HyperEVM: big blocks, small blocks and talking to HyperCore

· 3 min read · by haze

HyperEVM is the EVM that runs next to Hyperliquid's order book (HyperCore). Chain id 999, gas paid in HYPE, and your usual tools work: Foundry, viem, wagmi. But the first deploy usually fails, and the reason is the block design.

Two kinds of blocks

HyperEVM produces two block types side by side:

  • Small blocks: about one per second, with a 2M gas limit. Fast confirmations for normal transactions.
  • Big blocks: about one per minute, with a 30M gas limit. Room for contract deploys and heavy transactions.

Each address is set to one or the other. New addresses use small blocks, and most contract deploys need more than 2M gas, so the deploy can't fit and fails or never lands.

Switching an address to big blocks

The setting lives on HyperCore, not in a transaction. You switch it with a signed Hyperliquid action called evmUserModify (field usingBigBlocks). It costs no gas, but the address needs a Hyperliquid account first (any USDC deposit creates one).

Ways to do it:

  • The HyperEVM big blocks tool checks an address and switches it with your wallet.
  • The Hyperliquid Python SDK has exchange.use_big_blocks(True).
  • Check the result over RPC with eth_usingBigBlocks.

Then deploy as usual, and switch back to small blocks afterwards so your everyday transactions confirm in a second again.

forge script script/Deploy.s.sol \
  --rpc-url https://rpc.hyperliquid.xyz/evm \
  --broadcast --verify

Big blocks have their own gas price. Read it with eth_bigBlockGasPrice, or see both lanes side by side on the live gas tracker.

Reading HyperCore from a contract

Contracts can read HyperCore state through read precompiles at fixed addresses starting at 0x0000000000000000000000000000000000000800: perp positions, spot balances, vault equity, oracle and mark prices, and more. You call them with a static call and decode the result. Mind the units: perp values and spot values don't use the same decimals.

The HyperCore precompile reader calls every precompile live and scales the numbers, which is the quickest way to check what your contract will see.

Sending actions with CoreWriter

To act on HyperCore (place an order, move funds, stake), a contract calls sendRawAction(bytes) on the CoreWriter system contract at 0x3333333333333333333333333333333333333333. The bytes are a version byte, an action id and the ABI-encoded action.

Two things trip people up:

  • The action runs on HyperCore after your EVM transaction, not inside it. You can't read its result in the same call, so design for it to happen asynchronously.
  • If the action is invalid on HyperCore (not enough balance, wrong asset index), the EVM transaction still succeeds. Check the outcome on the HyperCore side.

The CoreWriter action builder builds those bytes for you, or decodes the actions inside an existing transaction.

Moving HYPE and tokens between Core and EVM

Native HYPE moves between HyperCore and HyperEVM through the system address 0x2222222222222222222222222222222222222222. Spot tokens that are linked to an ERC-20 have their own system addresses. The Core ↔ EVM bridge resolver gives any token's system address, EVM contract and decimals, plus the exact transfer to send.

A deploy checklist for HyperEVM

  1. Make sure the deployer has a Hyperliquid account and some HYPE on HyperEVM for gas.
  2. Switch the deployer to big blocks.
  3. Run the deploy script and verify the source.
  4. Move ownership to a multisig.
  5. Switch the deployer back to small blocks.
Building on Hyperliquid? Vaults, CoreWriter strategies, dashboards and trading tools are what i build, including the hyperliquid tools on this site.

more notes