HyperCore is the trading state machine
HyperCore contains the native spot and perpetual order books, matching, margining and settlement. Hyperliquid states that the system is fully onchain and currently supports 200,000 orders per second under its published architecture claims.
The performance statements are protocol claims and are not independent benchmarks by this site. Native exchange actions use HyperCore’s API and signed action model rather than generic EVM transactions.
HyperEVM is EVM execution on the same consensus
HyperEVM provides smart-contract execution secured by HyperBFT. The official docs describe it as part of the same chain rather than a separate chain. Mainnet uses chain ID 999, HYPE as the gas token and the public RPC at rpc.hyperliquid.xyz/evm.
The environment supports Cancun-era EVM behavior with documented differences such as no blob support. Check the developer docs for current block limits and precompiles before deploying.
Core–EVM connectivity is the important frontier
HyperEVM applications can interact with HyperCore assets and state through system mechanisms documented by Hyperliquid. The documented system mechanisms make trading liquidity composable with contracts while preserving distinct execution semantics.
Developers should model asynchronous boundaries, decimal conventions and failure handling explicitly. An EVM transaction succeeding does not automatically prove a downstream HyperCore economic action completed as intended.
Which interface should you use?
Use the exchange API for native market data and trading actions. Use HyperEVM JSON-RPC and contract tooling for smart contracts. A product that touches both should keep the two clients, signing formats and rate limits separate.
Trace every user action to the environment that owns the resulting state. A HyperEVM transaction hash proves EVM inclusion; a HyperCore order status proves exchange-state execution. Products that display one as evidence of the other can show a false success during delayed or failed cross-environment work.