Cowrie Research

firehose

4 min read

Firehose

  • Name: Firehose
  • URL: https://firehose.streamingfast.io/
  • Category: blockchain-data extraction layer / files-based streaming infrastructure / indexer-ingest middleware
  • Summary: Firehose is lower-layer blockchain-data plumbing: instrumented nodes, file-based history, replayable streams, fork-aware cursors, and relay/merge topology. The point is to make ingest and delivery explicit instead of hiding them inside brittle RPC polling.
  • What it does:
    • Extracts blockchain data from Firehose-enabled instrumented nodes rather than relying on ordinary JSON-RPC query patterns
    • Stores and serves block data through a files-based, streaming-first architecture designed for replay as well as real-time consumption
    • Uses a component family that includes Reader nodes, Relayers, Mergers, Firehose gRPC servers, and Substreams integrations
    • Provides fork-aware cursors so consumers can resume or replay streams from specific positions while preserving chain/fork context
    • Supports low-latency setups where multiple Reader components race and a Relayer deduplicates and forwards the earliest block downstream
    • Positions itself as a replacement for The Graph’s original blockchain data extraction layer
    • Exposes a common firehose-core maintenance layer so chain-specific Firehose integrations can track one shared Golang stack instead of each re-implementing operational plumbing
  • Key claims:
    • The Firehose docs describe it as a files-based and streaming-first blockchain-data technology developed by StreamingFast with The Graph Foundation, which is the clearest reason to catalog it as data-plane infrastructure rather than as a simple developer SDK.
    • The Firehose overview is explicit that the system was built in reaction to downtime, slow linear reprocessing, and brittle JSON-RPC behavior. That makes the main analytical move a control-plane shift away from query-time node access and toward pre-extracted, replayable block streams.
    • The component split is the most reusable mechanism insight. Reader nodes, Relayers, Mergers, Firehose servers, and Substreams are separate roles, which means practical power can sit in node instrumentation, storage custody, relayer placement, merger behavior, or stream-serving policy rather than in one generic indexer label.
    • Cursor handling matters because it shows Firehose is not just a live pub/sub feed. The docs say cursors capture the consumer’s position within blockchain and ForkDB state, which makes resumability and fork-awareness first-class features.
    • The low-latency racing readers design is especially important. The docs describe multiple Readers fronted by Relayers that deduplicate streams and push the first-arriving block downstream, which turns network placement and relay operation into meaningful sources of performance advantage.
    • The Graph’s Firehose docs say it is intended to replace The Graph’s original extraction layer, which makes it analytically useful as a sub-protocol inside the wider Graph ecosystem rather than only a standalone StreamingFast product.
    • The firehose-core README reveals another useful governance and maintenance surface: chain integrators are expected to build on a shared core facade so they inherit flags, defaults, and dependency changes from one upstream project instead of independently evolving every chain-specific stack.
    • Firehose belongs in the active corpus because it makes blockchain-data ingestion legible as instrumented-node extraction, file-based canonical history, relay/merge topology, cursor semantics, and downstream transformation infrastructure. That makes it a strong lower-layer comparison point for SQD and Substreams.
  • Whitepaper: No standalone Firehose whitepaper surfaced in this pass. The strongest primary materials were the official Firehose overview/docs, The Graph’s Firehose docs page, the Firehose docs repository README and architecture page, and the firehose-core repository README; see ../whitepapers/firehose-primary-sources-2026-05-12.md.
  • Sources:

Internal linkages

Control surface

  • The leverage sits in node instrumentation, storage custody, reader/relayer/merger placement, cursor semantics, and the policies wrapped around stream serving.

  • That is why this note matters: Firehose makes the ingest layer visible as an operator stack instead of pretending blockchain data just appears from an RPC endpoint.

  • Keep the comparison cut clean. Firehose sits below query-market notes like The Graph and closer to the raw extraction path.

  • Last reviewed: 2026-05-31 UTC

Graph View

Backlinks