Hyperliquid EVM: What It Is and How to Connect to It

What Hyperliquid EVM actually is

Hyperliquid is a purpose-built blockchain whose execution state includes two surfaces: HyperCore, which handles the order book, trades, and liquidations, and HyperEVM, the EVM-compatible execution layer. Both are secured by HyperBFT consensus, so HyperEVM is not a separate chain bridged into Hyperliquid; it is part of the same execution environment.

For developers, that means HyperEVM behaves like an EVM chain for contract deployment and JSON-RPC calls, but it inherits Hyperliquid-specific rules. HYPE is the native gas token, and the EVM uses the Cancun hardfork without blobs. EIP-1559 is enabled, and unlike most EVM chains, priority fees are also burned because HyperBFT handles ordering.

The practical consequence is that standard EVM tooling mostly works, but you should verify fee behavior, block production, and method support against the network rather than assuming Ethereum mainnet defaults.

• HyperEVM is the EVM execution layer inside Hyperliquid, not a standalone chain.
• HyperCore and HyperEVM share HyperBFT consensus and the HYPE token.
• All EVM interaction happens through JSON-RPC, including wallet network setup.

Chain settings at a glance

Most connection problems come from mixing mainnet and testnet values or assuming the public endpoint supports features it does not. Confirm the following before debugging application code.

The values below reflect Hyperliquid's published developer documentation. Always re-check the official docs before shipping, because chain parameters can change.

How to connect a wallet or dApp

Adding HyperEVM to a wallet is the same flow as any EVM network: supply the RPC URL, chain ID, and currency symbol. The snippet below shows a typical wallet_addEthereumChain request. Replace the RPC URL with your provider's endpoint if you are not using the public one.

If you are building a dApp, configure your library with the same chain ID and RPC URL. A common mistake is pointing the wallet at mainnet while the app's provider targets testnet, which produces confusing signature and nonce errors.

• Wallet network name: HyperEVM (or Hyperliquid EVM).
• Currency symbol: HYPE.
• Block explorer: use the official HyperEVM explorer for transaction lookups.
• Keep mainnet and testnet configurations in separate environment variables.

Quick recommendation: public endpoint or managed RPC?

The public Hyperliquid endpoint is fine for exploration, wallet setup, and low-volume scripts. It is not designed for production traffic, and it does not offer WebSocket JSON-RPC, which rules out subscription-based designs on that endpoint alone.

Move to a managed RPC provider when you need predictable rate limits, archive access for historical queries, failover across regions, or WebSocket support. OnFinality offers RPC API access and dedicated nodes across supported networks; confirm current Hyperliquid availability on the supported RPC networks page before committing an architecture.

If you are still comparing providers, the RPC provider selection guide covers the evaluation criteria in more depth.

HyperEVM vs HyperCore: what changes for your code

HyperCore is the trading engine: order placement, cancellation, and liquidation happen there. HyperEVM is the general-purpose EVM surface for contracts and standard JSON-RPC calls. They share consensus and the HYPE token, but they are not the same API surface.

If your application needs order-book data or trading actions, you are likely working with HyperCore APIs rather than EVM JSON-RPC. If you are deploying Solidity contracts, reading balances, or indexing EVM events, you are on the HyperEVM side. Mixing the two mental models is a common source of confusion when developers first integrate.

Moving HYPE between the two surfaces uses a native transfer to a designated address rather than a bridge contract. Check the official documentation for the current address and instructions before implementing transfers.

• HyperCore: order book, trades, liquidations.
• HyperEVM: EVM contracts, JSON-RPC, standard wallet flows.
• HYPE transfers between them use a native transfer mechanism, not a third-party bridge.

Failure modes to expect on HyperEVM

Most HyperEVM integration issues fall into a few categories. The table below maps symptoms to likely causes so you can debug faster.

If you are running against a managed provider, also check the provider's status page and request logs before changing application code.

Production readiness checklist

Before you route real traffic to HyperEVM, confirm the basics: correct chain ID per environment, a provider that supports the methods you call, a retry and backoff strategy, and a fallback endpoint. If your design depends on real-time events, verify WebSocket support explicitly rather than assuming it.

For teams that need isolated capacity or predictable throughput, dedicated nodes are an option; see dedicated nodes for how that model works. For most applications, a managed RPC API with clear limits is the simpler starting point.

• Separate mainnet and testnet configuration.
• Confirm archive and WebSocket support if your app needs them.
• Add retries with backoff and at least one fallback endpoint.
• Monitor error rates and latency from your own application, not just the provider dashboard.
• Review RPC pricing against expected request volume.

Frequently Asked Questions