Methodology

What the engine does

BitcoinProof answers one question: what Bitcoin did this entity control at block height H, or at date X? Given a wallet descriptor or extended public key (xpub) provided by the user, the engine reconstructs the unspent transaction outputs (UTXOs) controlled by those keys at a specified historical block height, and produces a reproducible PDF evidence report.

The engine does not hold private keys, sign transactions, or move bitcoin. It does not provide tax calculations, cost-basis tracking, or capital-gains reporting. It does not aggregate holdings across multiple entities. Its single function is point-in-time custody verification.

The reconstruction pipeline

Every report is produced by the same pipeline. Each stage is deterministic: given identical inputs and the same blockchain data, the pipeline produces the same output.

descriptor or xpub
    ↓
address derivation
    ↓
script-hash conversion
    ↓
indexed blockchain scan (Esplora protocol)
    ↓
transaction graph reconstruction
    ↓
wallet-state simulation
    ↓
historical snapshot at block height H
    ↓
valuation layer (user-supplied price)
    ↓
verification report (PDF)

The scan stage uses script-hash indexed lookup, not naive address-by-address querying. The engine derives the scripts associated with the descriptor, converts them to script hashes, and asks the block explorer for the matching history. This is the same approach used by Electrum servers and is the standard method for descriptor-based wallet reconstruction.

How the historical snapshot works

Block selection rule

The engine applies a single rule: the snapshot block is the last confirmed block whose timestamp is on or before the entered date and time in the configured timezone. One rule, applied uniformly to every jurisdiction.

For the Dutch Box 3 valuation date, the user enters 2026-01-01 00:00 in UTC+01:00 (CET); the engine selects the last block before midnight CET on 1 January 2026. For Switzerland, Norway, or Spain year-end, the user enters 2025-12-31 23:59 in CET; the engine selects the last block of 31 December 2025. For Australian SMSF, the user enters 2025-06-30 23:59 in Australia/Sydney (AEST); the engine selects the last block of 30 June 2025 in Sydney time.

The block is found by binary search over block heights. The selection uses the miner-reported timestamp recorded in the block header. Because miner timestamps are not strictly monotonic, the selection may occasionally differ by one block from a perfectly timed reference; the result is deterministic, reproducible, and the selected block height, hash, and timestamp are all recorded in the report.

Confirmation depth

The engine selects only blocks that are at least N confirmations below the chain tip at scan time. The default is six confirmations, configurable per snapshot. This protects against chain reorganisations: the deeper a block is, the lower the probability that the reconstruction will become invalid because the chain was reorganised after scanning. The configured depth is recorded in every report.

Unconfirmed transactions at the boundary

The user chooses whether to include transactions broadcast before the snapshot date but not yet confirmed at scan time. The default is to exclude them — standard practice for financial reporting. If the user includes them, the report shows an explicit warning and the assurance checklist marks the item as a verification warning. The user's choice is always recorded.

UTXO reconstruction

The engine builds the UTXO set by simulating wallet history forward to the snapshot block. An output is included in the snapshot if it was received at or before the snapshot block height and was not spent at or before that height. Outputs spent after the snapshot height remain in the snapshot — this is what makes a historical reconstruction different from a current-balance query. Replaced (RBF) and superseded transactions are resolved using the final confirmed outcome.

The result is a set of UTXOs, each carrying its txid, output index, amount in satoshis, address, derivation index, and acquisition block height. Amounts are integers throughout — no floating-point arithmetic anywhere in the engine.

What the engine does not do

The boundaries are as important as the function. BitcoinProof does not:

• handle, store, or know private keys or seed phrases;
• sign transactions or move bitcoin in any way;
• retrieve, calculate, or verify any BTC/fiat price — the price, currency, and source are typed in by the user;
• compute cost basis, capital gains, taxable events, or holding-period attribution;
• verify identity, residency, or beneficial ownership;
• aggregate holdings across multiple entities into a single report;
• provide financial, tax, accounting, legal, or investment advice in any jurisdiction.

Data sources and network behaviour

The engine queries the public Bitcoin blockchain through the Esplora protocol. It ships with a default public endpoint, identified in the application before any scan; users with stricter privacy requirements can point the engine at a self-hosted Esplora instance with a single configuration change. Self-hosted backends are a first-class feature, supported on the same code path as the default.

The blockchain backend used is recorded in every report. A recipient who questions the source can verify the result against any other Esplora instance, against any other block explorer, or against a Bitcoin Core node — the data being queried is public.

The application runs locally on the user's computer. Wallet descriptors, extended public keys, identity fields, and report contents do not leave the user's machine. Outbound network calls are limited to: queries to the configured block explorer (carrying Bitcoin script hashes derived from the user's descriptors); licence-key validation requests to bitcoinproof.io/licenses.json; and version-check requests to bitcoinproof.io/version.json. There is no telemetry, no analytics, and no crash reporting.

Independent verifiability

The report is the artefact, but the artefact is not the proof. The proof is the public Bitcoin blockchain. Every BitcoinProof report contains the following information, sufficient for any technically capable third party to reproduce the result without using BitcoinProof at all:

• the wallet descriptor or xpub (with checksum) that was scanned;
• the snapshot block height;
• the snapshot block hash;
• the snapshot block timestamp (miner-reported);
• the configured timezone, entered date, and entered time;
• the confirmation-depth setting that was applied;
• the unconfirmed-transaction policy that was applied;
• the block explorer that was queried;
• the version of the BitcoinProof software that produced the report.

An accountant, auditor, tax authority, or counterparty can take those values, query any independent block explorer, and arrive at the same UTXO set. This is what "reproducible" means in a BitcoinProof report: not that BitcoinProof says so, but that the public Bitcoin blockchain says so, and BitcoinProof has shown its working.

The verification assurance checklist

Every Full Technical Report and every Professional Report contains an eight-item verification checklist. The same eight items appear in every report — never fewer, never more. Each item carries a status of pass, warning, or info. A warning item makes any conditions visible rather than letting them pass quietly.

1. Scan sufficiency. Confirms that every included descriptor was scanned to at least the snapshot block height. A warning here means the report should not be relied on as complete.
2. Confirmation depth. Records the number of confirmations applied (six by default). Information item, never warns.
3. Unconfirmed transaction policy. Records whether unconfirmed transactions at the snapshot boundary were included. Including them is non-standard and triggers a warning.
4. Descriptor completeness. Confirms whether the report covers all descriptors of the entity (Complete Entity Report) or only a selected subset (Selected Descriptor Report). A subset report is always marked as partial.
5. Deduplication. Confirms each UTXO is counted exactly once, even where multiple descriptors of the same entity overlap. Always passes.
6. Block hash recorded. Records the snapshot block hash in full, allowing independent verification on any Bitcoin block explorer.
7. Backend disclosure. Records the URL of the block explorer queried during the scan. Information item, never silent.
8. Software version. Records the version of BitcoinProof that generated the report. Information item.

The same eight items are presented in two forms within each report: a technical form for accountants and auditors who want to verify the mechanics, and a plain-language form for the recipient who needs to understand what the document represents without working through the technical detail.

Complete Entity Reports and Selected Descriptor Reports

One snapshot can be turned into more than one report. The snapshot itself is always complete: the engine scans every descriptor of the entity. At report generation, the user chooses which descriptors to include in the document.

• A Complete Entity Report includes every descriptor of the entity. It represents the entity's full Bitcoin position at the snapshot date.
• A Selected Descriptor Report includes only some of the entity's descriptors. The header of the report, every page thereafter, the assurance checklist, and the disclaimer all label the document as partial. A partial report must not be treated as a complete declaration of holdings.

The distinction is unmistakable on the face of the document. A recipient flipping to any page sees the report type immediately.

The valuation layer

The user enters a BTC price, a fiat currency, and a free-text source describing where the price was obtained (for example, "CoinGecko close, 1 January 2026" or "ESTV official rate, 31 December 2025"). The engine multiplies the price by the BTC total to produce the fiat-equivalent figure shown in the report.

BitcoinProof does not retrieve, validate, or independently verify any price, currency selection, or source. The fiat figure on the report is the user's input multiplied by the engine's reconstruction. Recipients who require an independent valuation should obtain one from a source they consider appropriate; this is particularly relevant for SMSF auditors, who under ATO guidance must obtain objective, supportable market-value evidence rather than rely on holding statements or summaries alone.

What the engine guarantees

This is the only affirmative guarantee the engine makes. Everything else — the prices, the descriptor correctness, the user's identity details, the auditor's onward use of the document — depends on inputs and processes outside the engine.

What the report is, and what it is not

A BitcoinProof report is software output: a deterministic reconstruction of public on-chain facts, presented in a structured PDF, generated locally on the user's computer.

It is not the output of a regulated financial service, accounting service, audit service, valuation service, or licensed financial intermediary. It does not constitute financial, tax, legal, accounting, or investment advice in any jurisdiction. In Australia, it is not financial product advice within the meaning of section 766B of the Corporations Act 2001 (Cth), and BitcoinProof does not hold an Australian Financial Services Licence. In the Netherlands it is not regulated by the AFM or DNB and BitcoinProof is not a crypto-asset service provider under MiCAR. Equivalent positions apply in Switzerland (FINMA / FinSA), Norway (Finanstilsynet) and Spain (CNMV).

The engine reconstructs on-chain transaction history. It does not verify identity, beneficial ownership, residency, or tax-identifier validity. Recipients with independent verification obligations must satisfy those obligations by other means.

Further reading

• Download a sample report — see exactly what a recipient receives.
• Read the full report disclaimer — the canonical statement of scope and limits.
• End User Licence Agreement — software licence terms.
• Terms of Service — purchase and website terms.
• Privacy Policy — how data is handled.