How to get a Hyperliquid RPC endpoint for institutional trading (2026 guide)

TL;DR

The public Hyperliquid endpoint will never pass an institutional review — not because it is slow, but because it carries no SOC 2 attestation, no SLA, no access controls, and no audit trail, which makes it unusable for any desk, custodian, or fund that has to answer to a risk committee. On top of that compliance gap sits a structural one: Hyperliquid splits execution across HyperCore’s order-book API and the HyperEVM JSON-RPC layer, so a single endpoint never covers an institutional stack. This guide shows how to stand up compliant, SLA-backed, dedicated Hyperliquid infrastructure across both layers.

What is a Hyperliquid RPC endpoint

A Hyperliquid RPC endpoint is the access point into two execution layers that share one consensus, and for an institution the distinction matters because the two layers carry different data with different reporting obligations. HyperCore is a Rust-based on-chain order book that settles perps, spot, margin, and liquidations with roughly 0.2-second finality, and it speaks a REST/WebSocket model (/info for reads, /exchange for trading actions) rather than Ethereum JSON-RPC. HyperEVM is the EVM-compatible layer on chain ID 999, where Solidity contracts run against standard eth_* JSON-RPC and can read HyperCore state through precompiles. An institutional integration almost always touches both: positions and fills live on HyperCore, while vaults and on-chain strategy logic live on HyperEVM.

For an institutional trading on Hyperliquid, the endpoint is what every downstream system depends on:

• Reading account margin, open positions, and balances from HyperCore /info for risk and exposure dashboards
• Pulling historical fills and funding-rate history for books-and-records, PnL attribution, and client statements
• Streaming live fills and order updates over the HyperCore WebSocket for real-time risk monitoring
• Calling eth_call and eth_getLogs on HyperEVM to reconcile on-chain vault state with internal ledgers
• Submitting orders, cancels, and leverage changes through /exchange (validator-gated) for desks that trade directly

You can review the full request and subscription model in the Hyperliquid HyperEVM developer documentation.

For an institution, endpoint quality is not a latency line item — it is a control. A reporting pipeline that silently drops requests against a throttled public node produces statements that do not reconcile, and a reconciliation break is a finding, not an inconvenience.

How Hyperliquid RPC differs from Ethereum RPC

Hyperliquid is EVM-compatible on HyperEVM, so the JSON-RPC surface will feel familiar to any team that has integrated Ethereum — but the differences that matter for institutional operations are exactly the ones that break a naive port of an Ethereum reporting stack.

Property	Ethereum	Hyperliquid
Block model	Single ~12s blocks	HyperEVM dual blocks: fast small blocks (~1s) + infrequent big blocks (~1min) for gas-heavy deploys
Finality	~13 minutes (2 epochs)	Sub-second via HyperBFT (~0.2s on HyperCore)
Gas token	ETH	HYPE
Consensus	Gasper PoS	HyperBFT
Order book / settlement	Off-chain or AMM contracts	Native on-chain order book on HyperCore, outside the EVM
Source of record for trades	One JSON-RPC node	Split: fills on HyperCore, on-chain positions on HyperEVM

The decisive difference for an institution is that there is no single source of record. On Ethereum, one archive node answers every reporting query. On Hyperliquid, your trade and fill history comes from HyperCore’s REST/WebSocket API while your on-chain contract state comes from HyperEVM JSON-RPC — and the two must be stitched together at a consistent point in time before any statement reconciles. A provider that exposes only HyperEVM covers half of what a compliance pipeline needs. That fragmentation, combined with the validator-gated /exchange path, is why provider selection here is a governance decision, not just a performance one.

Hyperliquid RPC endpoint options

Public vs private Hyperliquid RPC endpoints

On most chains the public-versus-private decision is about reliability. For institutional trading on Hyperliquid, it is about whether the infrastructure is admissible at all: the public endpoint offers no contractual uptime guarantee, no access governance, and no compliance attestation, which means it cannot sit underneath a regulated reporting or trading workflow regardless of how well it performs on a quiet day.

Official public endpoints:

• HyperEVM mainnet: https://rpc.hyperliquid.xyz/evm
• HyperEVM testnet: https://rpc.hyperliquid-testnet.xyz/evm
• HyperCore mainnet API: https://api.hyperliquid.xyz/info
• HyperCore testnet API: https://api.hyperliquid-testnet.xyz/info

⚠️ The public HyperEVM JSON-RPC endpoint is limited to roughly 100 requests per minute per IP, and HyperCore REST reads share a 1,200 weight-per-minute IP budget. An institutional risk dashboard polling positions across multiple accounts, or a nightly reconciliation job backfilling fills, will exhaust both during normal operation — and for exactly this reason the Hyperliquid API documentation directs production integrations toward dedicated infrastructure rather than the shared endpoint.

Feature	Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
HyperEVM rate limit	~100 req/min per IP	No aggressive throttling
Compliance posture	None	SOC 2 attestation, custom SLAs
Access governance	None	SSO/MFA, role-based permissions
Archive access	Not available	Available

The institutional case is straightforward: a Hyperliquid integration that has to survive an audit needs infrastructure that comes with a SOC 2 Type II and ISO 27001 attestation and a contractual SLA behind it, which is the entire premise of Chainstack for Enterprise. A public endpoint provides neither.

Full node vs archive Hyperliquid node

For an institution, the full-versus-archive question maps directly onto the line between live operations and the historical record: real-time risk runs on current state, while reporting, reconciliation, and any regulatory request reach back into history.

Full node access	Archive node access
Live margin and positions for real-time risk monitoring	Historical fills and trade replay for books-and-records
Current HyperEVM vault state for treasury dashboards	Funding-rate history for PnL attribution and client statements
Spot balances and open orders for exposure checks	Historical eth_getLogs backfills for on-chain ledger reconciliation

Archive nodes and WebSockets are now live on Hyperliquid HyperEVM mainnet on Chainstack, so a compliance or finance team can reconstruct complete fill and funding history and reconcile it against on-chain vault movements from the same managed archive node infrastructure — rather than relying on best-effort third-party data dumps that carry no provenance guarantee. For any institution whose obligations include producing a defensible historical record, archive access is not optional.

HTTPS vs WebSockets

For an institutional deployment the transport decision splits along workload: stateless reporting and reconciliation queries fit a request/response model, while real-time risk and exposure monitoring need a persistent feed so a margin breach surfaces the instant it happens rather than on the next poll.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Reconciliation queries, account snapshots, contract reads, order submission via /exchange	Live fills, position updates, and HyperEVM event streams for real-time risk
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

Note that the public HyperEVM JSON-RPC endpoint offers no WebSocket — real-time data on the public side comes only from the HyperCore WebSocket, capped at 100 connections, 1,000 subscriptions, and 2,000 messages per minute per IP. Managed Global Nodes add WebSocket support on HyperEVM itself, so a risk system can subscribe to vault and contract events without polling against the public ceiling.

How to get a private Hyperliquid RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account).
2. Create a new project
3. Select Hyperliquid as your blockchain protocol
4. Choose network: Hyperliquid Mainnet or Hyperliquid Testnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

You can deploy a private Hyperliquid RPC node on Chainstack across both HyperEVM and HyperCore, and the same console exposes the /evm path (system transactions stripped) and the /nanoreth path (system transactions included) on every node — the latter matters when reconciliation requires seeing every cross-layer transfer.

Here is a minimal connection using the Hyperliquid Python SDK, the primary SDK for reading Hyperliquid state, to pull an account snapshot through your Chainstack endpoint:

from hyperliquid.info import Info
from hyperliquid.utils import constants

# Point Info at your Chainstack HyperCore endpoint
# skip_ws=True for a one-shot REST query; set False to open the live feed
info = Info("YOUR_CHAINSTACK_ENDPOINT", skip_ws=True)

# Pull a user's perp positions and margin summary for a risk/reporting view
user_state = info.user_state("0xACCOUNT_ADDRESS")
print(user_state)

📖 For the full integration guide, see the Chainstack Hyperliquid tooling documentation.

You can also access Chainstack Hyperliquid RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Using Chainlist

HyperEVM (chain ID 999) is listed on Chainlist, so a team can add the network to a wallet like MetaMask from there in one click. Chainlist is a network registry, not an infrastructure provider, though — any public RPC URL it lists carries the same 100 req/min ceiling and the same absent compliance posture, so it should be replaced with a managed endpoint before it sits under any institutional workflow. Chainlist also does not surface HyperCore at all, since the order book is non-EVM.

Chainstack pricing for Hyperliquid RPC

Chainstack bills on request units with a flat one-request-per-RU model, which makes a reporting-heavy institutional workload far easier to forecast and budget than compute-unit pricing that multiplies cost by method weight. See the full Chainstack pricing page for plan details and overage rates.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	$0	3,000,000	25	$20
Growth	$49	20,000,000	250	$15
Pro	$199	80,000,000	400	$12.50
Business	$499	200,000,000	600	$10
Enterprise	from $990	400,000,000+	Unlimited	$5

For institutional workloads, the Enterprise plan is where the controls that matter live: custom SLAs, SSO/MFA, role-based access, and the SOC 2 Type II and ISO 27001 posture an audit requires. For predictable, capped-cost reads, the Unlimited Node add-on provides flat RPS-based pricing with no request accounting, and Dedicated Nodes start from $0.50/hour plus storage for isolated, co-locatable infrastructure.

How to estimate monthly cost

1. Count the read calls per second your risk and reporting systems make against HyperCore /info and HyperEVM at steady state
2. Add WebSocket subscription load for live position and fill monitoring
3. Multiply by your active operating hours per month
4. Add HyperEVM contract reads for any on-chain vault or treasury reconciliation
5. Size for the reporting cycle, not the average: a nightly or month-end reconciliation job that backfills historical fills hits archive reads (billed at 2 RU each) in a concentrated burst — budget for that batch window separately, or it silently throttles exactly when statements are due

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• HyperCore reads and HyperEVM contract reads served by dedicated nodes with a contractual SLA, not the shared public endpoint
• Access governance in place: SSO/MFA and role-based permissions on the infrastructure console
• Archive access confirmed for books-and-records — historical fills, funding history, and eth_getLogs backfills
• /evm vs /nanoreth path behavior confirmed for whether reconciliation needs to see system transactions

Before committing to a provider, benchmark endpoint latency and consistency against alternatives with the Chainstack performance dashboard.

Troubleshooting common Hyperliquid RPC issues

Issue	How to fix
429 Too Many Requests on HyperEVM	You hit the ~100 req/min public cap; move to a managed endpoint with dedicated RPS
HyperCore WebSocket disconnects	Add reconnect + resubscribe logic, then backfill the gap with an /info snapshot so the risk view stays complete
Reconciliation breaks between HyperCore fills and HyperEVM state	Snapshot both layers against a consistent time/block reference; do not compare a live HyperCore read against a stale HyperEVM call
Missing system transactions or unexpected nonce during audit	Switch from the /evm path to the /nanoreth path, which includes system transactions for full cross-layer accounting
/exchange unavailable on a non-validator node	Order submission is validator-gated; route it to api.hyperliquid.xyz and keep your node for /info reads and reporting
Address-based throttle (1 req/10s) after quota exhaustion	Respect the per-address weight budget; batch reads and eliminate redundant /info polling in reporting jobs

Conclusion

The failure mode that catches institutional trading on Hyperliquid is not a crash — it is a reconciliation break discovered weeks later. A reporting pipeline pointed at the public endpoint quietly drops requests once it crosses 100 per minute, fills go unrecorded, and a client statement or regulatory filing no longer ties out to the on-chain record. Because the data spans two layers with no shared source of truth, the gap is hard to even locate, and on infrastructure with no SLA and no audit trail there is nothing to escalate to. That is the kind of finding that turns into a remediation project.

The pattern that works is to treat Hyperliquid infrastructure as a controlled system from day one. Run dedicated nodes with a contractual SLA for HyperCore reads and HyperEVM reconciliation, keep validator-gated /exchange order flow on its own path, enforce SSO/MFA and role-based access on the console, and insist on SOC 2 Type II and ISO 27001 attestation before anything sits under a regulated workflow. Do not build institutional reporting on a shared endpoint — the absent compliance posture is a hard blocker, not a detail to revisit later.

Start on the free Developer plan to wire up and validate the full HyperCore + HyperEVM split, then move to Dedicated Nodes and an Enterprise agreement when the workload goes into production.

FAQ

Is the public Hyperliquid endpoint enough for an institutional trading? No, and the reason is governance before performance. The public endpoint has no SLA, no access controls, and no SOC 2 Type II and ISO 27001 attestation, so it cannot legitimately sit underneath a regulated trading, custody, or reporting workflow even when it happens to be fast. Add the 100 req/min ceiling that a multi-account risk dashboard exhausts in seconds, and it is a development tool, not production infrastructure.

Does Chainstack Hyperliquid infrastructure carry SOC 2 Type II and ISO 27001? Yes. Chainstack achieved SOC 2 Type II and ISO 27001 certification, which evaluates controls over a sustained period rather than at a single point in time, covering security, availability, and confidentiality. For an institution, that attestation plus a contractual SLA is what makes managed Hyperliquid infrastructure admissible in an audit.

HyperCore or HyperEVM — which endpoint does an institution need for reporting? Almost always both. Fills, positions, margin, and funding live on HyperCore, so all trade and risk reporting reads go there. HyperEVM (chain ID 999) holds any on-chain vaults or strategy contracts, and reconciling those against internal ledgers requires eth_call and eth_getLogs on that layer. A complete statement stitches both layers at a consistent point in time.

Do I need an archive node for compliance and books-and-records? Yes, the moment your obligations reach into the past. Live risk runs on current state, but historical fills, funding-rate history, and eth_getLogs backfills for ledger reconciliation all require archive access. Since Chainstack now runs archive on HyperEVM mainnet, the historical record and live monitoring can come from the same provider with the same provenance.

How do institutions handle the validator-gated /exchange endpoint? Order submission through /exchange is served only by validator-backed infrastructure, so it routes to api.hyperliquid.xyz rather than a standard node. A well-architected institutional stack keeps that order-flow path separate from the dedicated node that serves high-volume /info reads, WebSocket risk feeds, and HyperEVM reconciliation — different paths, different controls.

Which SDK should an institution use to integrate Hyperliquid? The Hyperliquid Python SDK is the primary choice for reading account state, fills, and funding for risk and reporting systems, and it points at any HTTPS endpoint including a Chainstack node. TypeScript and Rust SDKs are also supported; the Chainstack tooling documentation covers connection setup for each.

Additional resources

• Mastering Hyperliquid — Chainstack developer guide to nodes, SDK setup, and cross-layer interaction
• Chainstack Hyperliquid tooling documentation — connection code for the Python, TypeScript, and Rust SDKs
• Understanding Hyperliquid infrastructure and RPC nodes — HyperCore vs HyperEVM, rate limits, and path behavior
• Hyperliquid official documentation — protocol overview, HyperCore and HyperEVM architecture
• More Hyperliquid tutorials and articles on the Chainstack Blog