Skip to main content

Documentation Index

Fetch the complete documentation index at: https://goldrush.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
No rate limits

The GoldRush Hyperliquid Info API has no per-IP, per-key, or per-address rate limits. The 1200 weight/min cap on the public Hyperliquid /info API does not apply. You can:
  • Poll any user-state endpoint as fast as your code wants.
  • Open as many concurrent connections as your client supports.
  • Pull state for thousands of wallets in tight loops.
For wallet-level real-time updates without polling at all, use the Streaming API walletTxs subscription instead - push-based, also no rate limits.

​
How caching works

Responses are served from a real-time cache that’s kept fresh by direct ingestion from Hyperliquid. The cache is transparent to your client code - same JSON in, same JSON out.
Cache layerTypical freshness
User-state types (clearinghouseState, spotClearinghouseState, frontendOpenOrders)Sub-second after each user event.
Market types (metaAndAssetCtxs)Sub-second on every mark-price tick.
You’re not rate-limited, but polling smartly saves your own bandwidth.
EndpointRecommended intervalNotes
metaAndAssetCtxs1 secondMark prices update on every tick - for sub-second freshness, use the Streaming API.
clearinghouseState1 second per user, OR push via walletTxsAccount state only changes on a user event; push is far more efficient than polling.
spotClearinghouseState5 secondsSpot balances change less frequently than perp positions.
frontendOpenOrders1 second per user, OR push via walletTxsSame as clearinghouseState.

​
Watch out for client-side limits

GoldRush has no rate limits, but the rest of your stack might:
  • Browser fetch concurrency - most browsers cap at ~6 concurrent requests per host. Use connection pooling on the server side or batch requests.
  • HTTP/2 stream limits - most clients allow 100+ concurrent streams per connection by default. Bump if you’re saturating.
  • OS file descriptor limits - if you’re opening thousands of connections, raise ulimit -n.
For multi-wallet fan-out, use the batchClearinghouseState and batchSpotClearinghouseState endpoints, which accept up to 50 wallets per call. For more than 50 wallets, issue multiple calls.

​
Network and TLS

  • HTTP/2 keep-alive is supported and recommended.
  • TLS 1.2+ required.
  • Accept-Encoding: gzip is honored. zstd support is on the roadmap.

​
Need higher guarantees?

Enterprise SLA, dedicated capacity, regional pinning, and on-prem options are all available. Email sales.