BitcoinDatabase.com

Compliance & flows · Proof of reserves API

Bitcoin proof of reserves API for reserve address balances and attestation data

Proof of reserves comes down to one question a reader can check: do the addresses an exchange or custodian claims actually hold the balances they say they hold, at a stated block height? The Bitcoin proof of reserves API answers the on-chain half of that. Feed it a list of reserve addresses or extended public keys and get balances to the satoshi, UTXO counts, first and last activity, and a balance snapshot pinned to a specific block, so an attestation can be reproduced by anyone who repeats the query.

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 liability side of proof of reserves (customer balances, usually committed to a Merkle root or a zero-knowledge proof) stays with the exchange and its auditor. What we supply is the asset side: an independent, fully-indexed view of the chain that an auditor, a counterparty or your own risk team can query over REST or SQL without running a node. This is informational on-chain data, not an audit opinion, an attestation, or financial 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 Proof of reserves API

Balances pinned to a block height

A reserve claim is only checkable if everyone agrees on when it was true. Query any address set as of a specific block height and get the same balances back every time, which is what makes an attestation reproducible.

Whole wallets, not just single addresses

Reserve wallets are rarely one address. Submit an extended public key or a list of thousands of addresses and get the aggregate balance, per-address detail and UTXO counts in one pass.

Independent of the entity being checked

The data is read from the public chain by us, so an auditor or counterparty is not reading numbers supplied by the party making the claim.

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.

  • Total a published reserve address list to the satoshi
  • Snapshot reserve balances at a fixed block height
  • Expand an xpub into its derived addresses and balance
  • Track reserve wallet inflows and outflows over time
  • Flag reserve addresses that moved between attestations
  • Export the underlying rows for an auditor workpaper
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 Proof of reserves API

Proof of reserves is a check that a custodian holds enough assets to cover what customers are owed. It has two halves: the reserves side, which is on-chain balances at addresses the custodian controls, and the liabilities side, which is customer balances usually committed to a Merkle root or a zero-knowledge proof. Our API covers the on-chain reserves side.
No. Control is proven by a signed message from the address key or a movement of funds the custodian arranges, both of which happen outside our system. We verify what the address holds and how it has moved, which is the part anyone can independently check on-chain.
No, and the difference is who supplies the address list. An exchange reserve estimate is built by outsiders inferring which addresses an exchange controls, so it can be wrong and nobody can audit it. A proof of reserves has the exchange itself name the addresses and prove control cryptographically. One is inference, the other is an assertion backed by a signature.
No. A reserve proof shows assets held, not what is owed against them. Proving control of 100,000 BTC says nothing about whether customer liabilities total 150,000 BTC. That is why a credible attestation pairs the asset proof with a liability commitment, usually a Merkle root customers can check their own balance against. Reserves alone are half the equation.
Because balances change every block, so a claim without a height is unfalsifiable. Pinning the query to a stated height means an auditor, a counterparty and the exchange all compute the same number from the same public data, and anyone repeating the query later gets the identical result. Without it, two honest parties checking hours apart will disagree and neither can show why.
Yes, and it is the cheapest due diligence there is. Take the addresses the custodian published, total them at a fixed height, and compare against the figure they claim. The work is only awkward at scale, since reserve wallets run to thousands of addresses. Submitting the whole list or an extended public key in one pass is what makes this a query rather than a crawl.
Because the estimate counts an address list, and coins moving onto that list look like inflows even when they come from the same operator. Between 16 and 21 September 2026 five widely tracked exchange cold addresses rose 10,036.88 BTC. Two sweeps from one untracked hot wallet explained all of it except 15,066 satoshis of dust. A reserve proof built on a named address list avoids that ambiguity.
Four things: the full address list or extended public key, the block height the claim is made at, proof of control such as a signed message for each address, and a commitment to customer liabilities, usually a Merkle root. With the list and the height, anyone can total the balances independently and check the figure lands on the same satoshi.
On our side, totalling a large address set at a past block height runs on SQL over the indexed chain, which grows with every new block. SQL starts on the Growth plan at $199 a month. Scale, at $799 a month, adds bulk CSV exports for handing the per-address detail to an audit team, plus webhooks if you want to be told when a reserve address moves between attestations.

Explore more

More ways to query Bitcoin with BitcoinDatabase

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