This guide explains Bitcoin Core getchainstates RPC in plain English. It shows what the command does, what its result means and what it cannot prove.
TL;DR
- What it is: Bitcoin Core 26.0 introduced getchainstates to expose the chainstates used during assumeUTXO snapshot synchronisation. It returns the header count and an array ordered by work with the most-work active chainstate last.
- Why it matters: getchainstates makes assumeUTXO trust visible. Operational completion is not a current snapshot tip; it is a matching snapshot base plus a fully validated background history and reconciled active chainstate.
- Current position: Require a second reviewer and explicit rollback or expiry, and pause payments, signing or network-dependent services until post-change evidence is complete.
What this means in simple English
An RPC is a command sent to one Bitcoin Core node. It can ask that node for information or request a local action. A successful reply describes that node; it does not automatically prove what happened across the Bitcoin network.
Beginners can focus on the input, the result and the limit of that result. Operators should test the command on the exact Bitcoin Core version they run before relying on it.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- RPC:
- A command that software sends to a node to request information or a local action.
- UTXO:
- An unspent transaction output: a piece of bitcoin that can be used as an input to a later transaction.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Result shape
headers is global header progress. Each chainstate includes blocks, bestblockhash, difficulty, verificationprogress, cache allocations, optional snapshot_blockhash and validated.
Ordering
The array is ordered by work and the most-work active state is last. Do not assume the first entry is primary or hard-code a two-entry array forever.
Snapshot identity
snapshot_blockhash appears when a chainstate is based on a snapshot. Compare it with the intended assumeUTXO base and the source snapshot record.
Validated flag
true means every block in that chainstate has been validated. false identifies a snapshot-based state whose background justification is incomplete.
Progress
verificationprogress is an estimate toward the network tip, not a cryptographic completion proof. Track blocks and bestblockhash and watch for sustained stalls.
Cache metrics
coins_db_cache_bytes and coins_tip_cache_bytes reveal allocation, not actual resident memory or performance. Correlate them with host metrics and configuration.
Completion policy
Keep monitoring until background validation succeeds and chainstate cleanup is observed. Reconcile tips after reorganisations and never delete original data merely because the snapshot tip is current. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is Bitcoin Core getchainstates RPC?
Bitcoin Core 26.0 introduced getchainstates to expose the chainstates used during assumeUTXO snapshot synchronisation. It returns the header count and an array ordered by work with the most-work active chainstate last.
Is Bitcoin Core getchainstates RPC active or supported today?
Require a second reviewer and explicit rollback or expiry, and pause payments, signing or network-dependent services until post-change evidence is complete.
Why does Bitcoin Core getchainstates RPC matter?
getchainstates makes assumeUTXO trust visible. Operational completion is not a current snapshot tip; it is a matching snapshot base plus a fully validated background history and reconciled active chainstate.
Do beginners need to use the technical details?
No. The command is mainly for people who operate Bitcoin Core or software connected to it. Other readers can use the article to understand what an operator or service is measuring.
Conclusion
getchainstates makes assumeUTXO trust visible. Operational completion is not a current snapshot tip; it is a matching snapshot base plus a fully validated background history and reconciled active chainstate.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
