HyperCore vs HyperEVM: Which Layer Does What?
HyperCore is Hyperliquid's native financial engine; HyperEVM is the programmable EVM environment beside it. They share one L1 but serve different workloads.
HyperCore and HyperEVM are two execution environments inside the same Hyperliquid blockchain. HyperCore owns native financial state such as spot and perpetual order books, positions, margin, and liquidations. HyperEVM runs EVM smart contracts and gives developers a familiar environment for applications. HyperBFT secures both, and dedicated interfaces let them read from and write to each other.
What belongs in HyperCore
HyperCore is optimized for actions that define Hyperliquid's native markets. A perpetual order, spot order, cancellation, margin update, funding payment, or liquidation belongs to this environment. These are not Solidity contracts deployed by a DEX team. They are protocol-level state transitions.
That specialization allows the network to treat ordering, matching, risk checks, and market state as first-class operations.
What belongs in HyperEVM
HyperEVM is where general-purpose application logic lives. ERC-20 contracts, lending markets, AMMs, vaults, staking wrappers, routers, and other EVM applications can be built with familiar tooling.
HyperEVM uses HYPE as gas and follows EVM transaction semantics. A contract can have bugs or governance risks independently of HyperCore, so users should distinguish “built on HyperEVM” from “native HyperCore functionality.”
How the two communicate
Read precompiles expose selected HyperCore state to HyperEVM contracts. A contract can inspect information such as balances, positions, oracle data, or other supported native state without depending exclusively on an offchain oracle.
CoreWriter provides the opposite direction for supported actions. HyperEVM contracts can encode an action that the protocol later processes on HyperCore. Asset-transfer mechanisms also move supported assets between the two environments.
This creates an important design pattern: a contract can use native financial state without rebuilding the matching engine, while HyperCore remains specialized and relatively constrained.
How to decide which surface to use
If you are trading native spot or perps, you are primarily interacting with HyperCore. If you are supplying assets to a HyperEVM lending market, swapping through a HyperEVM AMM, or calling a smart contract, you are interacting with HyperEVM.
Builders should ask a similar question. If the product needs exchange state, read it through the supported native interfaces. If it needs to submit a supported native action, use CoreWriter or the appropriate API. If the product's core logic is arbitrary programmable state, place that logic in HyperEVM.