> ## 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.

# Fields a chain doesn't have

> Why some columns are always null on some chains, and how to tell them from real nulls.

Chains differ. Ethereum has withdrawals and blobs; Arbitrum chains have L1 block numbers and
retryable tickets; OP-Stack chains have deposit transactions and L1 fees. Bloklake gives
every chain the **same schema** anyway:

* You can select any field on any chain.
* A field the chain doesn't have comes back as an **all-null column**.
* The response lists those fields so you can tell them from real nulls.

One client, one schema, every chain.

## How it's reported

| Format | Where | Example |
| - | - | - |
| Arrow | `bl.unavailable_fields` in each stream's schema metadata | `"transactions.mint,transactions.l1_fee"` (`""` when none) |
| JSON | `unavailable_fields` | `["transactions.mint", "transactions.l1_fee"]` |

Entries are `<row type>.<column name>`, using the snake\_case column names, in the order
transactions, logs, blocks. Only fields you **selected** are listed.

## Real nulls vs unavailable fields

A null in a field that isn't listed is a real null:

* `to` on a contract creation
* `baseFeePerGas` before London
* `status` before Byzantium
* `topic3` on an event with fewer indexed arguments
* an Arbitrum retryable field on an ordinary transaction

A field listed in `unavailable_fields` is null in **every** row on this chain.

## Rejecting them instead

If you'd rather get an error than an all-null column, add `"strictFields": true`. Selecting a
field the chain doesn't have is then a `400 invalid_query` naming every such field, and nothing
is billed:

```bash theme={null}
curl https://api.bloklake.com/v1/chains/rh/query/json \
  -H "Authorization: Bearer $BLOKLAKE_API_KEY" -H 'content-type: application/json' \
  -d '{"fromBlock": 36000000, "toBlock": 36000000, "strictFields": true, "transactions": [{}],
       "fields": {"transaction": {"hash": true, "mint": true, "l1Fee": true}}}'
```

```json theme={null}
{"error":{"code":"invalid_query","message":"strictFields: this chain has no values for transactions.mint, transactions.l1_fee (GET /v1/schema lists the fields it has)"}}
```

`strictFields` is set per request: it works with a [`queryId`](https://docs.bloklake.com/querying/prepared-queries) too,
and isn't part of the prepared query, so the same query can be strict on one call and lenient on
the next. Use it when one schema is meant for one chain and a missing field means a mistake.

## Finding out ahead of time

[`GET /v1/schema`](https://docs.bloklake.com/api-reference/schema) lists every field with `available: true/false` for
that chain, plus the chain's `families` (`base`, `arbitrum`, `op_stack`). It's free and needs no
key.

```bash theme={null}
curl -s https://api.bloklake.com/v1/chains/rh/v1/schema | jq '.row_types.blocks[] | select(.available == false) | .dsl_name'
```

The [chain pages](https://docs.bloklake.com/chains/overview.md) and the
[chain status page](https://dashboard.bloklake.com/chains) list them too.

## Typos are still errors

Only real field names are accepted. `withdrawals` on Robinhood Chain is fine (null column);
`withdrawls` anywhere is a `400`.


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