> For a complete page index, fetch https://docs.conduit.xyz/llms.txt

# Query flashblock state

> Query the latest flashblock state through a G3 chain's public JSON-RPC endpoint.

Use your chain's existing public JSON-RPC endpoint to query the state accumulated through the latest flashblock. Pass the `pending` block tag to a supported RPC method. You don't need a separate connection or request format.

> **Note**
>
> Conduit enables flashblocks per chain. Contact your Conduit account team for your chain's RPC endpoint and credentials.

## Query pending state

Start with your chain's authenticated RPC endpoint:

```bash
export RPC_URL="https://[YOUR_RPC_HOST]/[YOUR_API_KEY]"
```

For example, use `eth_call` with `pending` to run a read against the latest flashblock state:

```bash
curl "$RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_call",
    "params": [
      {
        "to": "0x[CONTRACT_ADDRESS]",
        "data": "0x[CALL_DATA]"
      },
      "pending"
    ]
  }'
```

Use `latest` instead when you want the latest canonical state:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_call",
  "params": [
    {
      "to": "0x[CONTRACT_ADDRESS]",
      "data": "0x[CALL_DATA]"
    },
    "latest"
  ]
}
```

Because the two tags can refer to different states, a call may return a value with `pending` before the same value is visible with `latest`.

## Supported methods

The following `eth_` methods read flashblock data when called with `pending`. The examples in the **`params`** column show the exact JSON-RPC parameter order.

### Read account and contract state

| Method                    | `params`                                       | Result                                                                                                             |
| ------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `eth_getBalance`          | `[address, "pending"]`                         | Account balance.                                                                                                   |
| `eth_getTransactionCount` | `[address, "pending"]`                         | Account nonce from pending state. This can include consecutive transactions waiting in the local transaction pool. |
| `eth_getCode`             | `[address, "pending"]`                         | Contract code.                                                                                                     |
| `eth_getStorageAt`        | `[address, storageSlot, "pending"]`            | Value at one contract storage slot.                                                                                |
| `eth_getStorageValues`    | `[{ address: [storageSlot, ...] }, "pending"]` | Values from multiple storage slots and addresses.                                                                  |
| `eth_getAccountInfo`      | `[address, "pending"]`                         | Account balance, nonce, and code in one response.                                                                  |

`eth_getStorageValues` and `eth_getAccountInfo` are Reth extensions. A `storageSlot` is a 32-byte, hex-encoded storage key, such as `0x0000000000000000000000000000000000000000000000000000000000000000` for slot 0.

### Run calls against pending state

| Method            | `params`                         | Result                                                                                                                       |
| ----------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `eth_call`        | `[transaction, "pending"]`       | Return data from executing one call. Optional state and block overrides can follow the block tag.                            |
| `eth_estimateGas` | `[transaction, "pending"]`       | Gas estimate using pending code, storage, balances, and nonces. Optional state and block overrides can follow the block tag. |
| `eth_simulateV1`  | `[simulationPayload, "pending"]` | Results from simulating one or more calls on top of pending state.                                                           |

An `eth_simulateV1` request uses the following shape:

```bash
curl "$RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_simulateV1",
    "params": [
      {
        "blockStateCalls": [
          {
            "calls": [
              {
                "to": "0x[CONTRACT_ADDRESS]",
                "data": "0x[CALL_DATA]"
              }
            ]
          }
        ]
      },
      "pending"
    ]
  }'
```

### Read the partial block

| Method                                       | `params`                                                        | Result                                                       |
| -------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------ |
| `eth_getBlockByNumber`                       | `["pending", includeFullTransactions]`                          | The partial block accumulated through the latest flashblock. |
| `eth_getHeaderByNumber`                      | `["pending"]`                                                   | The partial block's header.                                  |
| `eth_getBlockTransactionCountByNumber`       | `["pending"]`                                                   | Number of transactions accumulated in the partial block.     |
| `eth_getBlockReceipts`                       | `["pending"]`                                                   | Receipts accumulated in the partial block.                   |
| `eth_getTransactionByBlockNumberAndIndex`    | `["pending", transactionIndex]`                                 | One transaction from the partial block.                      |
| `eth_getRawTransactionByBlockNumberAndIndex` | `["pending", transactionIndex]`                                 | One raw, encoded transaction from the partial block.         |
| `eth_getLogs`                                | `[{ "fromBlock": "pending", "toBlock": "pending", ...filter }]` | Logs accumulated in the partial block that match the filter. |

`includeFullTransactions` is a boolean. Set it to `true` to return full transaction objects or `false` to return transaction hashes. `transactionIndex` is a hex-encoded quantity, such as `0x0` for the first transaction.

For example, fetch the current partial block with transaction hashes:

```bash
curl "$RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBlockByNumber",
    "params": ["pending", false]
  }'
```

To query only logs from the current partial block:

```bash
curl "$RPC_URL" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getLogs",
    "params": [
      {
        "address": "0x[CONTRACT_ADDRESS]",
        "fromBlock": "pending",
        "toBlock": "pending"
      }
    ]
  }'
```

### Look up a transaction by hash

If you already know a transaction hash, these methods also check the latest flashblock without a block-tag parameter:

| Method                      | `params`            | Result                                                                                                 |
| --------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------ |
| `eth_getTransactionByHash`  | `[transactionHash]` | The transaction. If it has appeared in a flashblock, the response includes its partial block metadata. |
| `eth_getTransactionReceipt` | `[transactionHash]` | The transaction receipt once it appears in a flashblock.                                               |

## Treat pending data as a preconfirmation

Flashblock state is available before the block seals, so it's not yet canonical. A new flashblock can also arrive between two RPC requests, causing consecutive `pending` queries to observe different snapshots.

Conduit designs [flashblock reorgs](/chains/guides/g3/connect-to-flashblocks#flashblock-reorgs) to be rare, with a target of fewer than three per year. G3's durability design aims to limit these reorgs to scenarios involving major hardware faults.

Use `pending` when you need the lowest-latency view. Use `latest`, or query the sealed block by number or hash, before treating the result as canonical.

Not every RPC method that accepts a block tag reads the flashblock state. Use the methods listed on this page for pending-state queries. To consume each partial update directly, [connect to the flashblocks stream](/chains/guides/g3/connect-to-flashblocks).