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 subscription cap

The GoldRush Hyperliquid WebSocket API has no per-IP, per-key, or per-connection subscription cap. The 1000-subscription-per-IP limit on the public Hyperliquid WebSocket does not apply. You can:
  • Open as many concurrent subscriptions as your client supports.
  • Multiplex hundreds of l2Book subscriptions on a single connection.
  • Track every active wallet, market, and asset from one process.

​
Wildcard subscriptions

Filter parameters that the public Hyperliquid WebSocket requires are optional on GoldRush. Omit them to stream the entire channel on one subscription instead of fanning out one subscription per asset.
ChannelPublic HyperliquidGoldRush
l2Bookcoin required - one subscription per assetcoin optional - omit it to stream the full L2 order book across every asset on a single subscription
So a single connection can stream Hyperliquid’s full live book state without any client-side fan-out logic.

​
How streaming works

Messages are pushed directly from a live Hyperliquid ingestion pipeline - no polling, no cache delay. Latency from upstream Hyperliquid event to your client is dominated by network round-trip from our Tokyo nodes.
ChannelPush trigger
l2BookEvery L2 update on the subscribed coin (or every coin, if wildcard).

​
Connection management

You’re not rate-limited, but a few client-side defaults are worth tuning.
BehaviorRecommended client setting
ReconnectOn unexpected close, reconnect with exponential backoff capped at ~30 seconds. Re-send your subscription messages after the new socket opens.
HeartbeatSend an application-level ping every 30 seconds. The server replies with pong. Most WebSocket libraries handle this automatically; verify yours does.
Max message sizeL2 book snapshots for wildcard subscriptions can exceed 1 MB. Raise your client’s maxPayload (Node ws library) or max_size (Python websockets) if you’re receiving truncated messages.
BackpressureIf your handler can’t keep up with incoming messages, your client buffer will fill. Drain to a queue or downstream consumer; don’t block the read loop on application work.

​
Reconnect sketch

import WebSocket from "ws";

function connect() {
  const ws = new WebSocket(
    `wss://hypercore.goldrushdata.com/ws?key=${process.env.GOLDRUSH_API_KEY}`,
    { maxPayload: 8 * 1024 * 1024 },
  );

  ws.on("open", () => {
    ws.send(JSON.stringify({
      method: "subscribe",
      subscription: { type: "l2Book" }, // wildcard - all assets
    }));
  });

  ws.on("close", () => setTimeout(connect, Math.min(30_000, backoff *= 2)));
  ws.on("error", () => ws.close());
  ws.on("message", handle);
}

let backoff = 1_000;
connect();

​
Watch out for client-side limits

GoldRush has no caps, but the rest of your stack might:
  • OS file descriptor limits - if you’re opening many connections in parallel, raise ulimit -n.
  • Reverse proxy idle timeouts - if you’re terminating WS through nginx, HAProxy, or a cloud load balancer, set the idle timeout above your heartbeat interval (typically 60 seconds minimum).
  • Browser concurrency - browsers limit WebSocket connections per origin; one connection multiplexing many subscriptions is always preferable to many connections.

​
Network and TLS

  • HTTP/1.1 Upgrade to WSS is supported (standard WebSocket handshake).
  • TLS 1.2+ required.
  • Compression (permessage-deflate) is negotiated when offered by the client.

​
Need higher guarantees?

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