# Hyperliquid Blocks - replica_cmds Data

`replica_cmds` is the node-written block record. It contains signed action bundles, execution responses, and the consensus metadata needed for block-level replay and auditing.

Use this dataset when you need the full action record. Fills, order statuses, and book diffs are narrower feeds when you only need one kind of event.

## Access

| Availability  | Access                                                                                      | Details                                                                                                                                                                                                              |
| ------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Live / replay | [StreamBlocks](https://www.dwellir.com/docs/hyperliquid/stream_blocks) and [GetBlock](https://www.dwellir.com/docs/hyperliquid/get_block) | V3 selects with `position.block_number` or `position.timestamp` and returns those cursors on `Record` alongside `data`. V2 selects with `block_height` or `timestamp_ms` and returns the JSON bytes in `Block.data`. |
| Archival      | [S3 Bucket](https://www.dwellir.com/docs/hyperliquid/historical-data)                                              | S3 coverage for `replica_cmds`: `2025-01-25` to today, stored as `LZ4-compressed native records`.                                                                                                                    |

## File layout

Blocks use this relative pattern:

```text
replica_cmds/<YYYYMMDD>/<chunk-start>.lz4
```

Each compressed file is JSONL and can contain multiple blocks, with one complete block object per line. Unlike the `*_by_block` datasets, `replica_cmds` does not use the shared events envelope.

The sequential block number is `chunk basename + zero-based line index + 1`. For example, the first line in `100.lz4` is block `101`, and the second line is block `102`.

## Sample data

```json
{
  "abci_block": {
    "time": "2026-01-01T00:00:00.000000000",
    "round": 42,
    "parent_round": 40,
    "proposer": "<redacted-proposer>",
    "hardfork": { "version": 1, "round": 10 },
    "signed_action_bundles": [
      [
        "<redacted-bundle-hash>",
        {
          "signed_actions": [
            {
              "signature": {
                "r": "<redacted-signature-r>",
                "s": "<redacted-signature-s>",
                "v": 27
              },
              "action": {
                "type": "order",
                "orders": [
                  {
                    "a": 170,
                    "b": true,
                    "p": "0.038385",
                    "s": "1514",
                    "r": false,
                    "t": { "limit": { "tif": "Ioc" } }
                  }
                ]
              },
              "nonce": 1704067200000
            }
          ],
          "broadcaster": "<redacted-broadcaster>"
        }
      ]
    ]
  },
  "resps": { "Full": [] }
}
```

This is synthetic representative data. Production addresses, hashes, and signatures use visible `<redacted-...>` markers.

## Important fields

| Field                              | Description                                                      |
| ---------------------------------- | ---------------------------------------------------------------- |
| `abci_block.time`                  | ISO-8601 consensus timestamp with sub-second precision.          |
| `abci_block.round`                 | HyperBFT consensus round. It is not the sequential block number. |
| `abci_block.parent_round`          | Parent consensus round. Consensus rounds may skip.               |
| `abci_block.proposer`              | Proposer address for the block.                                  |
| `abci_block.signed_action_bundles` | Signed user actions grouped into bundles.                        |
| `resps.Full`                       | Execution responses aligned with the action bundles.             |

Derive the sequential block number from the chunk basename and line index. Do not derive it from `abci_block.round`, because consensus rounds can skip.

## Related pages

- [gRPC API overview](https://www.dwellir.com/docs/hyperliquid/grpc) — Review raw-feed positioning, filtering, retention, and recovery.
- [Historical data](https://www.dwellir.com/docs/hyperliquid/historical-data) — Review archival coverage and object layouts for node-written datasets.
- [Miscellaneous events](https://www.dwellir.com/docs/hyperliquid/data-catalog/node-feeds/misc-events) — Inspect ledger and system events emitted alongside block processing.