Streams referenceQuickNode-compatible

Events

Funding payments, liquidations, deposits, withdrawals, and ledger updates.

The non-order event surface: per-user funding payments with the funding rate, liquidations with victim and mark price, deposits, withdrawals, and position updates. The live source behind the liquidation and funding datasets.

Method
hyperliquid.Streaming/StreamData (stream_type: EVENTS)
Endpoint
stream.hyperliquidrpc.com:443 · gRPC over TLS (HTTP/2)
Auth
API key in x-api-key metadata
Volume
Bursty: funding clusters at funding intervals across 63,000+ wallets; liquidations cluster with volatility.

When to use it

Everything that changes an account without being an order lands here: per-user funding payments with the rate applied, liquidations with victim and mark price, deposits, withdrawals, and position updates. It is the live source for risk monitors watching liquidation cascades, funding-strategy desks tracking what each wallet actually paid, and treasury tooling reconciling flows in and out.

Combine it with the trades stream for the complete picture of a wallet: fills explain position changes, events explain everything else.

Method

// stream.hyperliquidrpc.com:443 — gRPC over TLS (HTTP/2)// auth: API key in x-api-key metadata · server reflection enabledpackage hyperliquid; service Streaming {  // Bidirectional: send one subscription, then read updates.  // Subscribe with stream_type: EVENTS.  rpc StreamData (stream SubscribeRequest) returns (stream SubscribeUpdate);}

QuickNode-compatible StreamData with stream_type: EVENTS. Each update carries the block number and the event payload as JSON; the type field discriminates funding, liquidation, deposit, withdraw, and position updates.

Subscribe

# StreamData is bidirectional; grpcurl sends the subscription for you.grpcurl -H 'x-api-key: YOUR_KEY' \  -d '{"subscribe":{"stream_type":"EVENTS","filters":{"user":{"values":["0xe83b6f02a1d94c7785cb01f3aa620d94b17c08d5"]}}}}' \  stream.hyperliquidrpc.com:443 \  hyperliquid.Streaming/StreamData

The filters map also matches on type. Subscribe with "type": {"values": ["liquidation"]} for a pure liquidation feed with no client-side sorting.

Message fields

FieldTypeDescription
typestringfunding / liquidation / deposit / withdraw / position update.
userstringAffected wallet.
coinstringMarket symbol (funding, liquidation).
usdcstringUSDC amount of the event (signed for funding).Byte-exact decimal string.
funding_ratestringFunding rate applied (funding events).Byte-exact decimal string.
szistringSigned position size the payment applied to.Byte-exact decimal string.
liquidationobject?Liquidated size, price, and mark price (liquidation events).

Fields typed string that carry numbers are byte-exact decimal strings, verbatim from the node. Compare and store them as strings or arbitrary-precision decimals. Never parseFloat a price you intend to reconcile.

Server-side filters

  • coins[]
  • wallets[]
  • replay from a block height

Filters are applied on the server, so filtered-out messages never leave our edge. You only pay for what you subscribe to. Request shapes for every stream family are on Filtering; backfill semantics on Replay & backfill.

Semantics & gotchas

Pure event stream in block order. Funding arrives per user per funding interval; liquidations as they execute.

  • Funding arrives per user, per interval. At each funding interval you receive one event per wallet per market with an open position, so bursts across 63,000+ wallets are normal. Size buffers for the spike, not the average.
  • usdc is signed. Negative means the wallet paid (funding) or lost; positive means it received. Sum it as a signed decimal and a wallet's funding ledger falls out directly.
  • Liquidation detail rides on the event. Liquidation events carry the liquidated size, price, and mark price in the liquidation object; the corresponding forced fills also appear on the trades stream.
  • Volatility clusters liquidations. Quiet for hours, then hundreds in a minute. Alerting pipelines should debounce and aggregate rather than page per event.

Sample message

{  "block_height": 612409002,  "block_time": "2026-06-09T09:00:00.084Z",  "type": "funding",  "user": "0xe83b6f02a1d94c7785cb01f3aa620d94b17c08d5",  "coin": "BTC",  "usdc": "-14.302187",  "szi": "2.54000",  "funding_rate": "0.0000125"}

Bursty: funding clusters at funding intervals across 63,000+ wallets; liquidations cluster with volatility.

Recipes

A wallet's funding ledger

Filter by user, keep type == "funding", and accumulate usdc per coin. The funding_rate on each event lets you verify the payment against position size.

from collections import defaultdictfrom decimal import Decimal paid = defaultdict(Decimal) for update in stub.StreamData(iter([subscribe]), metadata=meta):    ev = json.loads(update.data.data)    if ev["type"] == "funding":        paid[ev["coin"]] += Decimal(ev["usdc"])

Platform-wide liquidation monitor

Subscribe with a type filter so only liquidations cross the wire, then aggregate per market over a rolling window to detect cascades.

grpcurl -H 'x-api-key: YOUR_KEY' \  -d '{"subscribe":{"stream_type":"EVENTS","filters":{"type":{"values":["liquidation"]}}}}' \  stream.hyperliquidrpc.com:443 \  hyperliquid.Streaming/StreamData

Treasury flow reconciliation

Filter your operational wallets and record deposit and withdraw events as they confirm on-chain. Because amounts are byte-exact strings, the ledger you build matches the chain to the last digit.

Related