HyperCore vs HyperEVM: Hyperliquid's Dual-VM Explained

Two chains wearing one skin

Hyperliquid isn't a single virtual machine with an EVM bolted on for marketing purposes. It's two separate execution environments, HyperCore and HyperEVM, running under the same HyperBFT consensus, producing blocks on the same chain, secured by the same validator set. If you've compared Hyperliquid's architecture to dYdX v4's app-chain design, this dual-VM split is the detail that trips up most people moving over: there is no single unified state that includes both perp positions and EVM contract storage the way an Ethereum L2 has one merkle trie for everything.

HyperCore is the original chain. It's a purpose-built, non-EVM execution layer with one job: match orders, settle perps and spot trades, manage margin, run liquidations. No Solidity, no EVM opcodes, no gas market in the usual sense, just a deterministic order-book engine that every validator executes identically. That focus is what gives Hyperliquid sub-second finality and on-chain order books that behave like a real matching engine instead of an AMM pretending to be one (the consensus mechanics behind that speed are worth understanding on their own; see the breakdown of HyperBFT's finality guarantees).

HyperEVM arrived later as a second execution environment on top of the same chain: a standard EVM with Solidity, Foundry, Hardhat, MetaMask, all the tooling you'd expect. Its job isn't to replace HyperCore's matching engine. It's to let you write programmable logic (vaults, structured products, lending markets, keeper automation) that can observe HyperCore state and, within limits, act on it.

What "shared state" actually means

Marketing copy says HyperCore and HyperEVM "share state." In practice that means shared consensus and block production, not synchronous composability. Each environment keeps its own state tree; a HyperEVM contract doesn't get atomic read-write access to a perp position the way a Solidity contract on Ethereum gets atomic access to another contract's storage in the same call.

Reads are direct and cheap. HyperEVM exposes precompiled contracts at fixed low addresses that let Solidity query HyperCore state inside the same transaction: margin, position size and entry price, oracle and mark prices, spot balances, vault equity. A view call looks like this:

interface IPositionPrecompile {
    struct Position {
        int64 szi;          // signed size, 1e8-scale
        uint64 entryNtl;
        int64 marginUsed;
        int64 leverage;
        int64 unrealizedPnl;
    }
    function position(address user, uint16 perp) external view returns (Position memory);
}

IPositionPrecompile constant POSITION =
    IPositionPrecompile(0x0000000000000000000000000000000000000800);

function isUnderMargined(address vault, uint16 perpIdx, int64 threshold)
    external
    view
    returns (bool)
{
    return POSITION.position(vault, perpIdx).marginUsed < threshold;
}

Writes are where teams get burned. There's no precompile that places an order and settles it inside the same EVM transaction. Instead HyperEVM ships a system contract, CoreWriter, deployed at a fixed address, that accepts encoded actions (place order, cancel, transfer between spot and perp, adjust leverage) and queues them for HyperCore to process. The action doesn't execute atomically with your EVM call; it lands in a subsequent HyperCore block, usually within a second or two, but your contract has already returned control before you know the fill price, or whether the order filled at all.

That asynchronous gap is the single biggest design constraint for building on HyperEVM against HyperCore. You cannot write a vault contract that opens a hedge and checks its resulting P&L in the same call. Design for eventual consistency instead: emit the action, then have a subsequent read (on-chain or off-chain) confirm the resulting state.

Where each one actually earns its keep

Teams building automated strategies usually touch both layers, just for different jobs. A funding-rate arbitrage bot lives and dies on HyperCore's matching engine and fee schedule: speed and fill quality there is the entire trade, and routing anything time-critical through CoreWriter's queue defeats the purpose. A vault that auto-adjusts collateral ratios or runs a keeper-triggered rebalance, by contrast, belongs naturally in HyperEVM, where you get composability with other DeFi primitives and can write real unit tests against a local fork.

We see the same split constantly in liquidation-bot builds: the core loop (scanning positions, computing health factors, submitting liquidation orders) reads HyperCore data through precompiles for speed, while any on-chain accounting, fee splits, or access control sits in a HyperEVM contract that doesn't need to race the clock. It's the same pattern that shows up when comparing order-book venues to pooled-liquidity designs like GMX; see the order-book vs. GLP liquidity comparison for how differently the two models handle depth and slippage.

There's a gas-and-latency wrinkle specific to HyperEVM worth knowing before you commit to an architecture. HyperEVM produces two block types: "small" blocks with low gas limits roughly every second, and "big" blocks with higher gas limits produced less frequently. Contracts that need cheap, fast calls (price checks, simple reads) want small blocks. Anything gas-heavy, like batch operations or dense vault logic, needs to target big blocks. Get this wrong and a transaction either fails on gas or sits waiting for the next big block, adding latency you didn't plan for.

HyperCore vs HyperEVM at a glance

Dimension	HyperCore	HyperEVM
Language / tooling	Native, non-EVM, no Solidity	Solidity, standard EVM tooling (Foundry, Hardhat)
Primary job	Order matching, perp/spot settlement, liquidations	General-purpose smart contracts
Gas model	No traditional gas market; per-trade fee schedule	Gas paid in HYPE; small vs. big block limits
Reading the other side	N/A (source of truth)	Read via precompiles, synchronous, same tx
Writing to the other side	N/A	Via CoreWriter, queued, executes next HyperCore block
Atomicity across VMs	—	None; treat cross-VM calls as eventually consistent
Block cadence	Sub-second, HyperBFT finality	~1s (small blocks) / slower (big blocks)
Best fit	Latency-sensitive trading logic, market making	Vaults, structured products, DeFi composability

Which one to build on

If your logic is a race (market making, funding arbitrage, liquidations), build it against HyperCore directly and treat HyperEVM as a read-only reporting layer at most. Any strategy where fill latency determines profitability shouldn't route orders through an async queue with a one-block delay; that delay is exactly the gap a competing market maker will exploit against you.

If your logic is about composability, accounting, or user-facing automation (a vault that rebalances collateral, a structured product wrapping a perp position, a live account view for users), build it on HyperEVM and lean on the read precompiles heavily. They're fast, free of the async problem, and good enough for anything short of placing time-critical orders.

Most serious products end up as both: a HyperCore-facing execution engine paired with a HyperEVM contract layer for accounting, permissions, and reporting. Don't force one VM to do the other's job; that's the mistake that produces vaults with race conditions and bots carrying gas bills they didn't need. If you're figuring out which side of the split your strategy actually belongs on, talk to us about building it on Hyperliquid.