Most newcomers meet Hyperliquid through a trading screen: an order book, some candles, a button that says long or short. That is a reasonable first impression, but it can leave a builder confused about what the network actually is. Hyperliquid is best understood not as one system with one API, but as two execution surfaces sharing a chain identity — HyperCore, which holds native trading and market state, and HyperEVM, which runs smart contracts with an Ethereum-compatible interface. Once you see that split, the connectivity questions answer themselves much faster.
Where the trading state lives
HyperCore is the part of Hyperliquid designed around markets. It tracks order books, mid prices, candles, user orders, fills, and portfolio-style account data. It is not queried with Ethereum JSON-RPC methods. Instead, it exposes an Info API where you post a request describing the type of data you want. A typical call asks for the level-2 order book of a given coin, while other query types return open orders, fills over a time window, historical orders, or candlestick snapshots.
This is the key mental shift for a beginner: on HyperCore, you are not reading contract storage. You are asking the network about market state that the chain maintains natively. That state includes things like staking delegations and vault details as well, so the Info API is broader than a pure price feed. If your application is a trading dashboard, a position monitor, or an analytics job, most of your reading happens here.
Where the contracts live
HyperEVM is the contract side. It speaks Ethereum JSON-RPC, which means the methods you already know from Ethereum work the same way in spirit: you ask for the latest block number, read logs, query contract state, or send transactions. The chain ID is 999, a useful detail to keep straight when configuring a wallet or a client library, because the wrong chain ID can produce confusing failures before you have written a single line of business logic.
HyperEVM is where wallets, DeFi protocols, and general dApps belong. If you want to deploy a contract, read an ABI-defined function, or listen for events, that is HyperEVM work. The two surfaces are not competitors; they are complementary. A trading tool might read order books from HyperCore and settlement logic from HyperEVM in the same user session.
Four patterns you will actually build
The first is the market reader: a dashboard that pulls mid prices and order books to show current conditions. It touches HyperCore only and is mostly read-heavy.
The second is the account monitor: given a user address, fetch open orders and fills, then present history and exposure. This pattern benefits from understanding how much of the data is time-bounded, because requesting wide windows repeatedly is a quick way to burn through request budgets.
The third is the hybrid app: a contract on HyperEVM that represents positions or strategy, paired with HyperCore data displayed alongside it. Here your code maintains two clients with two request shapes, and the cleanest designs make that separation explicit rather than hiding it behind a single generic helper.
The fourth is the backend worker: a bot or indexer that polls on a schedule, caches aggressively, and writes results somewhere else. For this pattern, connection stability and rate limits matter more than any individual method.
RPC details that shape your first build
The first consideration is endpoint capacity. Public endpoints are convenient for learning, but they come with tight request limits — the reference setup for Hyperliquid shows a public rate limit of 5 requests per second, with authenticated access scaling much higher depending on plan. A polling loop that felt fine in testing can hit that ceiling quickly.
The second is transport. HTTPS is fine for request-response reads. WebSockets exist for HyperEVM and suit cases where you want a persistent stream rather than repeated polling. Not every workload needs one, but knowing both are available prevents premature architecture decisions.
The third is history. Archive support on HyperEVM means you can query past state, which matters for analytics and for debugging logic against older blocks. Check that your provider supports it before you design a backfill job.
The fourth is separation of concerns. Because HyperCore queries and HyperEVM calls use different paths and different request bodies, treat them as two integrations. A managed provider that serves both surfaces under one account, such as the Hyperliquid network RPC offering from OnFinality, lets you keep the split in your code while centralizing keys, limits, and monitoring. That is an operational convenience, not a shortcut around the two-model reality.
A note on latency expectations
Hyperliquid is positioned as a performance-focused network for onchain trading, and it is reasonable to care about round-trip time. What is not reasonable is assuming any specific number without measuring. Benchmark your own calls from the region your users are in, watch how your provider's limits interact with your polling cadence, and instrument failures rather than guessing. If you build a trading bot, a slow read can be worse than a failed one because it looks like stale truth.
Knowing when to stop reading
A good orientation gives you a map, not a manual. You now know that Hyperliquid maintains market state on HyperCore and contract state on HyperEVM, that the former is queried through an Info-style API and the latter through Ethereum JSON-RPC, and that your architecture should reflect that boundary. You also know the operational questions that come next: what rate limit you can live within, whether you need WebSockets or archive data, and how much of your workload is reading versus writing.
The honest caveat is that documentation and provider capabilities evolve. Verify method names and limits against current sources before you commit to a polling design, and keep your two clients cleanly separated so a change on one surface does not ripple through the whole app.
Useful Resources:
• Hyperliquid network RPC
Useful Resources: