HyperEVM is Hyperliquid's general-purpose EVM: the network a wallet adds as chain ID 999, where contract calls burn HYPE as gas. HyperCore is the onchain order-book environment, Ethereum mainnet uses chain ID 1 and burns ETH, and those three labels share wallet tooling while still naming three different ledgers.
How Hyperliquid works covers HyperCore and HyperEVM on one chain, and HyperEVM is the contract half. A wallet screen can look like Ethereum while the books still live on HyperCore, and adding a custom network is how you point that screen at chain ID 999.
What the HyperEVM is
HyperEVM is the Ethereum-style contract environment on Hyperliquid. An EVM, or Ethereum Virtual Machine, is the runtime that executes Solidity contracts, a chain ID is the integer a wallet uses to tell networks apart, and JSON-RPC is the HTTP API that wallet extensions speak when they send those calls. Independent RPC docs describe HyperEVM as the Ethereum-compatible smart contract layer (chain ID 999) where you deploy Solidity contracts (source: Chainstack, Hyperliquid getting started). Compatible tooling still leaves you on Hyperliquid's ledger, even when a MetaMask skin looks identical.
| Label | Chain ID | What you are looking at |
|---|---|---|
| HyperEVM | 999 | Contract RPC. HYPE gas. |
| Ethereum mainnet | 1 | Ethereum. ETH gas. |
| HyperCore book | none on this RPC | Native books. Signed actions. |
HyperCore books use signed trading actions through the Hyperliquid app, so they sit outside that JSON-RPC field, while Ethereum mainnet is a different chain, with its own RPC host and ETH as gas.
Suppose you open Add Custom Network: paste Ethereum's RPC and chain ID 1, and you stay on Ethereum paying ETH for gas, or paste Hyperliquid's RPC with chain ID 999, and you are on HyperEVM paying HYPE. The book you trade on is a third surface, reached through Hyperliquid's own app, off that custom-network form.
How HYPE pays gas on chain ID 999
HYPE is the gas asset on HyperEVM, so a contract call burns HYPE on chain ID 999. ETH that already sits in the same wallet on Ethereum mainnet stays on chain ID 1, because the gas balance and the chain ID travel together.
What Hyperliquid is covers HYPE as the native token, and the EVM-half fact is narrower: that coin is what the RPC face spends. Official onboarding copies Ethereum's fee shape on purpose, so the HyperEVM uses the same gas system as Ethereum and many L2s, with a base fee and a priority fee. Shared state is also why the first rollout stayed tight. Because HyperCore and the HyperEVM share the same state, the project says it is technically risky to allow the HyperEVM to consume more bandwidth on initial launch (source: Hyperliquid Docs, How to use the HyperEVM). That is a capacity hedge the project states. How EIP-1559 sets a base fee is the Ethereum version of the same two-part bill.
You can hold ETH and HYPE in one extension, and the ETH row pays calls on chain ID 1, while the HYPE row on HyperCore spot pays gas only after it sits on the EVM half. A wrapped ticker is a later convenience, and native HyperEVM HYPE is counted to 18 decimals on that half, which is a unit scale.
If the call needs gas, the asset is HYPE on 999.
The Cancun hardfork HyperEVM uses
HyperEVM follows the Cancun hardfork family and omits blob-carrying transactions, so the tooling generation can look familiar while the data path still skips Ethereum's proto-danksharding lane, and that missing blob type is the holder tell.
Developer docs put the cut in one sentence. HyperEVM consists of EVM blocks built as part of Hyperliquid's execution, inheriting all security from HyperBFT consensus, which is a claim the project makes about its own execution. "The HyperEVM uses the Cancun hardfork without blobs." Mainnet chain ID is 999, with a separate RPC host from testnet (source: Hyperliquid Docs, HyperEVM for developers).
Ethereum's Dencun upgrade is what blobs refers to on that other chain. The introduction of Proto-Danksharding in the Dencun upgrade adds cheaper data storage for these proofs by only requiring node operators to store this data for about 18 days (source: ethereum.org, Dencun). Hyperliquid is its own L1, so HyperCore books stay off those blobs, and what proto-danksharding changed is the Ethereum lesson.
Suppose you port a contract with ordinary Cancun-era tooling: Solidity syntax still compiles, and a blob transaction that Ethereum rollups use for cheap data has no lane here, so generic Solidity is a boundary. How Ethereum smart contracts work is the account-and-map version of the job HyperEVM reuses.
Cancun-family opcodes can show up, blob space stays on Ethereum, and chain ID 1 stays Ethereum.
Fast and slow HyperEVM blocks
HyperEVM splits its own throughput into fast small blocks and slower large blocks, which is two block sizes on one EVM, under one increasing HyperEVM height, still one chain beside HyperCore, with one validator set. A small send can land on the fast size while a fat deploy waits on the slow one.
The architecture page states the split: the total HyperEVM throughput is split between small blocks produced at a fast rate and large blocks produced at a slower rate, and the mempool that feeds those sizes is still chain state, with a tight queue. The onchain mempool implementation accepts only the next 8 nonces for each address, and live gas limits on that page move with upgrades, so they are configuration (source: Hyperliquid Docs, Dual-block architecture).
| Block size | Job |
|---|---|
| Fast small | Quick confirmation. |
| Slow large | Bigger deployments. |
| HyperCore book | Fills. Signed book actions. |
One HyperBFT round feeds both environments, and the EVM-half fact is only this: two EVM block sizes interleaved under one height, pulling from two independent mempools under the same L1 execution. If you queue a ninth send before eight earlier nonces land, the extra one sits outside that window, still off the book.
Fast versus slow is a HyperEVM traffic rule, HyperCore matching still sits on the other environment, and you pick no second chain ID to get the slow size.
How HYPE moves from HyperCore spot to HyperEVM
Moving HYPE from HyperCore spot onto HyperEVM is a system transfer into native gas, a hop between two environments on one L1, and the coins land as native HYPE that a contract call can burn. Other spot tokens need a link first, because sending the wrong asset through the HYPE transfer address can still lose funds.
Transfers docs make HYPE the special case: as the native token on HyperCore, HYPE also links to the native HyperEVM balance rather than an ERC-20 contract, and the same page refuses a lazy 1:1 story. "Do not blindly assume accurate fungibility between Core and EVM spot." (source: Hyperliquid Docs, HyperCore to HyperEVM transfers). That caveat is about linked contracts and decimals.
Suppose you hold 200 HYPE on HyperCore spot and want 50 as HyperEVM gas: you send 50 through the HYPE system transfer, and those 50 land as native gas on 999, while the 150 you leave behind can still rest on spot. If you send a different spot token to that same HYPE address, the onboarding note is that those units can be lost, and each other spot asset has its own transfer address once it is linked.
How HyperCore's onchain book works is the other half of that send. Routes in from Bitcoin, Ethereum, Solana, and the rest, plus what each route trusts, sit in Hyperliquid deposits and bridges, which is the foreign-chain question, while this hop stays Core-to-EVM.
There is no foreign-chain bridge between Core and EVM, and you can still destroy units by using the HYPE transfer address for the wrong asset.
How HyperEVM contracts read HyperCore
A HyperEVM contract can query HyperCore through read precompiles, and a system contract exists for sending HyperCore actions. Shared state is one committed list, so your HyperCore spot row and your HyperEVM gas row still settle as two balances.
The holder landing page states the product goal without a ranked app list. A theme of the HyperEVM is to abstract away the deep liquidity on HyperCore as a building block for arbitrary user applications, which is a claim the project makes about composition (source: Hyperliquid Docs, HyperEVM). How Hyperliquid apps split across two environments is the catalog question.
The developer interaction page is where the addresses live. The testnet EVM provides read precompiles that allow querying HyperCore information, and those precompile addresses start at 0x0000000000000000000000000000000000000800. A system contract is available at 0x3333333333333333333333333333333333333333 for sending transactions from the HyperEVM to HyperCore, while encoding internals stay a builder surface (source: Hyperliquid Docs, Interacting with HyperCore). A later leader cannot un-place a committed HyperCore rest just because an EVM call asked for it, and delay plus duplicate explorer entries for write actions sit in the parent architecture guide.
Suppose a lending UI reads a book price: the read is a precompile, the fill is still a book action, and the call still fails if your gas sits on HyperCore spot. Ordinary account hygiene still applies, because an onchain read leaves the usual security job in place.
If you came for a contract, you are on 999 with HYPE in the gas balance, and if you came for a bid, you wanted HyperCore.
Where HyperEVM fits if you already hold HYPE
If you already hold HYPE on BloFin, you are on a centralized listing. Native HyperEVM remains a competing venue's contract half, so weigh that split before you treat an exchange balance as gas.
Chain ID 999 is the contract RPC, a CEX HYPE row is a different instrument, and that is the holder cut, separate from a runbook for adding the network.
BloFin HYPEUSDT is live at 75x, listed December 19, 2024 11:30 UTC, and HYPE/USDT is live, listed May 30, 2025 13:30 UTC. Those instrument IDs are BloFin ledger lines, so they skip HyperEVM fills, they skip HYPE as chain-999 gas, and they skip HyperEVM's dual-block mempool. HYPERUSDT on the same venue is Hyperlane, a different listing, so a ticker collision leaves the EVM question untouched.
You do not need to memorize precompile indexes, but you do need the three-way split of chain ID 999, the HyperCore book, and Ethereum mainnet, plus which balance pays gas. Ethereum dapps still helps if contract apps are new. If you want the wiring again, start with the parent architecture guide, and if you want the book, start with HyperCore, while a contract still needs HYPE on the EVM half before you sign.
Frequently asked questions
If I set chain ID 998 but keep RPC rpc.hyperliquid.xyz/evm, am I on HyperEVM testnet?
No. Official developer docs pair testnet 998 with rpc.hyperliquid-testnet.xyz/evm, so editing only the chain ID field while the host stays on the mainnet RPC is a broken custom network, and independent RPC docs reprint that host split. HYPE on 999 will not pay a 998 deploy, and a wallet label that still says Hyperliquid leaves the host unfixed.
Can I subscribe to new HyperEVM heads over a websocket on rpc.hyperliquid.xyz/evm?
No. Official developer docs say that public host currently has no websocket JSON-RPC, though other RPC implementations may, so a vendor RPC that advertises eth_subscribe is a different server. Add-network still uses HTTPS JSON-RPC, and if a UI shows live heads without that vendor, it is polling, which means chain ID 999 implies no socket on the public URL.
If I leave a HyperEVM transaction pending for more than a day, does it stay queued?
No. Dual-block docs prune mempool transactions older than 1 day, which is a HyperEVM mempool rule, so a stale send stays off the book and you re-sign after the prune. An unsigned intent in a wallet draft is absent from that mempool, and confirmation still follows the fast or slow EVM block size.
Can HyperEVM contracts write to HyperCore after the CoreWriter update?
Treat the holder page's write fence as older alpha copy. Galaxy Research dated a CoreWriter update to July 5, and that note says the update lets HyperEVM contracts write to HyperCore, including placing orders. The holder page still carries a not-live fence, so those two voices disagree. Confirm a pool write on an explorer before you treat a contract call as a HyperCore rest (source: Galaxy Research, Hyperliquid's L1).
If a linked ERC-20 uses extra wei decimals, does a non-round transfer credit in full?
No. Transfers docs say if the emitted log value is not round in those extra decimals, the non-round amount is burned, and that dust is guaranteed to be under 1 Wei, which is a linking caveat. Round the send, or expect the dust to vanish, because native HYPE uses a different transfer address than a linked ERC-20, and a BloFin spot fill skips this rounding rule.
Will a BloFin HYPEUSDT withdrawal arrive on chain ID 999?
Not by default. Official user docs tell you to confirm a CEX supports HyperEVM, because some venues credit HyperCore spot and not the EVM half, and BloFin HYPEUSDT and HYPE/USDT are CEX listings. A withdrawal to an address you added as 999 is a different route, with its own deposit and bridge checks, while HYPERUSDT on the same board is still Hyperlane.
Does sending HYPE from HyperEVM back to HyperCore spot burn the same gas balance as the inbound hop?
No. Official onboarding says sending from the HyperEVM to Spot balances costs gas in HYPE on the HyperEVM, and sending from Spot to the HyperEVM costs gas in HYPE on HyperCore Spot, so those are two balances on one coin. A BloFin HYPE/USDT fill pays neither burn, and CoreWriter asks the book without picking which balance the hop uses.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on HyperEVM, dual-block architecture, Core-to-EVM transfers, and HyperCore interaction, plus Chainstack's Hyperliquid RPC reference and ethereum.org's Dencun overview. Protocol facts independently verified against cited sources current as of August 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, smart-contract risk, venue risk, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, or trade on HyperEVM or on BloFin. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.