Docs
    Guide

    Base vs Extended blocks

    EVM Firehose and Substreams stream the same block type — but how much execution detail a block carries depends on how it was produced. Here's the difference, what each level contains, and when you need extended.

    The short version

    It's the same block type (Firehose sf.ethereum.type.v2.Block) either way — the level is not the block version. What differs is the data source:

    • Extended — produced by an instrumented (Firehose-enabled) node that records the full execution of every transaction.
    • Base — reconstructed by polling a standard JSON-RPC node (eth_getBlock + receipts). No execution tracing, so the block carries less.

    A type.v2 block can therefore be either base or extended. The wire format is identical; extended blocks simply populate fields that base blocks leave empty.

    What's in each

    DataBaseExtended
    Block header (number, hash, timestamp, miner, gas)
    Transactions (from, to, value, input, nonce)
    Receipts — status, gas used, effective gas price
    Event logs (topics + data) (from receipts)
    Call traces — internal contract-to-contract calls
    Native value transfers inside calls
    Balance changes
    Storage changes (state diffs)
    Nonce / code changes
    Per-call gas changes

    Both levels carry event logs, so log-driven indexing (the bulk of subgraphs and Substreams) works on either. The split only matters once you reach for execution traces or state.

    Why it matters

    The level dictates what your Substreams modules can read:

    • Works on base — anything driven by event logs: ERC-20Transfer/Approval, DEX Swap events, contract events in general.
    • Needs extended — internal calls, native ETH transfers that don't emit a log, proxy/factory call graphs, gas accounting per call, and any module reading balance or storage changes (state diffs).

    Run a trace- or state-dependent module against a base chain and those fields come back empty — the module compiles and runs, it just sees nothing. Confirm the chain is extended before relying on them.

    How to tell which a chain is

    Each EVM chain's level is shown as a badge on its endpoint in Endpoints (Firehose / Substreams) — extended or base. Hover the badge for a one-line summary.

    Major high-traffic chains (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB) generally ship extended blocks; some chains are served base-only. The badge is the source of truth — the registry is refreshed daily, so check there rather than memorizing a list.

    In raw Substreams output the block's detail_level field reports the same thing:

    DETAIL_LEVEL_BASE      // RPC-polled — header, txs, receipts, logs
DETAIL_LEVEL_EXTENDED  // instrumented node — + traces + state changes

    Frequently asked

    Is a type.v2 block always extended?
    No. type.v2 is the block schema; base and extended are detail levels within it. A v2 block can be either — it depends on whether the source node was instrumented or RPC-polled.
    Does this affect the RPC or Token API?
    No. Base/extended only describes Firehose and Substreams block streams. The JSON-RPC and Token API products are unaffected.
    My trace/state module returns nothing on a chain — why?
    Almost always because that chain is served baseblocks, which carry no call traces or state changes. Check the endpoint badge; if it reads base, traces and state diffs aren't available there.
    Can a chain move from base to extended?
    Yes — when an instrumented Firehose node becomes available for it. The registry badge updates accordingly; nothing changes in your module, the previously-empty trace/state fields simply start populating.
    Is extended more expensive to consume?
    Extended blocks are larger (they carry traces + state), so Substreams egress per block is higher. If you only need event logs, a base chain moves less data for the same result.

    Related