# Hyperliquid Trades - Live Trade Prints

Trades are normalized match records for tape displays, execution analytics, and market-flow signals. Each trade reports the taker side, execution price and size, transaction hash, match identifier, and every bid-side and ask-side participant.

## Access

| Availability | Access                                                               | Details                                                        |
| ------------ | -------------------------------------------------------------------- | -------------------------------------------------------------- |
| Live         | [StreamTrades](https://www.dwellir.com/docs/hyperliquid/stream_trades)                      | Provides typed V3 gRPC trade batches.                          |
| Live         | [Order Book WebSocket trades](https://www.dwellir.com/docs/hyperliquid/trades)              | Provides live JSON trade messages and an optional user filter. |
| Historical   | [Hyperliquid Index fills](https://www.dwellir.com/docs/hyperliquid/hyperliquid-index/fills) | Provides a historical alternative.                             |
| Historical   | [Tick data](https://www.dwellir.com/docs/hyperliquid/tick-data)                             | Provides a historical alternative.                             |
| Archival     | [S3 Bucket](https://www.dwellir.com/docs/hyperliquid/historical-data)                       | Provides archival fill records for custom processing.          |

## Live behavior

[StreamTrades](https://www.dwellir.com/docs/hyperliquid/stream_trades) accepts 1-20 coins and an optional user filter. It batches matches by `(block, coin)`.

`bid_users` and `ask_users` are repeated fields because a match can contain multiple makers. A self-trade can place the same address on both sides.

Within one block, identify a match by `(coin, tid)`. Across blocks, include the batch's `block_number` in the match key.

The gRPC stream is live-only. It has no opening snapshot and no historical replay. `ABORTED` means frames were lost or live state reset. Reconnect for new activity, then use an archival or indexed alternative to recover any missed interval.

## Sample data

This synthetic V3 protobuf payload uses visible redaction markers instead of production identifiers:

```protobuf
time: 1785736814057
block_number: 1058646974
trades: {
  coin: "<redacted-market>"
  side: "B"
  px: "114250.0"
  sz: "0.75"
  hash: "<redacted-transaction-hash>"
  time: 1785736814057
  tid: 99887766
  bid_users: "<redacted-bid-user>"
  ask_users: "<redacted-ask-user>"
  ask_users: "<redacted-second-ask-user>"
  synthetic: false
}
```

The Order Book WebSocket represents the same participant set in a single `users` array. The V3 gRPC payload keeps bid-side and ask-side users separate.

## Related pages

- [Whale tracking guide](https://www.dwellir.com/guides/hyperliquid-whale-tracking) — Build real-time alerts around large, attributed trades.
- [Order book WebSocket guide](https://www.dwellir.com/guides/order-book-server) — Combine trades with L2, L4, and multi-coin routing.
- [Derived fill views](https://www.dwellir.com/docs/hyperliquid/data-catalog/derived/fill-views) — Move from match-level trades to participant-specific execution records.
