Web3 & Blockchain

A block explorer whose index can be explained and rebuilt

We build explorers around deterministic ingestion, chain reorganisation handling and reconciliation with the node that remains the source of chain data.

Capabilities

What this service delivers

01

Node ingestion and replay

The indexer consumes ordered blocks from a compatible node RPC interface and records durable checkpoints. Idempotent processing permits bounded replay after interruption, schema change or detected inconsistency.

02

Reorganisation handling

Canonical block ancestry is checked before indexed state advances. A rollback journal reverses affected transactions, balances and UTXOs before the replacement branch is applied.

03

Address and UTXO indexes

Purpose-built indexes support address history, spend status, balances and unspent outputs without rescanning the chain. Derived totals retain enough provenance to be checked against source transactions.

04

Search and rich lists

Search resolves blocks, transaction identifiers and valid addresses through typed queries. Rich lists are labelled as indexed estimates because address ownership and clustered holdings cannot be inferred reliably.

05

Mempool views

Pending transaction views track admission, replacement, eviction and confirmation as reported by the connected node. They do not present mempool presence as consensus or a promise of inclusion.

06

Explorer APIs and caching

Versioned endpoints expose blocks, transactions, addresses and network status with pagination and explicit confirmation fields. Rate limits, bounded queries and cache invalidation protect the node and index from disproportionate workloads.

Technology stack

Tools used for the work

TypeScriptNode.jsPostgreSQLRedisBitcoin Core RPCWebSocketsOpenTelemetryDockerPrometheus
Process

How the engagement runs

01

Map chain semantics

We inspect node RPC behaviour, transaction format, address encodings, issuance rules and reorganisation expectations. The index schema records which values are authoritative and which are derived.

02

Design reversible indexing

Checkpoints, rollback records and idempotency rules are specified before bulk ingestion begins. Test fixtures cover competing branches, duplicate notifications and interrupted commits.

03

Build queries and interfaces

Address, UTXO, transaction and network views are implemented against bounded query paths. API limits and cache lifetimes reflect update frequency and database cost.

04

Backfill and reconcile

Historical blocks are indexed with progress, lag and consistency metrics. Sampled and aggregate checks compare indexed outputs with node responses before public traffic is admitted.

05

Operate and repair

Runbooks cover node replacement, deep reorganisation, index drift and complete replay. Alerts distinguish an unavailable interface from data that may be stale or internally inconsistent.

01

The node remains the chain authority

An explorer is a queryable view over one or more nodes, not an independent source of consensus. Its correctness inherits node software, node configuration and the branch observed by that node. The interface therefore reports sync height, peer status and index lag rather than presenting every response as current.

We do not promise that an explorer can correct an invalid or compromised node. Independent node comparison can expose disagreement, but protocol correctness requires review at the node and consensus layers.

02

Reorganisations require reversible state

A transaction can move from confirmed to pending or disappear when a stronger branch replaces indexed blocks. The indexer records block ancestry and the mutations attributable to each block so address histories, balances and UTXO spend states can be reversed in a defined order.

Replay starts from a verified checkpoint and uses idempotent writes to avoid duplicated transactions or totals. Deep reorganisation policy is explicit: automatic rollback may stop at a configured boundary and require operator review.

  • Canonical ancestry checks
  • Per-block rollback records
  • Idempotent replay checkpoints
  • Deep-reorganisation alerts
03

Derived indexes must remain reconcilable

Address balances, transaction counts and rich lists are derived conveniences. Scheduled controls compare indexed tips, block hashes, transaction samples, supply totals and UTXO aggregates with node data. A mismatch marks affected views as degraded while investigation or rebuild proceeds.

An index that has silently drifted is worse than no explorer because users may act on plausible but false data. We favour visible unavailability over serving results that cannot pass consistency checks.

04

Public queries need explicit cost boundaries

Unbounded address histories and broad scans can exhaust database, cache and node capacity. Cursor pagination, maximum ranges, request quotas and separately budgeted exports keep ordinary lookup responsive. Cache keys include chain context so a rollback cannot leave canonical pages backed by orphaned data.

Mempool data changes more quickly and varies between nodes, so it receives short cache lifetimes and qualified labels. API consumers receive stable schemas and rate-limit metadata, but availability still depends on the explorer’s node and operating capacity.

FAQ

Common questions

How does a block explorer handle a blockchain reorganisation?

It detects changed block ancestry, reverses mutations from orphaned blocks and applies the replacement branch. Transactions, address totals and UTXO states must all follow the same rollback boundary.

Can a block explorer show every address balance?

Yes, when the chain model and maintained indexes support it. The displayed balance is derived from indexed transactions or UTXOs and should expose its indexed height.

Is a block explorer an independent source of blockchain truth?

No. It is a view over its connected node and inherits that node’s chain selection and correctness; reconciliation can detect disagreement but cannot repair consensus defects.

Can the explorer provide an API for wallets and applications?

Yes, through versioned endpoints for blocks, transactions, addresses and network status. Pagination, quotas and cache policy are required so application traffic cannot overwhelm interactive use or the underlying node.

How long does initial block explorer indexing take?

It depends on chain history, transaction volume, node RPC performance, index design and available storage throughput. We benchmark a representative range before estimating backfill and rebuild windows.

Can a rich list identify who owns the largest balances?

No. A rich list can rank addresses or script destinations, but one holder may control many addresses and one address may represent many users.

Plan a block explorer development engagement.

Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.