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. These captured events can also support custom liquidation or 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.

# 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

Field	Type	Description
type	string	funding / liquidation / deposit / withdraw / position update.
user	string	Affected wallet.
coin	string	Market symbol (funding, liquidation).
usdc	string	USDC amount of the event (signed for funding).Byte-exact decimal string.
funding_rate	string	Funding rate applied (funding events).Byte-exact decimal string.
szi	string	Signed position size the payment applied to.Byte-exact decimal string.
liquidation	object?	Liquidated size, price, and mark price (liquidation events).

Raw financial fields typed string preserve their decimal representation from the node. Store them as strings or arbitrary-precision decimals. Calculated fields, including aggregated book sizes, are identified by their field notes.

Server-side filters

coins[]
wallets[]
recent replay up to 6 hours

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.