What is indexer?

Software that reads a chain block by block and writes the results into a database that can be queried quickly.

Chains are built to validate, not to answer questions like every transfer this address ever made, so almost every interface you use sits on an indexer rather than on a node. The important consequence is that indexers can disagree, lag, or be wrong while the chain is fine, which is why two explorers sometimes show different token balances for the same wallet.

Reconciling to the chain is always possible; it is just slow. Understanding this is the difference between assuming your funds are gone and recognizing that a screen is stale.

How it works

A node stores blocks and the current state, and it answers the questions consensus requires: is this block valid, what is this account's balance now, what does this contract return. It has no efficient way to answer historical or aggregated questions, because nothing is stored in a shape that supports them.

An indexer fills that gap. It connects to a node, walks the chain from a starting block to the tip, decodes transactions and event logs, and writes normalized rows into a conventional database. A wallet's transaction list, a portfolio tracker's history, a decentralized exchange's chart, and a block explorer's search are all queries against that database.

Three failure modes follow from the design.

1. Lag. The indexer is always some distance behind the tip, usually seconds, occasionally much longer after an outage or a resync.
2. Decoding gaps. A contract using an unusual pattern may not be decoded correctly, so transfers appear missing or mislabeled even though they happened.
3. Reorganization handling. When a chain rolls back a block, an indexer must unwind the rows it wrote for it. One that unwinds incompletely keeps reporting data the chain has already discarded, which is the usual source of a wrong balance.

The chain remains the authority in every case. A block explorer that disagrees with your wallet is two indexers disagreeing, and the transaction hash on chain settles it.

Example

Illustrative walkthrough. You withdraw a token from an exchange and your wallet shows nothing five minutes later, while a block explorer shows the transaction confirmed. Both are reading indexed data. The explorer's indexer has processed the block; your wallet's provider has not, or has not decoded that particular token contract. Paste the transaction hash into a second explorer and check the recipient address matches yours. If it does, the funds are on the chain and only the display is behind.

Why it matters when you buy

After any withdrawal from an exchange, the transaction hash is your evidence and the block explorer is where you check it, not the wallet screen. The block explorer guide covers reading one, and the chain pages show typical confirmation times per network so you know when a delay is actually unusual.

Related terms

• block explorer: the most familiar indexer front end
• subgraph: a widely used indexing definition format
• node: the source an indexer reads from
• event log: the records it decodes into rows
• chain reorganization: the event that causes stale rows
• archive node: full history an indexer often needs

Questions

Why does my wallet show a different balance from the explorer?

They read different indexers. One is behind, or one has decoded a token contract the other has not. The chain itself has one answer, and the transaction hash reveals it.

Is my transaction lost if no explorer shows it?

More likely it was never broadcast, or you are searching an explorer for a different network. Confirm the chain first, then check the sending wallet's own record.

Do indexers ever change historical data?

Yes, when a chain reorganizes and blocks are discarded. A correctly built indexer unwinds those rows, which is why a very recent transaction can briefly appear and then disappear.