> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bloklake.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Selecting fields

> Choose exactly the columns you need. Fewer columns means smaller, faster and cheaper responses.

`fields` says which columns to return for each row type. You get only what you select.

```json theme={null}
{
  "fields": {
    "log": {"blockNumber": true, "transactionHash": true, "topic1": true, "topic2": true, "data": true},
    "transaction": {"hash": true, "from": true, "gasUsed": true},
    "block": {"number": true, "timestamp": true}
  }
}
```

* The keys are **singular** (`log`, `transaction`, `block`), unlike the plural filter keys
  (`logs`, `transactions`).
* Names are **camelCase in the request** and come back **snake\_case** in the response:
  `blockNumber` → `block_number`, `gasUsed` → `gas_used`. The TypeScript client returns rows
  under the camelCase names, and the Python client also accepts snake\_case names in queries;
  see [Clients](https://docs.bloklake.com/clients.md#what-you-get-back).
* An unknown field name is a `400` naming it, so a typo can't silently drop a column.
* Setting a field to `false` is the same as leaving it out.
* If you filter a row type but select none of its fields, that's a `400`
  (`no fields selected for logs`).

The full lists, with types and descriptions, are in the field reference:
[logs](https://docs.bloklake.com/api-reference/fields/logs.md), [transactions](https://docs.bloklake.com/api-reference/fields/transactions.md),
[blocks](https://docs.bloklake.com/api-reference/fields/blocks.md).

## Fields worth knowing

| Field | Row type | Notes |
| - | - | - |
| `blockNumber` | logs, transactions | Added to every row so you can join without a second lookup. |
| `blockTimestamp` | logs | The block's timestamp on every log, so log queries need no blocks stream. |
| `topics` | logs | Shortcut that selects `topic0`–`topic3`. They still come back as four separate columns. |
| `sighash` | transactions | The first 4 bytes of `input`; `null` if `input` is shorter. Much smaller than `input` when you only need the function. |
| `status` | transactions | `1` success, `0` reverted, `null` before Byzantium (not "zero"). |
| `effectiveGasPrice`, `gasUsed` | transactions | From the receipt: the fee paid is `gasUsed × effectiveGasPrice`. |
| `contractAddress` | transactions | Set on contract creations. |
| `accessList`, `authorizationList`, `withdrawals` | transactions, blocks | Nested lists of structs; see [Data types](https://docs.bloklake.com/responses/data-types.md). |

## Select only what you use

You're [billed by the bytes of the rows you receive](https://docs.bloklake.com/billing/how-billing-works.md), so every column
you don't need costs money and time. Some fields are much larger than others:

| Field | Size per row |
| - | - |
| `logsBloom` (block, transaction) | 256 bytes |
| `input` (transaction), `data` (log) | variable: often hundreds or thousands of bytes |
| `accessList` | variable, can be large |
| hashes, topics, roots | 32 bytes |
| addresses | 20 bytes |
| amounts (`value`, gas prices) | 16 bytes |
| numbers (`gasUsed`, `nonce`, block numbers) | 8 bytes |

> [!TIP]
>
> For a transfer you usually need `topic1`, `topic2` and `data`. You already know `topic0` (you
> filtered on it) and `topic3` is always null for ERC-20 `Transfer`. Leaving those two out makes
> each row 64 bytes smaller.

## Same fields on every chain

Every field can be selected on every chain. If a chain doesn't have a field (Arbitrum fields
on Ethereum, `withdrawals` on Robinhood Chain), the column is all `null` and listed in
`unavailable_fields`. One request shape works across chains. See
[Fields a chain doesn't have](https://docs.bloklake.com/querying/unavailable-fields.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.