Unfinalized blocks and reorgs

Indexing unfinalized blocks

To index unfinalized (“hot”) blocks and stay correct across blockchain reorganizations, a squid must

use a Database with hot block support in its run() call. For TypeormDatabase that support is on unless explicitly disabled; state it explicitly with

import {run} from '@subsquid/batch-processor'
import {TypeormDatabase} from '@subsquid/typeorm-store'

run(dataSource, new TypeormDatabase({supportHotBlocks: true}), async ctx => {
  // ...
})

not cap the block range of its data source below the chain head.

With a hot-block-aware database, run() consumes the fork-aware stream of the data source. When a reorganization happens, the processor detects that the incoming blocks no longer extend the chain it has indexed, asks the Database to roll back the changes made for the orphaned blocks, then runs the batch handler on the new consensus blocks. The state of the Database reflects the current blockchain consensus at all times, and the batch handler code never has to deal with forks itself.

With a database that lacks hot block support (e.g. the file store or TypeormDatabase with {supportHotBlocks: false}), the processor consumes the finalized stream instead and simply stops short of the unfinalized chain head.

Networks without a Portal dataset, including local development chains, can be indexed in the same fork-aware way with the EVM RPC data source.

Overview

Pipes SDK

Squid SDK

Alternative clients

Indexing unfinalized blocks

​Indexing unfinalized blocks

Indexing unfinalized blocks