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.
We build explorers around deterministic ingestion, chain reorganisation handling and reconciliation with the node that remains the source of chain data.
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.
Canonical block ancestry is checked before indexed state advances. A rollback journal reverses affected transactions, balances and UTXOs before the replacement branch is applied.
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.
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.
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.
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.
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.
Checkpoints, rollback records and idempotency rules are specified before bulk ingestion begins. Test fixtures cover competing branches, duplicate notifications and interrupted commits.
Address, UTXO, transaction and network views are implemented against bounded query paths. API limits and cache lifetimes reflect update frequency and database cost.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No. A rich list can rank addresses or script destinations, but one holder may control many addresses and one address may represent many users.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.