Hyperliquid Replica Cmds Block Data
Hyperliquid replica_cmds is raw block data: every signed action bundle a consensus block carried and the per-action execution result, keyed by block height.
Replica cmds is where a Hyperliquid node streams blocks parsed as transactions. One record is one consensus block: the block height, the consensus block with its time, round, parent round, proposer and hardfork, every signed action bundle the block carried, and the per-action execution results. It is the rawest layer of HyperCore order flow, because fills, order statuses and order book diffs are views of what the block already holds.
What one record represents
“Blocks parsed as transactions are streamed to” replica_cmds, and the node’s --replica-cmds-style flag set to actions-and-responses writes “both actions and responses”.
One record is one consensus block, carrying height; abci_block, the consensus block with its time, round, parent_round, proposer, hardfork and signed_action_bundles; and resps, the execution results. Each bundle pairs a transaction hash with a payload holding the broadcaster and its signed actions, and each signed action carries a signature, a nonce, the action itself, and optional vaultAddress and expiresAfter fields.
height is the sequential block number, carried on the record. round and parent_round are HyperBFT consensus rounds: they advance on their own schedule and can skip, so a round is not a block number and does not join as one. Hyperliquid documents the path and the style flag, not the record’s internal shape; the action and response formats inside it are documented.
The compact order format: a, b, p, s, r, t, c
Hyperliquid’s exchange endpoint lists the order wire format’s keys: “a is asset / b is isBuy / p is price / s is size / r is reduceOnly / t is type / c is cloid (client order id)”. t is either a limit carrying a tif or a trigger carrying isMarket, triggerPx and tpsl. Those keys belong to an order inside an order action: on a modify, the top-level a is always_place, a boolean.
Asset ids decode through Hyperliquid’s asset-ids schema, where a perp is its index in meta, a builder-deployed perp is 100000 + perp_dex_index * 10000 + index_in_meta, and spot is 10000 + index. Alongside order, the endpoint documents cancel, cancelByCloid, scheduleCancel, modify, batchModify, updateLeverage, updateIsolatedMargin and the transfer and staking actions; validator and deploy actions appear too.
How to tell whether an action succeeded
resps carries the per-action result, a status of ok or err, and on err the response is an error string. A per-order error can also ride inside an ok response, in the statuses list of the response data.
Actions, statuses and diffs
The same event is readable at three altitudes. Order status updates carry the transition the resulting order went through, order book diffs carry the mutation it made to the book, and L4 order book snapshots carry the book those mutations land on. The executions are Hyperliquid fills.
Delivery
Available history is delivered as files to your own bucket. Fills, funding payments and position snapshots are also available as a Snowflake datashare and real time via Kafka Streaming, and they carry the same block height, so they join to the blocks without a translation layer.
Hyperliquid fields SonarX indexes
| Hyperliquid field | What it is | SonarX indexes it |
|---|---|---|
height | the sequential block number, carried on the record itself | ✓ |
abci_block | the consensus block, with its time, round, parent round, proposer and hardfork | ✓ |
signed_action_bundles | bundles of signed actions, each a transaction hash paired with its payload | ✓ |
signature | the r, s and v of the signature on the action | ✓ |
vaultAddress | the subaccount or vault address the master account is acting for | ✓ |
expiresAfter | the timestamp in milliseconds after which the action is rejected | ✓ |
action | the action itself, such as an order, a cancel or a modify | ✓ |
type | the action type, for example order, cancel, cancelByCloid, modify or scheduleCancel | ✓ |
orders | the orders an order action places | ✓ |
a | the asset, on an order inside an order action | ✓ |
b | the isBuy flag | ✓ |
p | the price | ✓ |
s | the size | ✓ |
r | the reduceOnly flag | ✓ |
t | the type: either a limit carrying a tif, or a trigger carrying isMarket, triggerPx and tpsl | ✓ |
c | the cloid, or client order id | ✓ |
cancels | the resting orders a cancel action targets | ✓ |
resps | the per-action execution result, ok or err | ✓ |
Field definitions and mechanics: Hyperliquid's own documentation. Chain overview: indexed Hyperliquid blockchain data.
Frequently asked questions
What is replica_cmds data on Hyperliquid?
Replica cmds is where a Hyperliquid node streams blocks parsed as transactions. In the actions-and-responses style, each block carries both the signed actions submitted to HyperCore and what the chain did with them, which makes it the rawest layer of Hyperliquid order flow.
What does one replica cmds record represent?
One replica cmds record is one consensus block. It carries the block height, the consensus block with its time, round, parent round, proposer and hardfork, the signed action bundles the block carried, and the execution results for those actions. Each bundle pairs a transaction hash with a payload holding the broadcaster and the signed actions it submitted.
What do a, b, p, s, r, t and c mean in a Hyperliquid order action?
They are Hyperliquid's compact order format, documented on the exchange endpoint: a is asset, b is isBuy, p is price, s is size, r is reduceOnly, t is type and c is cloid, the client order id. The value of t is either a limit carrying a time in force, or a trigger carrying isMarket, triggerPx and tpsl.
How do you tell whether a Hyperliquid action succeeded?
By its execution result: each action in the block has a response whose status is either ok or err, and on err the response is an error string. A per-order error can also ride inside an ok response, in the statuses list of the response data, so an accepted transaction does not by itself mean every order in it was placed.
How does replica cmds data relate to order statuses and book diffs?
Replica cmds, order statuses and book diffs are the same events at different altitudes. Replica cmds carries the signed action and its execution result, order status updates carry the transition the resulting order went through, and order book diffs carry the mutation that order made to the book. All three sit on the same block height, so they line up intent, outcome and book state.
Is abci_block.round the block number?
No. Round and parent round are HyperBFT consensus rounds, which advance on their own schedule and can skip, so a round is not a sequential block number and does not join as one. The sequential block number is the height field, carried on the record.
Get started
Query Hyperliquid replica cmds data
Tell us the delivery target and the history depth you need, and we scope the Hyperliquid share against it.
Other Hyperliquid datasets
Hyperliquid Order Status Updates Data
Hyperliquid order status data records every transition an order goes through on HyperCore, from placement to fill, cancel or reject, with the full order object.
Hyperliquid Order Book Diffs Data
Hyperliquid order book diffs carry every mutation to HyperCore's per-order book, one block at a time: a new resting order, a resize, or a removal.
Hyperliquid L4 Order Book Snapshots Data
Hyperliquid L4 order book data is the whole HyperCore book at one block height as individual resting orders: each order's id, price, size and owning address.
Hyperliquid Fills Data
Trades executed on HyperCore, per user and per market: price, size, side, direction, the position before the fill, realised PnL on the closed part, and fees.