BitcoinDatabase.com
How it works
Bitcoin API Block explorer API Address lookup Historical data API On-chain data Transaction API Bitcoin data API Wallet tracker On-chain metrics Rich list Address balance API Query with SQL Crypto AML API UTXO data Blockchain API Flow analysis Node API Webhook API Price API Transaction monitoring Mempool API RPC API xpub balance API See all →
Glassnode alternative Dune alternative Blockchair alternative Chainalysis alternative BlockCypher alternative Chainstack alternative Blockchain.com API alternative Mempool.space alternative CoinAPI alternative TRM Labs alternative Whale Alert alternative CoinGecko alternative CoinMarketCap alternative Blockdaemon alternative Xverse alternative BigQuery alternative Bitquery alternative TimechainIndex alternative CryptoQuant alternative Alchemy alternative QuickNode alternative Hiro alternative Amberdata alternative Elliptic alternative Merkle Science alternative Coin Metrics alternative CoinGlass alternative Crypto APIs alternative Tatum alternative NOWNodes alternative GetBlock alternative Arkham Intelligence alternative Santiment alternative Nansen alternative Allium alternative Flipside alternative SonarX alternative GoldRush alternative Scorechain alternative AMLBot alternative
Docs Pricing Blog Contact Sign in

Query the chain · Audit trail

Bitcoin audit trail API for crypto audit evidence

A Bitcoin audit trail API gives auditors a period-end balance pinned to a block height plus every movement that produced it, so opening balance, additions and disposals roll forward to the closing balance to the satoshi.

or try it below ↓

REST API · SQL · dashboards · address history from genesis

Query Console
btc
try:

Hit Run to query the Bitcoin blockchain.

Live from the chain for .

BTC

Balance trail

informational on-chain data · not financial advice

REST API · SQL · dashboards, one indexed dataset. Reading the chain ...

The first thing an audit of bitcoin holdings needs is a cutoff, and the calendar does not give you one. We looked up the last block before midnight on 31 December 2025. In UTC it is block 930,340, stamped 23:59:58. In Pacific time it is block 930,389, which means 49 more blocks and 147,438 more transactions sit inside the year for a company that closes its books on the West Coast. Eastern time is worse than either, because it is ambiguous: a timestamp lookup returns block 930,371, stamped 04:57:51 UTC, yet blocks 930,372 and 930,373 are both stamped before midnight Eastern too. Block 930,372 carries a timestamp 273 seconds earlier than the block it follows. Bitcoin only requires a timestamp to beat the median of the previous eleven blocks, so this is legal, and it leaves two blocks and 8,821 transactions whose fiscal year depends on which rule you picked. A defensible audit file states the rule and the height, not just the date.

The second thing is a rollforward that closes. On 21 September 2026 we rolled one large custodial cold address, 3M219KR5vEneNb47ewrPfWyb5jQ2DjxRP6, from block 967,238 to block 968,066. Opening balance 224,683.07908858 BTC. Three confirmed receipts: 5,151.775 BTC at block 967,458, a 1,281-satoshi dust payment at block 967,546, and 4,885.103 BTC at block 967,898. Closing balance 234,719.95710139 BTC. Opening plus the three receipts equals the closing figure exactly, and two independent explorers returned the same closing balance to the satoshi. A 546-satoshi payment was still unconfirmed at the read and is correctly excluded, which is the kind of item that shows up as a difference if you screenshot an explorer instead of querying at a height.

That is the shape ASU 2023-08 asks for. For annual periods beginning after 15 December 2024, US companies measure crypto assets at fair value through net income and disclose, for significant holdings, the name, cost basis, fair value and number of units, plus an annual rollforward of activity. The units and the movements come from the chain; the fair value comes from a stated price source at the same cutoff. We supply the first half as queryable data and the market data to value it: height-pinned balances and rollforwards over SQL across the indexed chain, which grows with every new block, from the Growth plan, and current balances and transaction lists over REST on every plan. This is on-chain data for your working papers, not accounting, audit or legal advice.

REST API SQL DASHBOARDS WEBHOOKS CSV EXPORT

History from genesis queryable in seconds

On-chain data not financial advice

Why it works

What you get with Audit trail

Cutoff by height, not by date

Name the block that closes the period in your own time zone and every figure in the file inherits it. Year-end 2025 lands on block 930,340 in UTC and block 930,389 in Pacific time, 147,438 transactions apart, so the date alone does not identify a balance. The 30 September 2026 quarter end lands on 969,369 in UTC, 969,391 in Eastern and 969,409 in Pacific time.

A rollforward that ties out

Opening balance, each receipt and disposal with its transaction and block, then the closing balance. Because the flow and the balance are computed independently, a file that ties is a check in itself, and a file that does not tells you exactly where to look.

Evidence anyone can rerun

Every number carries the address list and the height it was measured at. An auditor who reruns the query lands on the same satoshi, which turns a client-prepared schedule into something the engagement team can test independently.

Side by side

Ways to evidence a bitcoin balance for an audit

What each approach can and cannot produce for a period-end file. Measured behavior is from our own tests of public endpoints in August and September 2026.

Approach Balance at a past block Rollforward of movements Cost model Best for
BitcoinDatabase Yes, over SQL within the indexed chain, full address history over REST Yes, every input and output with its block SQL from $199/mo (Growth) Audit files that must reproduce to the satoshi
Explorer screenshot No, shows today only Manual, page by page Free, paid in staff hours A single wallet with a handful of movements
Public explorer API No, height parameter ignored in our tests Yes, but you fold it yourself Free, no uptime commitment Spot checks during fieldwork
BigQuery public dataset Yes, with your own SQL Yes, with your own SQL $6.25 per TiB scanned Teams already running BigQuery
Bitquery Yes, through GraphQL Yes, through GraphQL From $79/mo for commercial use Firms auditing several chains at once
Own full node Not by address, the UTXO set is current only Only with an indexer you build Roughly $390 to $430/mo on AWS Firms that must control every byte

An explorer screenshot is not wrong, it is just unreproducible: it records the balance at the moment someone pressed print, which is rarely the cutoff block, and it silently includes or excludes unconfirmed payments depending on the site. SQL starts on the Growth plan and runs over the indexed chain, which grows with every new block; the Developer plan carries one year of history over REST.

What it handles

The indexed Bitcoin chain, queryable your way

Look up an address, a transaction, a UTXO, the rich list or an on-chain metric, by REST API, SQL or dashboard. The same authoritative data, reconciled block-by-block against the canonical chain, without running a node.

  • Resolve the cutoff block for any date and time zone
  • Pull period-end balances for a whole address list at one height
  • Produce an opening-to-closing rollforward per address
  • List every receipt and disposal with txid, block and fee
  • Separate confirmed activity from unconfirmed payments
  • Attach a fair value from market data at the same cutoff
  • Export schedules as CSV for the working papers
GET /v1/address/{addr} query result
200 · JSON 
{
  "address": "bc1qxy2k…l0wdv8",
  "balance_btc": 68432.10,
  "balance_usd": 4612165420,
  "tx_count": 1284,
  "unspent_outputs": 37,
  "first_seen": "2014-02-09"
}
indexed from genesis · to the satoshi ✓ reconciled block-by-block

Why BitcoinDatabase

One platform, queryable three ways

Not a raw node to sync, not an indexer to build, and not five vendors to stitch together. The fully-indexed Bitcoin blockchain, available as a REST API, as SQL, and as dashboards, on one authoritative dataset.

REST API

Typed JSON for addresses, transactions, balances, UTXOs and metrics. Drop it into apps, wallets, explorers and agents with curl, Python or any HTTP client.

SQL access

Run SQL directly against the indexed Bitcoin dataset for ad-hoc analysis, cohorts and exports, the same data the API and dashboards read from.

Compliance-first

Informational on-chain data and analytics only. Entity labels and flow tracing are framed as tooling to support a regulated team's own review, not accusations.

Good questions

Questions about Audit trail

Auditors test existence by agreeing the client's reported units to the blockchain at the period-end cutoff, and test ownership separately, usually by having the client sign a message or move a small amount from the address. The blockchain half is a balance query at a named block height, repeated independently by the audit team so they do not rely on a client screenshot.
List every address the wallet controls, pick the cutoff block for the period end in the reporting time zone, and query each address balance at that height. Then roll each one forward from the prior period: opening balance plus receipts minus disposals should equal the closing balance exactly. Any difference points to a missing address or a movement recorded in the wrong period.
It is strong evidence of existence and of movements, because it is external to the client and anyone can reproduce it. It says nothing about who controls the keys, so it has to be paired with ownership evidence, and it is only as good as the address list the client provided, which is why completeness of that list gets its own procedures.
It is the chain of recorded movements that explains a balance: every transaction in and out of an address, each fixed to the block that confirmed it. On Bitcoin that trail is public and permanent, but it is not arranged by address or by accounting period, so turning it into a rollforward takes an index built for that query.
The last block mined before midnight in your reporting time zone, which differs by time zone. For 31 December 2025 it is block 930,340 in UTC and block 930,389 in Pacific time. In Eastern time a timestamp lookup and a highest-height rule disagree by two blocks, so state the rule you used alongside the height.
Block 969,369 in UTC, stamped 23:59:38, then a 40 minute gap to the next block. In Eastern time it is block 969,391, 22 blocks and 95,816 transactions later, and in Pacific time block 969,409, 40 blocks and 179,384 transactions after UTC. Unlike year end 2025, no timestamp near any of the three midnights ran backwards, so each cutoff is unambiguous.
Because the protocol only requires a block timestamp to be later than the median of the previous eleven blocks, not later than the block right before it. At the 2025 year end, block 930,372 is stamped 273 seconds earlier than block 930,371. Sorting by timestamp instead of height can therefore put a transaction in the wrong period.
For annual periods beginning after 15 December 2024, ASU 2023-08 requires in-scope crypto assets to be measured at fair value with changes in net income. Disclosures include the name, cost basis, fair value and units of each significant holding and an annual rollforward of activity. The units and the rollforward are the parts that come straight from the chain.
Yes. Pass the address list with an opening and a closing height and you get opening balance, receipts, disposals and closing balance per address, with the transactions behind each line. Over SQL the same query runs across the indexed chain, which grows with every new block, and on the Scale plan the result exports as CSV for the working papers.
No. A payment sitting in the mempool at the cutoff is not in any block and can still be replaced or dropped, so it belongs to whichever period it eventually confirms in. Explorers often display unconfirmed amounts next to the balance, which is one reason a screenshot and a height-pinned query can disagree.
Read every Bitcoin API question

Explore more

More ways to query Bitcoin with BitcoinDatabase

BTC address balance API

Get exact balances and UTXOs for any address, in batches.

Learn more

Bitcoin address balance history API

What an address held on any past date, not just what it holds now.

Learn more

On-chain metrics

Active addresses, realized cap, SOPR, HODL waves and exchange flows.

Learn more

Bitcoin block explorer API

Power an explorer with blocks, transactions and addresses, no node to maintain.

Learn more

Bitcoin address lookup

Look up any Bitcoin address: balance, full history and UTXOs in one query.

Learn more

Bitcoin historical data API

Full-depth history: every block, transaction and metric back to 2009.

Learn more
See every use case See pricing Back to the Bitcoin API

Stop running a node. Just query Bitcoin.

Run your first query now and get on-chain data back by REST API, SQL or dashboard, with address history back to the genesis block over REST. Informational on-chain data only, not financial advice.

See pricing

History from genesis over REST · SQL · dashboards · addresses, transactions, UTXOs, metrics