What is HyperEVM and why does it matter for on-chain traders?

• 18 Feb 2025 - HyperEVM mainnet launch date
• $172B+ - Hyperliquid 30-day volume at time of writing
• 73% - Hyperliquid's share of on-chain perpetual market share
• $1.24B - Hyperliquid all-time fees generated, with annualized revenue in the $800M-$1B range

Contents

1. The short version
2. What HyperEVM actually is
3. Why Hyperliquid built a separate EVM layer
4. How the dual-block architecture works
5. HyperBFT: one consensus, two execution environments
6. HYPE as gas, and how fee burning works
7. How HyperCore and HyperEVM talk to each other
8. What's actually live on HyperEVM right now
9. What composability with the CLOB means in practice
10. What HyperEVM does NOT change for perp traders
11. Real risks you should know
12. Where Stacked Markets fits
13. FAQs

Hyperliquid is running over $172B in 30-day volume and holds 73% of on-chain perpetual market share. That engine runs on HyperCore - the matching and settlement layer. HyperEVM is something different, and the distinction matters if you're building strategies, deploying collateral, or evaluating whether any of the new DeFi protocols on Hyperliquid are worth touching.

This article covers what HyperEVM is mechanically, why it was built as a separate layer rather than folded into HyperCore, how the two layers communicate, and what it actually changes - and doesn't change - for traders already operating on Hyperliquid.

The short version

HyperEVM is a general-purpose EVM execution environment running on the same Hyperliquid L1 as HyperCore. It is not a separate chain. It shares HyperBFT consensus with HyperCore, inheriting the same validator set and finality guarantees, but maintains separate state, separate gas accounting, and a separate execution context.

HyperEVM launched on mainnet on 18 February 2025. Since then, a range of DeFi protocols has deployed on it - lending markets, a CDP stablecoin, automated yield vaults, and more. The key point for traders: HyperEVM adds programmability to the Hyperliquid ecosystem without touching the perp trading engine.

What HyperEVM actually is

Most EVM chains are one thing: a general-purpose execution environment where smart contracts run and tokens move. Hyperliquid is structured differently. HyperCore handles the financial primitives - perpetual futures, spot markets, the on-chain central limit order book, margin accounting, funding rates, and liquidations. It is purpose-built for speed and predictability.

HyperEVM sits alongside HyperCore on the same L1. It runs standard Solidity contracts, and any EVM-compatible wallet, tool, or protocol can interact with it using familiar interfaces. The environment is Cancun-era compatible, meaning it supports EIP-4844 blob transactions and the base-fee plus priority-fee model.

HyperEVM is not a layer 2, and it's not a sidechain. It runs on the same Hyperliquid validators under the same consensus round. The separation between HyperCore and HyperEVM is logical - different state, different execution - not physical.

Why Hyperliquid built a separate EVM layer

The obvious question is why Hyperliquid didn't just add smart contract support directly to HyperCore. The answer comes down to preserving what makes HyperCore useful in the first place.

HyperCore achieves sub-second order matching by keeping execution deterministic and gas-free. There are no Solidity contracts in the matching path, no gas auctions, and no risk that a poorly written contract introduces latency spikes or state corruption into the order book. That's a deliberate design choice, not a limitation.

Putting general-purpose smart contract execution inside HyperCore would create three concrete problems:

• Latency contention. Complex contract calls compete with order matching for execution time. On any chain where contracts and financial primitives share the same execution queue, congestion produces unpredictable latency.
• Gas market interference. A gas auction inside the matching engine would mean high-fee contract calls could crowd out order submissions - or that order matching would need to participate in fee markets it was never designed for.
• Contract bug exposure. A Solidity bug in a lending protocol should not be able to affect the integrity of the perpetuals order book. Separation ensures that HyperEVM contract failures stay contained within HyperEVM state.

The dual-layer design addresses all three. HyperCore stays fast and predictable. HyperEVM gets full programmability. Failures in one layer don't propagate to the other.

How the dual-block architecture works

HyperEVM uses two block types, each sized for different workloads.

Small blocks carry a 2 million gas limit. These handle lightweight operations - token transfers, simple swaps, state reads. They process frequently and keep latency low for common interactions.

Large blocks carry a 30 million gas limit. These are for heavy contract calls: complex DeFi interactions, vault rebalancing, multi-step liquidations. They process less frequently and aren't suited for time-sensitive trading operations.

This split matters if you're building on HyperEVM or interacting with protocols that run complex logic. A transaction that fits in a small block settles faster than one requiring a large block. Protocols that batch operations or run automated strategies need to account for which block type their calls land in.

One operational note: the public RPC endpoint has been rate-capped at 100 requests per minute since August 2025. If you're running high-frequency queries against HyperEVM state, you'll need a private RPC or an indexer.

HyperBFT: one consensus, two execution environments

HyperBFT is the consensus mechanism that finalizes both HyperCore and HyperEVM state. Both layers share the same validator set and the same finality round - which is what makes HyperEVM genuinely part of Hyperliquid L1 rather than a separate chain that happens to run nearby.

From a security standpoint, HyperEVM inherits the same validator concentration risk as HyperCore. If the validator set were to act dishonestly or experience coordinated failure, both layers would be affected. That's not unique to Hyperliquid - it applies to any single-consensus system - but it's worth stating plainly. Using HyperEVM does not give you independent security from HyperCore.

The benefit of shared consensus is that state transitions on both layers finalize in the same round. There is no cross-chain bridge between HyperCore and HyperEVM in the traditional sense. Token transfers between the two layers use a system-level mechanism, not an external bridge contract, which removes one category of bridge exploit risk.

HYPE as gas, and how fee burning works

HYPE is the native gas token on HyperEVM. Every transaction pays gas in HYPE, following the Cancun-era EIP-1559 structure: a base fee that adjusts with block utilization, plus an optional priority fee to tip validators. Base fees are burned.

This creates deflationary pressure on HYPE supply proportional to HyperEVM activity. As of May 2026, HYPE trades at approximately $60.97. Hyperliquid has generated $1.24B in all-time fees, with annualized revenue in the $800M-$1B range - figures that reflect HyperCore activity primarily, but give useful context for the scale of the ecosystem HYPE is denominated in.

If you hold HYPE for trading or staking, HyperEVM activity affects token economics through fee burns. More HyperEVM usage means more HYPE burned per block. That's a real mechanic, not a marketing claim.

How HyperCore and HyperEVM talk to each other

The connection between HyperCore and HyperEVM is built into the protocol at the system level. Two components handle the flows in each direction.

The spot_transfer() system address handles token transfers from HyperCore to HyperEVM. When you move a spot asset from HyperCore into HyperEVM, the system address processes the transfer without routing through an external bridge contract. This was part of the March 2025 mainnet rollout that established the token linking standard.

The CoreDepositWallet handles the reverse - moving assets from HyperEVM back into HyperCore margin or spot balances. Protocols on HyperEVM can call into this wallet to route collateral back to HyperCore.

The practical implication: a smart contract on HyperEVM can read HyperCore state - including order book depth and position data - and trigger actions based on what it reads. That's the foundation of composability between the two layers.

On May 14, 2026, Circle expanded USDC as an Aligned Quote Asset (AQA) on Hyperliquid, deepening USDC's role in the ecosystem and giving HyperEVM protocols another well-capitalized stablecoin to build around.

What's actually live on HyperEVM right now

Several DeFi protocols have deployed on HyperEVM since the February 2025 launch.

HyperLend is an overcollateralized lending market on HyperEVM. Traders can post collateral and borrow against it - mechanics similar to Aave or Compound on Ethereum mainnet.

Felix Protocol is a CDP stablecoin system. You lock collateral, mint a stablecoin, and manage the position. The mechanics are analogous to Liquity or MakerDAO.

Hypurrfi is another overcollateralized lending protocol, focused on assets native to the Hyperliquid ecosystem.

Hyperbeat and Morphobeat are automated yield vaults that deploy capital into yield-generating strategies and rebalance automatically. Morphobeat specifically integrates with Morpho's lending infrastructure.

Summer.fi has integrated with HyperEVM, bringing its position management and automation tooling to the ecosystem.

Reactive Network provides event-driven automation on HyperEVM. Contracts can trigger based on on-chain events - price levels, position thresholds, oracle updates - without requiring an off-chain keeper.

Each of these protocols carries its own smart contract risk. HyperEVM is EVM-compatible, which means Solidity bugs, oracle manipulation, and liquidation edge cases are all live risks. The separation from HyperCore means those risks stay contained within HyperEVM - but they are real.

What composability with the CLOB means in practice

The most interesting thing about HyperEVM for active traders isn't the lending protocols or the CDP stablecoin. It's the ability to write on-chain strategies that interact directly with Hyperliquid's central limit order book.

Because HyperCore and HyperEVM share the same L1 and communicate through system-level primitives, a smart contract on HyperEVM can:

• Read live order book state from HyperCore without an external oracle
• Trigger collateral movements from HyperEVM into HyperCore margin based on on-chain conditions
• Route yield from HyperEVM lending protocols into perp margin automatically
• Execute multi-step strategies spanning both layers within the same finality round

This is qualitatively different from what's possible on Ethereum mainnet, where a perp protocol and a lending protocol are separate contracts with no shared state. On Hyperliquid, the CLOB is a first-class primitive that on-chain code can reference directly.

The practical limit right now is that most of this composability requires custom contract development. Tooling for building CLOB-aware strategies on HyperEVM is still early. But the architecture supports it, and protocols like Reactive Network are building the automation layer that makes event-driven strategies viable without off-chain infrastructure.

What HyperEVM does NOT change for perp traders

HyperCore perp trading is gasless and non-EVM. That doesn't change because HyperEVM exists. When you submit a perpetual futures order on Hyperliquid, it goes through HyperCore's matching engine - not through HyperEVM. No gas cost. No Solidity execution in the order path.

HyperEVM adds programmability to the ecosystem. It does not add gas costs or EVM overhead to perp trading. If you're a perp trader who doesn't interact with DeFi protocols on HyperEVM, its existence has no direct effect on your order execution or margin accounting.

What changes over time is the range of strategies available. Automated collateral management, yield-bearing margin, on-chain hedging - these become possible when HyperEVM and HyperCore can communicate. But the core perp trading experience runs on HyperCore and stays there.

Real risks you should know

HyperEVM is EVM-compatible. Every category of smart contract risk that exists on Ethereum mainnet exists here too.

• Solidity contract bugs in lending protocols, vaults, or CDP systems can result in loss of funds deposited into those contracts. The separation from HyperCore means these bugs don't affect the perp engine - but they absolutely affect your HyperEVM positions.
• Oracle manipulation is a live risk for any lending or CDP protocol relying on price feeds. A manipulated oracle can trigger incorrect liquidations or prevent liquidations from firing when they should.
• Dual-block gas limits mean complex transactions may not fit in a small block and will wait for a large block. Time-sensitive strategies that depend on fast execution need to account for this.
• Validator concentration risk applies to both HyperCore and HyperEVM because they share HyperBFT consensus. This is a known property of the system, not a hidden risk.
• Public RPC rate limits (100 req/min since August 2025) create a real constraint for any strategy that queries HyperEVM state frequently. Plan for private RPC access if you're building anything beyond manual interaction.

None of these are reasons to avoid HyperEVM entirely. They are reasons to size positions in HyperEVM protocols carefully and to audit contracts before deploying significant capital.

Where Stacked Markets fits

HyperEVM is the programmability layer. HyperCore is the financial engine. The gap that remains is a professional trading interface that gives you full control over how you interact with HyperCore's perp markets.

Stacked Markets is a non-custodial trading terminal built on top of Hyperliquid's on-chain order book. It holds no funds and no keys. You sign every order with your own wallet. Orders route directly to Hyperliquid's CLOB.

The terminal adds what Hyperliquid's native UI doesn't provide: configurable leverage caps, notional position limits, circuit breakers for rapid order bursts, and IOC limit orders with explicit slippage bounds. The worst-case fill price is shown before the wallet signing prompt appears. Every order is verifiable on-chain.

The HyperEVM ecosystem gives useful context for where Hyperliquid is heading as a platform. The perp trading itself runs on HyperCore - and the terminal for that is at Stacked Markets.

---

Trade Hyperliquid perps with professional risk controls and no custody. Stacked Markets holds no funds and no keys.

Start at Stacked Markets ->

FAQs

What is HyperEVM in simple terms?

HyperEVM is a general-purpose smart contract execution environment running on the same Hyperliquid L1 as the perp and spot trading engine (HyperCore). It supports standard Solidity contracts and EVM-compatible tooling. It is not a separate chain - it shares Hyperliquid's validator set and consensus mechanism.

When did HyperEVM launch?

HyperEVM launched on mainnet on 18 February 2025. The token linking standard connecting HyperCore and HyperEVM rolled out in March 2025.

Does HyperEVM affect perp trading on Hyperliquid?

Not directly. Perpetual futures on Hyperliquid run through HyperCore, which is gasless and non-EVM. HyperEVM adds programmability to the ecosystem but does not change how perp orders are matched, settled, or margined.

What is HYPE used for on HyperEVM?

HYPE is the native gas token on HyperEVM. Every transaction pays gas in HYPE. Base fees are burned following an EIP-1559-style model, creating deflationary pressure on HYPE supply proportional to HyperEVM usage.

Can smart contracts on HyperEVM interact with Hyperliquid's order book?

Yes. Because HyperCore and HyperEVM share the same L1 and communicate through system-level primitives, contracts on HyperEVM can read HyperCore state and trigger collateral movements between the two layers. That's the foundation for on-chain strategies that span both environments.

What are the main risks of using DeFi protocols on HyperEVM?

Smart contract bugs, oracle manipulation, and liquidation edge cases are all live risks in HyperEVM protocols. These risks are contained within HyperEVM and do not affect HyperCore's perp engine, but they can result in loss of funds deposited into HyperEVM contracts. Validator concentration risk applies to both layers because they share HyperBFT consensus.

What is the difference between HyperCore and HyperEVM?

HyperCore is the purpose-built financial engine handling perpetual futures, spot markets, the CLOB, margin, funding rates, and liquidations. It is gasless and non-EVM. HyperEVM is a general-purpose EVM execution environment on the same L1, designed for smart contracts, DeFi protocols, and programmable strategies. They share consensus but maintain separate state and execution contexts.