Switching from Dwellir? Keep your code.
We serve the Dwellir-compatible gateway (hyperliquid_l1_gateway.v2, with StreamBlocks, StreamFills, StreamOrderbookSnapshots, and the point-in-time GetBlock / GetFills / GetOrderBookSnapshot queries) on our endpoint. Change the target and the key; your client keeps working.
0+
markets, perps + spot + HIP-3
~$0.0B
traded daily, captured in real time
0.00B+
order events archived
One endpoint. That is the whole diff.
Your generated gateway stubs already speak our wire format. Point the channel at stream.hyperliquidrpc.com:443 and pass your key in x-api-key metadata; streams and point-in-time queries behave as before.
- All hyperliquid_l1_gateway.v2 methods are served: StreamBlocks, StreamFills, StreamOrderbookSnapshots, plus GetBlock, GetFills, and GetOrderBookSnapshot.
- Auth is an x-api-key entry in gRPC metadata; check your current header name when you swap keys.
- Set max-receive message size to 256 MB or more before requesting full order-book snapshots.
- The Dwellir-compatible gateway is included on both plans; point your existing client at it from day one.
What changes, beyond the endpoint.
Cells reflect a typical Hyperliquid RPC provider; verify against your current plan. Partial marks are deliberate; precision beats smugness.
| Feature | HyperliquidRPC | Dwellir |
|---|---|---|
| Real-time | ||
| Real-time gRPC streams | ||
| Wallet-level attribution on every fill | ◑ | |
| Exact decimal precision (no floats) | ◑ | |
| Server-side coin / wallet filtering | ◑ | |
| Compatibility | ||
| Works with QuickNode and Dwellir client stubs | Both | ◑ |
| gRPC reflection enabled | ◑ | |
| Historical | ||
| Historical dataset | Full archive | ◑ |
| Derived datasets (OHLCV, PnL, liquidations) | — | |
| Same schema live and historical | — | |
| Platform | ||
| HyperEVM JSON-RPC | ||
| Setup time | Minutes (API key) | Minutes |
Real-time gRPC streams
Wallet-level attribution on every fill
Exact decimal precision (no floats)
Server-side coin / wallet filtering
Works with QuickNode and Dwellir client stubs
gRPC reflection enabled
Historical dataset
Derived datasets (OHLCV, PnL, liquidations)
Same schema live and historical
HyperEVM JSON-RPC
Setup time
◑ = partial or provider-dependent. We keep this table honest: if a cell is out of date, tell us and we will correct it.
Same gateway methods, more platform around them.
The gateway you already integrate is one of three proto packages on our endpoint. The rest of the platform comes with it.
Full wallet attribution
Fills carry the trader's address, realized PnL, fees, maker/taker role, and position context: the raw material for copy-trading and wallet intelligence.
Exact decimal precision
Prices, sizes, PnL, and fees are byte-exact decimal strings, never floats. Backtests and accounting reconcile to the chain.
The complete historical archive
1.65B+ order events and 1B+ book updates archived in the same schema as the live feed. Query it, export it, or backtest on it.
Both wire formats, one endpoint
The Dwellir-compatible gateway and the QuickNode-compatible hyperliquid.* package run side by side. Migrating to us does not lock you into us.
Richer native streams
Beyond the gateway: full L4 order book, raw book diffs, order lifecycle, TWAP progress, and funding/liquidation events, with server-side coin and wallet filtering.
Derived datasets
OHLCV candles, wallet PnL, liquidation history, and funding-rate series, built from the full tape rather than samples.
Run us side-by-side before you switch.
Keep Dwellir in production and point a duplicate client at our endpoint. The gateway methods are on both plans, and Pro bills month-to-month so there is no lock-in during the evaluation.
Keep Dwellir running
Change nothing in production. Your existing gateway subscription is the control group.
Point a duplicate client at our gateway
All hyperliquid_l1_gateway.v2 methods are live on both plans. Check precision, attribution, and continuity against what you receive today.
Diff the feeds, then decide
Run your real client against it for a few days of trading, diff the two feeds, and switch when the data says so.
The full migration guide
Endpoint swap, auth metadata, gateway method coverage, message-size limits, and reconnect semantics, documented step by step.
The questions migrations actually raise.
Mechanics, gotchas, and tier gates, answered plainly. Anything missing lives in the migration guide.
No. We serve the hyperliquid_l1_gateway.v2 package your Dwellir client was generated against. If you prefer fresh stubs, reflection is enabled; generate directly from the endpoint or from our published .proto files.
Yes: GetBlock, GetFills, and GetOrderBookSnapshot work alongside the streaming methods StreamBlocks, StreamFills, and StreamOrderbookSnapshots.
Both. Every gateway method ships on Pro and Ultra alike; the plans differ on throughput, replay, and archive depth, not stream coverage.
Two values: the channel target becomes stream.hyperliquidrpc.com:443, and your API key moves into x-api-key gRPC metadata. Method signatures and response decoding are unchanged.
The wire format is identical; the operational envelope is documented rather than assumed. Set a ≥256 MB max-receive size for snapshots, reconnect with backoff, and read our DATA_LOSS semantics before going live. The migration guide lists every gotcha we know about.
Change one endpoint. Keep everything else.
Point your existing client at the gateway in minutes and run it side-by-side. Pro bills month-to-month: cancel anytime if the data does not fit.