Proof of Reserves for Crypto Exchanges: How It Works and Why Regulators Want It

Introduction

When an exchange fails, customers learn the same thing at the same moment: the balance on their screen was a promise, not an asset. Proof of reserves (PoR) is the industry's attempt to show, before anything goes wrong, that the promise is backed. The exchange publishes evidence that it holds at least as much of each asset as it owes its customers, and each customer can check that their own balance was counted.

For a long time PoR was voluntary marketing. That is changing. Dubai's Virtual Assets Regulatory Authority (VARA) already requires 100% reserves, daily reconciliation and independent reserve audits. The UK's Financial Conduct Authority (FCA) has finalised custody rules built on daily reconciliation. And in October 2026 the US Commodity Futures Trading Commission (CFTC) asked whether exchanges holding customer assets in pooled accounts should have to prove their reserves.

This post explains how proof of reserves works, what it does and does not prove, what regulators are asking for, and what an exchange has to build to produce one it can stand behind. It is written for founders, CTOs and compliance leads who run or plan to launch an exchange. For the wider build, see our crypto exchange development guide.

What Proof of Reserves Actually Proves

A useful PoR answers two questions and compares the answers:

• Liabilities: how much of each asset does the exchange owe its customers right now?
• Assets: how much of each asset does the exchange provably control on-chain?

If assets are at least equal to liabilities for every asset, the exchange was solvent in those assets at that moment. The result is usually reported as a reserve ratio per asset. Kraken, for example, publishes ratios such as 102.9% for BTC and 100.5% for ETH in its June 2026 proof of reserves review.

Vitalik Buterin's 2022 essay Having a safe CEX: proof of solvency and beyond set out the logic most implementations still follow. If you prove both sides, "you've proven the exchange has the funds to pay back all of its depositors." Prove only the asset side, which is what many early "PoR" announcements did, and you have shown a wallet balance, not solvency. A large wallet means nothing if the exchange owes more than it holds.

Two details matter more than they first appear. The comparison has to be per asset, because 10,000 ETH does not cover a BTC liability. And it has to be at the same moment, because balances and wallets both move constantly.

How It Works, Step by Step

1. Take a snapshot of customer liabilities. At a fixed block height or timestamp, the exchange exports every customer's balance for each in-scope asset from its internal ledger. Most of the trust sits here: if accounts are left out of the export, only the affected customers can catch it.

2. Commit to the liabilities with a Merkle sum tree. Each customer becomes a leaf containing a hash of an anonymised account ID and their balances. In a Merkle sum tree, each parent node stores the hash of its children and the sum of their balances, so the root carries both a fingerprint of every balance and the total owed. Buterin's essay explains why the sum matters: it stops an operator hiding a fake negative balance that quietly reduces the total, because any invalid node breaks verification for everyone above it.

3. Prove control of on-chain assets. The exchange shows it controls the addresses holding its reserves, usually by signing a message with each address's key or by moving a small amount on-chain at an agreed time. Bitcoin's BIP-322 defines a standard signed-message format, including a "proof of funds" variant over a set of UTXOs. Even that standard is careful about its limits: the list "does not aim to prove completeness," and the specification states that "no message signing protocol can actually prove control of funds" in the full sense, because a key can be shared.

4. Compare, per asset. Total on-chain holdings for each asset are compared with the liability total from the tree's root. The reserve ratio is published, usually with the Merkle root and the list of proven addresses.

5. Let every customer check their own leaf. Each customer receives a leaf ID and the sibling hashes needed to rebuild the path to the published root. Kraken's verification flow lets a customer enter part of their Merkle leaf ID into the accountant's or Kraken's tool, and lets technical users recompute the leaf and path in their own code. If enough customers check, an omitted or understated account is likely to be noticed.

Merkle Trees or Zero-Knowledge Proofs?

A plain Merkle sum tree has two weaknesses. It leaks information, because the sibling sums a customer receives reveal something about other accounts. And it relies on customers or an auditor to notice problems in the leaves.

Zero-knowledge proofs address both. Binance's zk-SNARK proof of reserves commits all balances to a Merkle tree and then proves, for every leaf, that each balance is included in the published asset totals, that "the user's total net balance is not negative," and that the root was updated correctly. Customers verify their own inclusion plus one succinct proof that every account satisfied those rules, without seeing anyone else's numbers. Binance open-sourced the prover, circuit and verifier on GitHub.

The negative-balance rule is the subtle part. On a spot-only exchange, no customer should ever owe the exchange an asset. Once you offer margin, loans or futures, individual asset balances can be negative by design, so the rule has to be "total net position is not negative, given collateral," not "every number is positive." Getting that rule right for your product set is engineering work, not a reporting exercise.

For most new exchanges, a well-run Merkle sum tree with an independent practitioner and a public verification tool is the sensible starting point. Zero-knowledge proofs are worth the extra build and audit effort once the user base is large, privacy concerns are real, or the product mix includes leverage.

What Proof of Reserves Does Not Prove

PoR is evidence, not a guarantee. In March 2023 the US Public Company Accounting Oversight Board (PCAOB) issued an investor advisory warning that PoR engagements do not provide "meaningful assurance." Its main points apply to any PoR design:

• It is a point in time. Assets can be lent, moved or lost the day after the snapshot.
• Liabilities may be incomplete. Procedures often do not cover all of the entity's obligations, such as loans or other creditors.
• Reserves may be borrowed. A report may not show that the "reserves" were borrowed for the snapshot.
• No view of controls or governance. PoR says nothing about who can move funds or how decisions are made.
• No common standard. Scope, procedures and assurance levels vary by provider.

Kraken's own page lists similar limits: a review proves control at a point in time but cannot prove exclusive possession of keys, find hidden encumbrances, or detect losses after the snapshot. And in December 2022 the accounting firm Mazars paused its PoR work for crypto clients, including Binance, KuCoin and Crypto.com, citing "concerns regarding the way these reports are understood by the public," as CNBC reported.

None of this makes PoR worthless. A snapshot report is the floor, and regulators are now building on it.

Why Regulators Want It, and What They Are Asking For

Dubai. VARA's Company Rulebook requires licensed providers to "maintain reserve assets equivalent to one hundred percent (100%) of the liabilities owed to clients," held one-to-one "in the same Virtual Asset," reconciled daily, and audited by an independent third party "no less than every six (6) months." On 6 October 2026 VARA issued a circular on reserve asset audit reports after reviewing 2025 reports. Auditors must now confirm reserves stayed at or above 100% "throughout the review period," not just on one day; cover every hot, warm and cold wallet and third-party custodian; report any lending or pledging of client assets; and not treat "management representations alone" as sufficient evidence. Our Dubai crypto exchange development team works with exchanges preparing for this regime.

United Kingdom. The FCA published its cryptoasset regime policy statements on 30 June 2026, with the full regime taking effect on 25 October 2027. Client cryptoassets come under a new CASS 17 sourcebook, which the FCA describes as enhanced protections around "ownership rights, record‑keeping, reconciliation, and private key management." The consultation behind it proposed that custodians reconcile "every business day," fix shortfalls, and keep client records that are not supplemented by blockchain data, as Linklaters summarised. The UK route is less about a public report and more about a daily internal process that an auditor can test.

United States. On 5 October 2026 the CFTC released an advance notice on Regulation Crypto Asset Transactions and Regulation Crypto Asset Markets, with comments due 14 December 2026. Among its questions, the CFTC asks whether crypto asset markets that hold customer assets in omnibus accounts should show their reserves sufficiently cover customer liabilities, through third-party attestations or blockchain-based verification (National Law Review). It is a question, not a rule, but it signals where US expectations are heading.

The common thread: regulators are moving from "publish a snapshot" to "reconcile every day, keep reserves at 100% in kind, and let an independent party test the whole period." An exchange designed only for an annual marketing report will struggle to meet that.

What an Exchange Needs to Build

Proof of reserves is mostly a by-product of good ledger and wallet design. If the foundations are right, producing a report is a few days' work. If they are not, no report will fix them. The pieces that matter:

• One authoritative ledger. Every customer balance, fee, pending withdrawal and internal transfer must come from a double-entry ledger that can produce a consistent snapshot at a chosen time. Liabilities scattered across product databases (spot, earn, futures, P2P escrow) are the most common reason a PoR takes months.
• A complete wallet inventory. List every address across hot, warm and cold tiers, plus balances held with third-party custodians or other venues, with the owner and purpose of each. VARA's circular now expects auditors to cover all of them.
• Address ownership proofs on demand. Build the signing step into your custody setup in advance, so cold and multi-party keys can sign a challenge message without an emergency key ceremony.
• Daily per-asset reconciliation. Compare ledger liabilities with on-chain and custodian balances every day, per asset, with tolerances and an exceptions queue that a person must clear. This is what UK and Dubai rules actually test.
• Clear scope rules. Decide and document what counts as a liability (staked assets, assets in open orders, unsettled withdrawals) and what counts as a reserve. Exclude the exchange's own funds from reserves and say so.
• Privacy-safe customer verification. Salted, anonymised leaf IDs, a simple "verify my balance" page, and open-source verification code so technical users and journalists can check the maths.
• Encumbrance controls. If customer assets must not be lent or pledged without consent, enforce that in the wallet policy engine, not just in a policy document, and log every movement out of client wallets.

Liquidity arrangements belong in scope too. Pre-funding on external venues or assets lent to market makers are real reserves only if they are recorded and provable. Our liquidity provider integration guide covers how those flows are set up.

How We Approach It

At iTech Soft Solutions we have built exchange software since 2016, including our TradiumPro platform, which runs CryptoWag and Xoibit, and TradexPro, our white-label exchange with 415 sales on CodeCanyon. On exchange projects we treat the ledger and the wallet layer as the foundation for reporting: one source of truth for customer balances, per-asset reconciliation against hot and cold wallets, and an audit trail that an independent practitioner can follow. Where a client needs a public PoR, we add the Merkle snapshot export and a customer verification page on top. If you are planning for VARA or the UK regime, our crypto exchange development team can review your ledger and custody design against these rules. For budgeting, see our cost to build a crypto exchange guide, and for the build-or-license decision, our white-label exchange buyer's guide.

Frequently Asked Questions

Is proof of reserves the same as an audit? No. Most PoR reports are agreed-upon procedures or limited engagements on one date, and the PCAOB warns they do not give meaningful assurance. A financial statement audit tests all assets, liabilities and controls over a period. Regimes such as VARA's are closing the gap by requiring independent reserve audits across a full review period.

Can proof of reserves cover fiat balances? Not cryptographically. On-chain assets can be proven with signatures, but fiat held in banks needs bank confirmations and an auditor. Many exchanges limit their published PoR to major crypto assets and stablecoins and say so in the scope.

How often should an exchange publish proof of reserves? Regulators care more about daily reconciliation than about how often a report is published. A practical pattern is daily internal reconciliation, an independent review at least every six months (VARA's minimum), and a public report with customer verification on a fixed cadence, such as quarterly.

Do zero-knowledge proofs make PoR trustless? They make the liability side private and verifiable, including a proof that no account has a hidden negative balance. They do not prove the snapshot included every account, that reserves were not borrowed, or that funds stayed after the snapshot.

Final Thoughts

Proof of reserves started as a reaction to exchange failures and is becoming part of how exchanges are licensed. The snapshot report is the visible part. The part that regulators and serious customers now test is underneath it: a single ledger, a complete wallet inventory, daily reconciliation per asset and independent checks across the whole period. Build those in from the start and a credible PoR becomes routine reporting rather than an emergency project.

If you are launching or upgrading an exchange and want the ledger, custody and reporting layer designed for VARA, the FCA or a public PoR, contact us to talk it through with our exchange team.