Blockchain Indexer

What Is a Blockchain Indexer?

A blockchain indexer is a tool that reads raw data from a blockchain node, processes it into a structured format, and stores it in a database optimized for queries. It acts as a search engine layer on top of the blockchain, making it possible for applications to look up balances, transaction histories, and UTXO sets without scanning the entire chain.

Blockchains are designed for consensus and validation, not for answering arbitrary queries. Bitcoin Core, for example, stores the UTXO set in a LevelDB database keyed by transaction ID and output index. There is no native way to query "all UTXOs belonging to address X" without iterating through every entry. The Bitcoin RPC interface can look up individual transactions by their txid, but retrieving a full address history means scanning thousands of blocks one by one.

Indexers solve this by building secondary indexes: data structures that map addresses to transactions, track balance changes over time, and maintain the relationships between inputs and outputs. Applications query the indexer instead of the node, turning seconds-long scans into millisecond lookups.

How It Works

Blockchain indexers follow an Extract, Transform, Load (ETL) pipeline that runs continuously as new blocks arrive.

1. Block ingestion: the indexer connects to a local full node via RPC, ZMQ notifications, or direct peer-to-peer messaging. It monitors the chain tip and reads each new block as it is confirmed.
2. Decoding and parsing: raw block data is deserialized into its component parts. Each transaction is broken down into inputs, outputs, scripts, witness data, and metadata like locktime values.
3. Extraction and transformation: the indexer identifies entities of interest. For a UTXO-based chain like Bitcoin, this means mapping outputs to addresses, tracking which UTXOs are created (unspent) and which are consumed (spent), and computing address balances.
4. Indexed storage: processed records are written into a query-optimized database with indexes on common lookup keys such as address, transaction hash, and block height. Database backends vary by implementation: RocksDB, LevelDB, PostgreSQL, or custom flat-file formats.
5. Query API: the indexer exposes an interface for applications. This can be the Electrum JSON-RPC protocol (for wallet compatibility), an HTTP REST API, or a GraphQL endpoint.

Handling Chain Reorganizations

A critical challenge for indexers is handling chain reorganizations. When the blockchain forks and resolves to a different canonical chain, the indexer must detect the divergence, roll back data from orphaned blocks, and re-index the new canonical blocks.

Detection works by comparing each new block's parent hash against the stored chain tip. If they diverge, the indexer identifies the fork point and reverses all changes made after it. Most indexers define a maximum reorg depth (commonly 200 blocks for Bitcoin) beyond which data is treated as finalized.

Database Architecture

The choice of database backend determines the indexer's performance characteristics and storage requirements. A simplified schema for a Bitcoin address index might look like this:

// Conceptual index structure
// Key: script_hash (SHA256 of output script)
// Value: list of (tx_hash, block_height, is_input)

script_hash_index: {
  "a3f2...": [
    { tx: "7b1c...", height: 800000, input: false },
    { tx: "9e4a...", height: 800150, input: true  }
  ]
}

// UTXO index
// Key: (tx_hash, output_index)
// Value: (script_hash, value_sats)

utxo_index: {
  ("7b1c...", 0): { script: "a3f2...", value: 50000 },
  ("7b1c...", 1): { script: "d8b1...", value: 149000 }
}

Lightweight indexers like electrs store only block heights per script hash and re-parse raw blocks at query time, trading CPU for disk space. Full-featured indexers like Esplora pre-compute and store complete transaction data, enabling fast lookups without touching the underlying node.

Types of Bitcoin Indexers

Bitcoin indexers fall into several categories, each optimized for different use cases and resource constraints.

Electrum Protocol Servers

These indexers implement the Electrum protocol to serve wallet queries: balance lookups, transaction history by address, and UTXO lists. They are the backbone of lightweight Bitcoin wallets that do not run full nodes.

electrs is designed for personal use with minimal storage: roughly 10% of the blockchain size. It achieves this by storing only block heights per script hash and re-reading raw block data at query time. Fulcrum stores complete 32-byte script hashes with transaction numbers, enabling much faster lookups at the cost of higher disk usage. In benchmarks on a Raspberry Pi 4, loading a wallet with ~3,000 addresses took 1.4 seconds on Fulcrum versus 382 seconds on electrs.

Full-Featured Explorer Backends

These indexers build comprehensive databases that can serve block explorer frontends without needing to query the underlying node for most requests.

• Blockstream Esplora: a fork of electrs that creates a complete database of the blockchain. Its index requires approximately 600 GB after compaction and about 1 TB of free space during initial sync. It provides both an HTTP REST API and Electrum protocol support.
• Mempool.space backend: a fork of Esplora with extended indexes including full transaction storage, address prefix search, and blockhash-to-txid mapping. Index size is approximately 1.3 TB after compaction. This powers the popular mempool.space block explorer and fee estimation tool.

EVM Chain Indexers

On smart contract platforms, indexers also decode contract events and state changes. The Graph is the most widely adopted decentralized indexing protocol for EVM chains. Developers define "subgraphs" that specify which contract events to index, how to transform them, and what GraphQL schema to expose. Independent operators stake tokens to process subgraphs and serve queries, with the network supporting over 60 chains and 50,000 active subgraphs.

Use Cases

Wallet Backends

Lightweight wallets like Electrum, Sparrow, and mobile wallets rely on indexers to display balances and transaction histories without running a full node. The Electrum protocol was specifically designed for this: a wallet connects to an Electrum server, subscribes to its addresses, and receives notifications when new transactions arrive. Without indexers, every wallet would need to run its own full node and scan blocks locally, which is impractical for most users. This is analogous to how SPV clients rely on external infrastructure to verify transactions without storing the full chain.

Block Explorers

Services like mempool.space and Blockstream Explorer index the entire blockchain so users can search transactions by txid, view address histories, and monitor network activity. The indexer preprocesses and stores all this data so that web requests return in milliseconds rather than requiring on-the-fly block scanning.

Payment Processors

Payment processors and merchant tools use indexers to monitor incoming payments, track confirmation status, and reconcile transactions. Without an indexer, confirming that a customer's payment arrived at the correct address would require polling the node and parsing raw block data in real time. For high-throughput payment systems like those built on Spark, indexing infrastructure ensures that transaction lookups remain fast even as volume scales.

Analytics and Compliance

On-chain analytics platforms like Dune and Nansen build on indexed data to provide dashboards and research tools. Compliance teams use forensic-grade indexers for chain analysis and transaction monitoring, mapping flows of funds across addresses and identifying patterns.

Why It Matters

Indexers are invisible infrastructure: users interact with wallets, explorers, and payment systems without knowing that an indexer powers the data layer underneath. But the choice of indexer directly affects user experience. A slow indexer means wallet balances take seconds to load. An unreliable indexer means missed payment notifications. A centralized indexer creates a single point of failure and a potential privacy leak, since the indexer operator can see which addresses a wallet queries.

For developers building on Bitcoin, choosing the right indexer involves balancing storage costs, query performance, and operational complexity. A personal wallet server might run electrs on a Raspberry Pi, while a production block explorer needs the full Esplora or Mempool backend on dedicated hardware. Understanding this tradeoff is essential for anyone building Bitcoin infrastructure. For a deeper look at how different node and indexer setups compare, see the research article on Bitcoin node implementation comparison.

Risks and Considerations

Storage and Resource Requirements

Full-featured indexers demand significant storage. The Mempool.space backend requires over 1.3 TB after compaction and roughly double that during the initial sync process. Even lightweight options like electrs need 35+ GB on top of the full node's own storage. These requirements grow over time as the blockchain expands, and operators must plan for ongoing disk usage.

Data Consistency During Reorgs

If an indexer does not handle chain reorganizations correctly, it may serve stale or contradictory data: showing a transaction as confirmed when it was actually orphaned. Applications that rely on indexed data for financial decisions (payment confirmation, balance checks) must either trust the indexer's reorg handling or implement their own confirmation depth thresholds.

Privacy Implications

When a wallet connects to a remote Electrum server, it reveals which addresses it is interested in. The server operator can correlate these queries to build a profile of the wallet's holdings and spending patterns. Running a personal indexer eliminates this leak, which is why privacy-conscious users run their own Electrum server at home. Alternatively, compact block filters (BIP 157/158) allow wallets to download and scan filtered block data locally, avoiding the need to reveal addresses to any server.

Centralization Risk

Most lightweight wallets connect to a small number of public Electrum servers or hosted APIs. If these services go down or begin censoring queries, wallets that depend on them stop functioning. This is a form of infrastructure centralization that runs counter to Bitcoin's design as a peer-to-peer system. The tradeoff between convenience (using a hosted indexer) and sovereignty (running your own) is one that every Bitcoin application must navigate.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.