Skip to main content

setFields(options)

Set the fields to be retrieved for data items of each supported type. The options object has the following structure:
Every field selector is a collection of boolean fields, typically (with a notable exception of trace field selectors) mapping one-to-one to the fields of data items within the batch context iterables. Defining a field of a field selector of a given type and setting it to true will cause the data source to populate the corresponding field of all data items of that type. Here is a definition of a data source that requests gas and value fields for transactions:
There are no default optional fields: apart from a small set of always-present fields (listed per item type below), a field that is not requested with setFields() will not be fetched and will be absent from the TypeScript types. Request every field your batch handler reads.
Same fields will be available for all data items of any given type, including the items accessed via nested references. Suppose we used the builder defined above to subscribe to some transactions as well as some logs, and for each log we requested a parent transaction:
After populating the convenience reference fields with augmentBlock() from @subsquid/evm-objects, gas and value fields would be available both within the transaction items of the transactions iterable of block data and within the transaction items that provide parent transaction information for the logs:
Fields that were not requested are missing from the data and from the item types, so reading them fails to compile:
Requesting only the fields you need improves sync performance, as unrequested fields are not fetched from the SQD Network Portal.

Data item types and field selectors

Most IDEs support smart suggestions to show the possible field selectors. For VS Code, press Ctrl+Space.
Here we describe the data item types as functions of the field selectors. Unless otherwise mentioned, each data item type field maps to the eponymous field of its corresponding field selector. Item fields are divided into two categories:
  • Fields that are always present regardless of the setFields() call.
  • Fields that must be requested with setFields(). E.g. a transactionHash field will only be available in logs if the log field selector sets transactionHash: true.
The raw items do not have id, block or relation fields such as log.transaction — these are added by augmentBlock() from @subsquid/evm-objects, see Block data.

Logs

Log data items may have the following fields:

Transactions

Transaction data items may have the following fields:
status field contains the value returned by eth_getTransactionReceipt: 1 for successful transactions, 0 for failed ones and undefined for chains and block ranges not compliant with the post-Byzantinum hard fork EVM specification (e.g. 0-4,369,999 on Ethereum). type field is populated similarly. For example, on Ethereum 0 is returned for Legacy txs, 1 for EIP-2930 and 2 for EIP-1559. Other networks may have a different set of types. authorizationList is populated for EIP-7702 transactions (type 4). l1* fields can only be requested for networks from this list. Requesting them for other networks may cause HTTP 500 responses.

State diffs

StateDiff data items may have the following fields:
The meaning of the kind field values is as follows:
  • '=': no change has occurred;
  • '+': a value was added;
  • '*': a value was changed;
  • '-': a value was removed.
Requesting the kind field also narrows the item type into a discriminated union: e.g. for a diff with kind: '+' the compiler knows that prev is empty and next holds the added value. The values of the key field are regular hexadecimal contract storage key strings or one of the special keys 'balance' | 'code' | 'nonce' denoting ETH balance, contract code and nonce value associated with the state diff.

Traces

Field selection for trace data items is somewhat more involved because their action and result fields may contain different subfields depending on the value of the type field. The retrieval of each one of these subfields is configured independently, with a selector name obtained by prefixing the capitalized subfield name with the trace type (and Result for result subfields). For example, to ensure that all traces of 'call' type contain the .action.gas field, the data source must be configured as follows:
The full Trace type with all its possible (sub)fields looks like this:
The action and result objects are omitted from the item type when none of their subfields are requested. After augmentBlock() every trace also exposes getTransaction(), getParent() and children. The corresponding transaction and parent properties are optional because related data must be requested explicitly — see addTrace().

Block headers

BlockHeader data items may have the following fields:
Use number for the block height; height remains available only as a deprecated alias. The stream converts the raw block time from seconds to milliseconds. Pass timestamp directly to new Date(timestamp) without multiplying it by 1000. The l1BlockNumber field can only be requested for networks from this list. Requesting it for other networks may cause HTTP 500 responses.

A complete example