Most newcomers hear "Hyperliquid" and assume it is one more exchange website with a token attached. It is not. Hyperliquid is a Layer 1 whose native purpose is onchain trading, and the thing that makes it unusual is that it does not run everything through a single virtual machine. Instead, the network is split into two execution layers with different jobs: HyperCore, where native trading and market state live, and HyperEVM, where smart contracts live.
That split is the single most important concept to absorb before you write a line of code. It explains why the same network needs two different API styles, why your wallet sees two kinds of state, and why the endpoint you pick depends entirely on what your app actually does.
What each layer is actually for
HyperCore is the trading engine. Order books, fills, open orders, positions, candles, and portfolio data all belong to this layer. You do not reach it with Ethereum-style JSON-RPC calls. You reach it through the Hyperliquid Info API, a request/response interface where you ask typed questions such as "give me the Level 2 book for BTC" or "give me this user's fills" and get structured market data back. The vocabulary here is trading vocabulary, not blockchain vocabulary.
HyperEVM is the contract layer. It speaks Ethereum JSON-RPC, has its own chain ID (999 on mainnet), and behaves like the EVM you already know: blocks, transactions, logs, contract state, and the usual method names. If you have written a Solidity contract or used a wallet with a custom network, this half of Hyperliquid will feel familiar immediately.
A useful mental model: HyperCore answers "what is the market doing and what does this account hold?" while HyperEVM answers "what does this contract say?" The two are related but queried differently, and confusing them is the most common early mistake.
Common application patterns
Once you see the two layers, the categories of applications basically write themselves.
Trading bots and execution tools sit closest to HyperCore. They read order books and mid prices, watch fills and order status, and react quickly. These apps care about request latency and about how many read calls they can make per second, because a market data loop is continuous by nature.
Dashboards and analytics tools blend both layers. A portfolio view might pull open orders and fills from HyperCore while also showing token balances or contract interactions from HyperEVM. If your dashboard shows both trading activity and DeFi positions, you are effectively speaking two protocols inside one app.
DeFi protocols, wallets, and dApps lean on HyperEVM. They deploy contracts, read state, and submit transactions using the same tooling they would use on any EVM chain. From the contract's point of view, Hyperliquid is just another EVM endpoint, which is exactly the point.
Market monitoring and alerting tools are a fourth pattern worth naming, because they often do not need to write anything at all. They poll HyperCore data, compare against thresholds, and notify. These are read-heavy, write-free workloads, and their infrastructure needs are different from a trading bot's.
The RPC considerations a builder should understand
This is where newcomers tend to get stuck, so let's be concrete about what actually differs when you connect to Hyperliquid infrastructure.
First, you are not choosing one endpoint. A serious Hyperliquid app may need a HyperEVM RPC URL for contract calls and a separate HyperCore Info path for market data. Treating them as one connection will force awkward workarounds later.
Second, request patterns matter more than raw peak speed. A trading dashboard that opens a WebSocket subscription has a very different profile from a bot that polls an order book every few hundred milliseconds. Public endpoints are usually rate limited, which is fine for experimenting but quickly becomes the ceiling for anything continuous. When you move to managed infrastructure, the question to ask is not just "how fast" but "what does sustained throughput look like for my specific call mix."
Third, consider archive access. If your app needs historical fills, past order states, or old contract logs, you need an endpoint that serves archival data rather than only the recent head of the chain. This is easy to overlook until a backtest or a historical chart quietly fails.
Fourth, think about observability. When a trading bot misbehaves at 3 a.m., the useful question is whether the problem was your logic or your data source. Having usage analytics and request-level visibility on the infrastructure side shortens that investigation enormously.
Fifth, expect to mix providers rather than pick one forever. The native Hyperliquid APIs are the natural home for trading operations, while managed infrastructure is often the better fit when you need scalable HyperEVM access, supported market data queries, and a dashboard that shows what your application is actually doing. Providers like OnFinality offer both HyperEVM JSON-RPC access and HyperCore Info queries under one account, alongside archive support and dedicated node options, which is convenient precisely because you avoid juggling credentials across two systems. You can explore the network page for details if you want to compare paths.
A reasonable starting sequence
If you are new to Hyperliquid, resist the urge to build a full trading system on day one. Start by reading a Level 2 order book and a simple contract call, side by side, so the two-layer model becomes concrete rather than abstract. Then add fill or order history and notice how historical queries behave differently from live ones. Only after that should you think about subscriptions, throughput, and failover.
Where this leaves you
Hyperliquid is best understood not as a chain with an exchange bolted on, but as two execution layers with deliberately different interfaces: one optimized for market state, one for contracts. That design is genuinely elegant, and it is also why "just point your RPC at it" is incomplete advice. Learn which layer answers which question, match your request pattern to the right endpoint, and plan for archive access and visibility before you need them. Get those basics right, and the rest of the stack stops feeling like a mystery.
Useful Resources:
• HyperEVM RPC URL
Useful Resources: