Most blockchains do one thing well and leave everything else to someone else. Hyperliquid flipped that idea on its head. It started as a purpose-built trading chain with a blazingly fast on-chain order book, and then it added something most trading chains never attempt: a general-purpose smart contract layer sitting right beside the exchange engine. That layer is called HyperEVM.
In this guide you will learn what HyperEVM is, how it differs from HyperCore (Hyperliquid’s exchange engine), how smart contracts can read and write directly to the exchange’s state, and the real risks you should understand before using any HyperEVM app. No jargon walls, no hype — just the architecture, the trade-offs, and how to stay safe.
id=”what-it-is”>What HyperEVM Actually Is
HyperEVM is the general-purpose execution environment of the Hyperliquid Layer 1 blockchain. In plain terms: it is an Ethereum-compatible smart contract layer where developers can deploy ordinary Solidity contracts using the same tools they would use on Ethereum — Foundry, Hardhat, Ethers.js, and MetaMask work as expected. It speaks standard JSON-RPC and uses the EVM Cancun hard fork without blob support.
What makes HyperEVM unusual is where it sits. Most EVM-compatible environments are either independent blockchains or layer-2 networks stacked on top of Ethereum, with their own consensus and sequencers. HyperEVM is neither. It is not a separate chain. It runs beside HyperCore — Hyperliquid’s Rust-based exchange engine — and both are secured by the same HyperBFT proof-of-stake consensus, with the same validator set committing both halves of each block. There is no sequencer posting batches to a parent chain and no seven-day withdrawal window.
It went live on mainnet on February 18, 2025, alongside a bug bounty program paying up to $1 million in USDC for critical vulnerabilities. The initial mainnet release supported native spot transfers of HYPE tokens, with general ERC-20 support planned for a later upgrade. Hyperliquid’s native HYPE token is the gas token on HyperEVM: every transaction pays gas in HYPE, and under its EIP-1559 fee model both base and priority fees are burned, which reduces HYPE supply over time.
Think of it this way: HyperCore is the exchange — the deterministic engine matching orders, computing margin, and running liquidations as hard-coded protocol logic. HyperEVM is the programmable playground next door, where anyone can deploy contracts that build on top of, and directly interact with, that exchange.
How HyperEVM Differs from HyperCore
Confusing HyperEVM with HyperCore is the single most common mistake beginners make. They are two execution environments sharing one chain and one consensus — but they do very different jobs, run on different block cadences, and offer very different guarantees.
HyperCore is permissioned code: its matching engine, margin system, and liquidation logic are baked into the node software itself. There is no Solidity inside it and no one can deploy a contract into it. That rigidity is the point — it is how HyperCore sustains on-chain order books that feel like a top-tier centralized exchange, handling roughly 200,000 orders per second while every validator holds an identical copy of the book.
HyperEVM is permissionless code: anyone can deploy a contract, which means anyone can also deploy a broken or malicious one. It uses two block cadences under the same consensus: small, fast blocks (roughly 1-second cadence, ~3M gas limit) for EVM transactions, and larger ~1-minute blocks (~30M gas limit) for heavier execution, alongside the ~2-second order-book settlement rhythm of HyperCore. Two independent mempools keep EVM traffic from queueing behind exchange traffic and vice versa.
The practical consequence: if you are trading perpetuals or spot on Hyperliquid’s native interface, you are interacting with HyperCore — deterministic, fast, and without smart contract risk. The moment you touch a lending protocol, yield vault, memecoin launchpad, or any “app” on Hyperliquid, you have crossed into HyperEVM, where you inherit the standard smart-contract risk surface of any EVM chain. For more on the trading side, see our guide on how to trade on Hyperliquid.
| Property | HyperEVM | HyperCore | Standard EVM chain |
|---|---|---|---|
| Role | General-purpose smart contracts | On-chain order books, margin, liquidations | General-purpose smart contracts |
| Code model | Permissionless Solidity (Cancun, no blobs) | Permissioned, hard-coded in Rust | Permissionless Solidity |
| Consensus | HyperBFT, shared with HyperCore | HyperBFT, shared with HyperEVM | Varies (own consensus/validators) |
| Gas token | HYPE (base + priority fees burned) | HYPE (fee schedule set by protocol) | Native token of that chain |
| Block rhythm | ~1s fast blocks / ~1min slow blocks | ~2s order-book blocks | Varies by chain |
| Exchange-state access | Yes — precompiles + CoreWriter | Native (it is the exchange) | No native exchange; needs oracles/bridges |
| Main contract risk | Smart-contract bugs, malicious dApps | Protocol-level risk, oracle/liquidation risk | Smart-contract bugs, malicious dApps |
| Withdrawals | None needed — same chain | None needed — same chain | Bridge or canonical exit (L2s: ~7 days) |
How Smart Contracts Interact with the Exchange State
The killer feature of HyperEVM is atomic composability with the exchange. On any normal EVM chain, a smart contract that wants exchange data — the price of ETH, your margin position, a spot balance — needs an external oracle, a bridge, or a relayer. Each of those is a trust assumption and a point of failure. On HyperEVM, both halves of the chain are committed by the same validators in the same block, so a contract can reach HyperCore’s exchange state without a bridge or a message-passing protocol.
That opens designs that are awkward or impossible elsewhere. A lending protocol on HyperEVM can liquidate an undercollateralized loan through HyperCore’s native order books rather than routing through an external liquidity pool — selling collateral at real exchange prices with real depth. A vault contract can read your perp position natively and hedge it without trusting a price feed. A trading bot contract can react to on-chain order-book events in the same block they occur.
There is also a two-way street for assets. HyperEVM supports wrapped HYPE (WHYPE) for DeFi use, and the design lets users move HYPE between the HyperCore side and the HyperEVM side. The Hyper Foundation has described a vision where a user could trade a project token with minimal fees and deep liquidity on the native spot order book and seamlessly use the same asset in applications built on the EVM side.
None of this removes smart-contract risk. Composability with deep liquidity is powerful, but it also means a buggy or malicious HyperEVM contract can drain your tokens just as thoroughly as on any other chain. The exchange-state access is a developer feature, not a user safety feature — and as a user, you should treat every HyperEVM app with the same suspicion you would apply to a new Ethereum protocol.
Precompiles and CoreWriter Explained
The “two doors” between HyperEVM and HyperCore are worth understanding, because you will see them named in documentation, audits, and security discussions:
Read precompiles (starting at address 0x…0800). These are special contract addresses built into the node that let any HyperEVM contract read HyperCore state directly: oracle prices, perpetual positions, spot balances, and validator data. Instead of calling an external oracle contract, a developer calls the precompile and gets the exchange’s own canonical data. This eliminates an entire category of oracle-manipulation risk for reads — though it obviously concentrates trust in the correctness of HyperCore’s data itself.
CoreWriter (0x3333…3333). This is the write door. It lets a HyperEVM contract send actions back to HyperCore — for example, placing a spot order or transferring assets — so an app can compose directly with the exchange rather than around it. Writes go through the normal HyperCore execution path with its fee schedule, so contracts cannot bypass exchange rules or fees.
For developers this means familiar tooling with unusual superpowers: Hardhat and Foundry for deployment, plus native access to an order book. For users, the practical takeaway is simpler: whenever a HyperEVM app claims to use “native” prices or “native” liquidity, it is almost certainly talking through these precompiles. That is genuinely better than a third-party oracle — but it says nothing about the app itself being honest or bug-free.
Real Use Cases Being Built on It
Since the February 2025 mainnet launch, a real ecosystem has grown around HyperEVM. Reported figures put the count of projects building on it above 170 by early 2026, with dozens reporting on-chain balances — though much of that ecosystem is young and lightly audited, which is its own risk category.
The categories follow naturally from the architecture:
Lending and borrowing. Protocols can use precompile-fed prices and liquidate through native order-book depth rather than external pools. This is arguably the single most natural fit: the oracle and liquidation rails that lending normally has to bolt on are built into the chain itself.
DEXs and liquidity venues. AMMs and ve(3,3)-style venues have launched on HyperEVM, serving tokens that live natively on the EVM side and routing flows toward HyperCore’s spot books where it makes sense.
Vaults and structured products. Yield vaults and points-based liquidity programs use HyperEVM contracts to manage deposits while the underlying strategies trade on HyperCore’s books. These inherit both smart-contract risk and strategy risk — read the strategy, not just the marketing.
Memecoin launchpads. Permissionless token creation tooling arrived early, as it does on nearly every EVM chain. Expect the usual memecoin risk profile: thin liquidity, insider allocations, and rapid rug potential.
Trading infrastructure. Bots, automation contracts, and analytics tools that read HyperCore state natively through precompiles instead of polling an API.
If you plan to actually use this layer — deploying contracts or connecting a wallet to it — you will need the network configured first. See how to add HyperEVM to MetaMask and how to bridge to Hyperliquid for the practical setup steps.
Risks and Limitations
HyperEVM is powerful, but a balanced view requires the uncomfortable parts:
Smart-contract risk is fully present. Permissionless deployment means malicious and buggy contracts exist on HyperEVM just as they do on Ethereum. The precompiles make reads trustworthy; they do nothing to make a lending protocol’s accounting correct or a vault’s strategy honest. Most of the ecosystem is young and lightly audited — treat new apps accordingly.
Concentrated validator set. The same HyperBFT validators secure both layers. Speed has a structural cost: the validator set is smaller than Ethereum’s or Solana’s, which is worth weighing on the decentralization side of the ledger. Both HyperEVM and HyperCore inherit this property together.
Novel interaction surface. Precompiles and CoreWriter are unusual machinery. Unusual machinery means unusual failure modes — edge cases in how contracts read exchange state during volatile markets, or how writes settle across the two block cadences. The $1M bug bounty signals the team takes this seriously, but novel code carries novel risk.
Young tooling ecosystem. Block explorers, analytics, and security tooling for HyperEVM lag behind Ethereum’s mature ecosystem. Harder verification means harder due diligence for everyday users.
Fake networks and phishing contracts. Because HyperEVM is an EVM chain at chain ID 999, scammers can and do create fake “HyperEVM” network entries with attacker-controlled RPCs, and fake tokens or dApps that mimic real ones. Never add a network from a link someone sends you; type explorer and documentation addresses yourself, and verify contract addresses against official sources.
Frequently Asked Questions
The Bottom Line
HyperEVM is one of the more interesting architectural bets in crypto: a general-purpose EVM layer fused to a high-performance exchange engine, sharing one consensus and letting contracts read and write exchange state natively. For developers it removes oracles and bridges from the equation; for users it means a growing DeFi ecosystem with direct access to deep on-chain liquidity.
But the fusion cuts both ways. The same chain that gives contracts native exchange access gives scammers a new playground of fake networks and phishing dApps, and every app on it carries the standard smart-contract risk of any EVM chain. Understand the architecture, verify everything at the network level, and treat each app on its own merits.
This guide is for education only — not financial advice.
