Summary
Hyperliquid's official documentation is the source of truth for the chain's architecture, API surfaces, and SDKs. It covers HyperCore (the fully onchain order book layer) and HyperEVM (the Ethereum-compatible smart contract layer), which share one consensus and one state. If you are building on Hyperliquid, you will likely need to read the docs for API semantics and then choose how to connect: public endpoints, a managed RPC provider, or your own node.
This page is a developer-oriented map of the Hyperliquid docs. It explains what each documentation area is for, how the API surfaces differ, and where RPC infrastructure fits into a working setup. It does not replace the official docs; it helps you decide what to read first and what to configure next.
OnFinality provides RPC API and dedicated node infrastructure for supported networks. If Hyperliquid is part of your stack, check the supported networks page and RPC pricing to see what is available before you finalize your connection strategy.
Key Takeaways
- Hyperliquid docs are split by layer: HyperCore for exchange data and order flow, HyperEVM for EVM-compatible smart contracts.
- The official docs are the authority for API methods, signing, and SDK usage; RPC providers supply transport and node access, not protocol semantics.
- HyperEVM uses familiar Ethereum JSON-RPC tooling, while HyperCore exposes exchange-specific APIs and streams.
- Choose your connection path early: public endpoint for exploration, managed RPC for production convenience, or dedicated node for isolation and control.
- Test with read-only calls first, then add signing and order submission once transport and chain settings are confirmed.
- Keep the official docs and your provider's network page side by side; they answer different questions.
What the Hyperliquid docs actually cover
The official Hyperliquid documentation is organized around the chain's two execution environments. HyperCore contains the fully onchain perpetual futures and spot order books, where orders, cancels, trades, and liquidations are processed with one-block finality. HyperEVM is the general-purpose smart contract layer that brings Ethereum-compatible tooling to the same unified state.
That split matters when you read the docs. A question about order books, positions, or exchange actions belongs in the HyperCore and API sections. A question about Solidity contracts, ERC-20 balances, or standard JSON-RPC calls belongs in the HyperEVM section. The docs also link to SDKs, builder tools, and support resources, which are useful once you move from reading to implementation.
- About and technical overview: consensus, state model, and how HyperCore and HyperEVM relate.
- API documentation: exchange actions, info queries, and streaming interfaces.
- HyperEVM section: EVM compatibility details and contract deployment context.
- SDKs and builder tools: language-specific clients and integration helpers.
- Support and community links: where to ask questions when the docs are ambiguous.
Decision guide: which connection path fits your project
Before you write integration code, decide how your application will reach Hyperliquid. The docs describe the protocol; they do not choose your infrastructure. That decision depends on workload, how much control you need, and whether you want to operate nodes yourself.
Use this table as a starting point. It is not a ranking of providers; it is a way to match your requirement to a connection model.
| Criterion | What to check | Why it matters |
|---|---|---|
| Exploration and prototyping | Public or shared RPC endpoint, basic read calls, no signing yet | Lets you confirm chain settings and API behavior before committing to infrastructure. |
| Production application with variable traffic | Managed RPC API with documented limits, monitoring, and support path | Reduces operational burden while keeping a clear escalation route when something breaks. |
| Sustained or latency-sensitive workloads | Dedicated node or private endpoint with predictable resources | Isolates your traffic from other users and gives you more control over configuration. |
| Full control and custom peering | Self-hosted node, hardware requirements, upgrade cadence | Maximum control, but you own uptime, monitoring, and protocol upgrades. |
HyperCore API vs HyperEVM JSON-RPC: what changes in your code
HyperEVM behaves like an Ethereum-compatible chain from a tooling perspective. You can use standard JSON-RPC methods such as eth_chainId, eth_blockNumber, and eth_getBalance with familiar libraries. That means your existing Ethereum development habits mostly carry over for contract reads and writes.
HyperCore is different. Exchange actions, order status, and market data are exposed through Hyperliquid-specific APIs and streams rather than generic EVM methods. The docs describe these interfaces in detail, including signing and preflight checks. If your application touches both layers, expect two integration styles in the same codebase: EVM JSON-RPC for contracts and HyperCore APIs for exchange data.
- Use EVM JSON-RPC for contract state, logs, and standard account queries on HyperEVM.
- Use HyperCore APIs for orders, positions, fills, and order book data.
- Check the docs for the exact request and response shapes; do not assume EVM method names apply to exchange actions.
- Keep signing logic separate from transport configuration so you can switch endpoints without rewriting business logic.
Chain settings and endpoint configuration
For HyperEVM, you will configure a chain ID, RPC URL, and typically a block explorer URL in your wallet or library. The official docs and the network's published chain information are the authority for these values. Do not copy chain IDs from third-party blog posts without verifying them against the official source.
For RPC access through OnFinality, check the supported networks page for current availability and the exact endpoint details. If Hyperliquid is listed, use the endpoint and chain settings provided there rather than guessing a URL. If it is not listed yet, you can still follow the official docs for protocol details and plan your infrastructure separately.
| Criterion | What to check | Why it matters |
|---|---|---|
| Chain ID | Official Hyperliquid docs or OnFinality network page | Wrong chain ID causes wallet and library connection failures. |
| RPC URL | Provider dashboard or OnFinality supported networks page | The endpoint determines transport, authentication, and rate limits. |
| Explorer URL | Official docs | Needed for transaction debugging and user-facing links. |
| Transport | HTTP for request/response, WebSocket for subscriptions, gRPC where documented | Not every workload fits every transport; streaming needs differ from batch reads. |
A minimal read-only check before you build further
Once you have an endpoint, confirm basic connectivity before adding signing or order logic. A simple JSON-RPC call verifies that your URL, headers, and chain configuration are correct. The example below uses a placeholder endpoint; replace it with the URL from your provider or the OnFinality supported networks page.
If the call returns a chain ID, your transport is working. If it fails, check the URL, authentication headers, and whether the endpoint expects a different path. This step saves time later because it separates transport problems from application logic problems.
curl -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'- Confirm the returned chain ID matches the official value.
- Then try eth_blockNumber to verify the node is synced and responding.
- Only after these pass should you add wallet signing or exchange API calls.
Common failure modes when following Hyperliquid docs
Most integration problems come from mixing layers or skipping verification. A developer reads a HyperEVM example, then tries to use the same method for HyperCore order data, or copies a chain ID from an outdated tutorial. The docs are detailed, but they assume you know which layer you are working on.
Another common issue is treating an RPC provider's documentation as a substitute for protocol documentation. Providers explain endpoints, limits, and transport; they do not redefine how Hyperliquid orders are signed or how HyperCore state is structured. Keep both references open and use each for its intended purpose.
| Criterion | What to check | Why it matters |
|---|---|---|
| Method not found | Whether the method belongs to HyperEVM JSON-RPC or HyperCore API | Exchange actions are not EVM methods; using the wrong surface returns errors. |
| Connection refused or 401 | Endpoint URL, API key, and required headers | Transport and authentication failures look similar but have different fixes. |
| Chain ID mismatch | Official docs vs wallet or library configuration | A wrong chain ID prevents transactions from being accepted. |
| Stale data | Whether you are polling or subscribing, and whether the node is synced | Order books and positions change quickly; stale reads lead to bad decisions. |
Where OnFinality fits alongside the official docs
OnFinality provides RPC API and dedicated node infrastructure for supported networks. For Hyperliquid, that means you can use OnFinality as your transport layer while relying on the official docs for protocol behavior, signing, and API semantics. This separation keeps your integration maintainable: if you change providers, your application logic stays the same.
Before you commit, review RPC pricing and the supported networks list to confirm availability and plan capacity. If you need isolated resources or a private endpoint, dedicated nodes are an option. For a broader framework on evaluating providers, see the RPC provider selection guide.
- Use the official docs for API methods, signing, and chain architecture.
- Use OnFinality for endpoint access, transport, and node operations where supported.
- Check supported networks and pricing before finalizing your architecture.
- Keep a fallback connection path in mind for production resilience.
Frequently Asked Questions
Are the Hyperliquid docs the same as RPC provider documentation?
No. The official Hyperliquid docs describe the protocol, API surfaces, and SDKs. RPC provider documentation describes endpoints, authentication, limits, and transport. You typically need both: one for how the chain works, one for how you connect to it.
Do I need a separate endpoint for HyperCore and HyperEVM?
That depends on your provider and setup. HyperCore and HyperEVM share one state and consensus, but they expose different APIs. Some providers offer a single endpoint that reaches both surfaces; others separate them. Check the provider's documentation for the exact configuration.
Can I use standard Ethereum libraries with HyperEVM?
HyperEVM is designed to be Ethereum-compatible, so familiar JSON-RPC methods and libraries generally apply for contract reads and writes. Always verify method support and chain settings against the official docs and your provider's network page.
Where should I start if I only want to read market data?
Start with the HyperCore API and streaming sections of the official docs. For contract-level data on HyperEVM, use standard JSON-RPC reads. Confirm your endpoint and transport before building dashboards or alerts.
Does OnFinality support Hyperliquid RPC?
Check the OnFinality supported networks page for current availability. If Hyperliquid is listed, you can use the endpoint details provided there. If not, you can still use the official docs for protocol guidance and plan infrastructure separately.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
