Key takeaways
- Proof of reserves compares the assets an exchange can show it controls with the balances it owes clients, at one moment in time.
- A full proof has 2 halves: a proof of assets and a proof of liabilities. Vitalik Buterin's essay of 19 November 2022 calls the pair a proof of solvency.
- A Merkle tree lets each client check that their own balance was counted. A zero-knowledge proof does it without exposing anyone else's balance.
- It is not a financial audit. Loans, pledged assets, bank balances and anything after the snapshot are outside it.
- In Dubai, VARA requires reserve assets equal to 100% of client liabilities, reconciled daily and audited at least every six months.
- Backpack states that it publishes a proof every day and names OtterSec as verifier. This guide quotes no reserve figure, because the live reserves page carries none in its server HTML.
For information only. Not investment advice.
Proof of reserves in one paragraph
Proof of reserves (PoR) is a report an exchange publishes to show that the assets it controls cover the balances it owes clients. It answers one narrow question: if every client had asked for their coins at the moment of the snapshot, were the coins there? A complete proof has two halves. A proof of assets shows which wallets the exchange controls. A proof of liabilities shows the total it owes, in a form each client can check.
Five terms carry most of the meaning. Fuller definitions are under Merkle tree and zero-knowledge proof in the glossary, and there are more guides on Backpack Learn.
- Reserves
- The assets an exchange holds to meet client balances.
- Liabilities
- What the exchange owes: the sum of all client balances.
- Reserve ratio
- Reserves divided by liabilities. At 100% the two are equal.
- Snapshot
- The date and time at which balances were recorded.
- Merkle root
- One short value that commits the exchange to a full list of balances.
Why exchanges publish it: November 2022
The question behind proof of reserves became urgent when the exchange FTX failed in November 2022. On 13 December 2022 the US Commodity Futures Trading Commission filed a complaint against FTX, the trading firm Alameda Research and the founder who controlled both. According to the CFTC's release on the FTX complaint, FTX had told customers that their assets were held in custody and kept apart from its own, while customer assets were routinely held by Alameda and mixed with its funds. The complaint put the loss of customer deposits at more than $8 billion. These are the regulator's allegations as filed.
A balance on a screen is a database entry, and only the exchange knows whether coins stand behind it. On 19 November 2022 Vitalik Buterin published the essay Having a safe CEX: proof of solvency and beyond, which sets out how an exchange can prove it with cryptography, in addition to licences and auditors.
The idea is older. The essay traces it to 2011, when the exchange Mt. Gox moved 424,242 bitcoin to an address announced in advance, and to 2013, when developers began to discuss how to prove the total owed to customers.
Backpack has a first-hand reason to care. The timeline on its About page records that in November 2022 the company lost 88% of its corporate treasury on FTX. Backpack Exchange was incorporated in March 2023, four months later: see Backpack company history and legal entities.
How proof of reserves works
A proof of reserves works by proving two totals separately, assets and liabilities, and then comparing them. Buterin's essay names the halves: show that client balances add up to a figure X (a proof of liabilities), show control of the private keys for X coins (a proof of assets), and together you have a proof of solvency. The assets half can be read from a public blockchain. The liabilities half is harder, because only the exchange holds the balance list.
Proving assets: wallet ownership
An exchange proves its assets by showing that it controls the private keys of named blockchain addresses. The essay lists the simple ways: move the coins at a time agreed in advance, send a transaction that names the owner, or sign a message off-chain so that no fee is paid. Anyone can then read the balances of those addresses on the public ledger and add them up.
Two problems follow. Most client funds sit in cold storage, on machines kept offline, so every extra signature is costly. And control at one moment is not ownership: two exchanges could pass the same coins back and forth so that each looks funded on its own snapshot day, which the essay calls collateral dual-use. Money in bank accounts cannot be proven this way at all; there a reader depends on banks and auditors.
Proving liabilities: Merkle trees
A Merkle tree compresses the whole list of client balances into one short value, the root, which the exchange publishes. In the definition given in the IETF's Certificate Transparency specification, each node is computed from the two nodes directly below it, and a short list of neighbouring nodes, called an audit path, is enough to show that one entry belongs to the tree (RFC 6962, section 2.1).
For balances, the essay describes a variant called a Merkle sum tree. Each leaf holds one client's balance and a hash of their account name mixed with a random value, so the leaf does not identify them. Each node above holds the sum of the two balances below it and a hash of both. The root therefore carries the total owed to all clients.
Here is an illustrative tree with four accounts. The numbers are invented for this guide and are not data from any exchange. Accounts A, B, C and D hold 3, 5, 2 and 6 BTC. A and B combine into a node of 8 BTC, C and D into another of 8 BTC, and the root shows 16 BTC owed in total. The client behind account C receives two nodes from the exchange: D's leaf of 6 BTC and the A+B node of 8 BTC. She recomputes 2 + 6 = 8, then 8 + 8 = 16, hashing at each step, and compares the result with the published root. If they match, her 2 BTC was counted.
The sums matter as much as the hashes. An exchange short of funds could try to hide the gap with a fake account that has a negative balance. In a sum tree every client rejects a node below zero, so the trick fails unless nobody on that side of the tree checks. The scheme is as strong as the number of clients who verify. It also leaks a little: in the example, the holder of account C learns that some account holds 6 BTC.
Set against the assets shown on-chain, the root gives the reserve ratio.
| Scenario | Assets | Ratio |
|---|---|---|
| Covered exactly | 16 BTC | 100% |
| Covered with a buffer | 17 BTC | 106.25% |
| Short by 2 BTC | 14 BTC | 87.5% |
A ratio under 100% means that some client balances were not covered at the snapshot. A ratio above it shows a buffer on that day and nothing about the next.
Zero-knowledge proofs: proving the total without exposing balances
A zero-knowledge proof lets an exchange prove that its balance list adds up without showing any balance to anyone else. In general terms it is a way to prove that a statement is true without revealing the information behind it; the party making the claim is the prover and the party checking it is the verifier (ethereum.org documentation on zero-knowledge proofs).
Applied to reserves, the exchange commits to all balances in a Merkle tree or a similar structure. It then attaches a proof, of a type the essay calls a ZK-SNARK, that every balance is zero or more and that together they equal the published total. Each client still receives a branch to check their own inclusion, and with an added layer of hashing that branch reveals nothing about other accounts.
The technique reaches beyond spot balances. With leverage, one balance can be negative as long as the client's other assets cover it with a margin. The essay notes that a proof can encode that rule too, so that no account is quietly exempted. See how margin positions in perpetual futures work.
Reserves and solvency: what a proof does not show
A proof of reserves shows that named assets covered a published list of client balances at one moment; solvency is a wider question. Strictly, the word reserves describes only the assets half, and a page that lists wallets without a liabilities proof tells a reader little. When both halves are published, the result is what Buterin's essay calls a proof of solvency; its conclusion uses the name proof of reserve for the same combination. Even then, five limits remain.
- It is a snapshot. Assets can be borrowed before the snapshot and handed back afterwards.
- Debts outside the client list are invisible. Loans, unpaid bills, tax and the debts of related companies are not client balances, so they are not in the tree.
- Control is not free ownership. A signature proves that the exchange holds the keys. It does not show whether the coins are pledged to someone else.
- Asset quality is not measured. A proof counts units. It does not say whether a large holding of a thinly traded token could be sold at its quoted price.
- Missing accounts go unnoticed unless clients check. Leaving out accounts whose owners never verify lowers the published total.
What a proof does not show
The company's other debts, whether the assets are pledged, what happened after the snapshot and whether prices will hold. A proof addresses one risk, that client coins are missing, and leaves market risk untouched.
So can a proof be faked? The hashes and signatures are hard to forge; the weak points are the inputs. The date, the verifier and the scope matter as much as the mathematics.
Scope matters most where client assets are put to work. When clients lend assets through an exchange, those balances become claims on borrowers, and a reader should ask whether the proof counts them: see lending and borrowing rates and risks.
Proof of reserves, attestation and financial audit compared
A proof of reserves is not an audit, and an attestation sits between the two. The three differ in who does the work, how much of the company they cover and what a reader can check personally. The table gives the usual form of each; the scope of any single report is defined in the report itself.
| Question | Proof of reserves | Attestation | Financial audit |
|---|---|---|---|
| Performed by | The exchange, using published cryptography, sometimes with a named outside verifier | An accounting or security firm engaged by the exchange | An independent audit firm working to auditing standards |
| What is checked | On-chain assets against the list of client balances | Specific items on a specific date, as agreed with the exchange | The full financial statements: all assets, all debts, income and cash flows |
| How often | Whatever the exchange chooses, from daily to occasional | Periodic, on the schedule the exchange agrees | Usually once a year |
| What you can verify | That your own balance is in the total, and the balances of the published wallets | Nothing directly. You read the firm's report | Nothing directly. You read the auditor's opinion |
| Main limit | A snapshot of client balances only | Limited to the agreed procedures and date | Slow, and months old when published |
Regulators lean on the older tools. Dubai's Virtual Assets Regulatory Authority requires the firms it licenses to hold reserve assets equal to 100% of what they owe clients, in the same virtual asset, to reconcile them every day and to have them audited by an independent third party at least every six months (VARA Company Rulebook, Part VI, Reserve Assets, in effect since 19 June 2025). In the European Union, the Markets in Crypto-Assets Regulation requires custodians to keep client crypto-assets apart from their own and to send each client a statement of position at least once every three months (MiCA, Article 75). Neither provision mentions a public cryptographic proof. To see which rules apply to a company, start with how to check an exchange licence on a register.
How to verify an exchange proof of reserves in five steps
Verifying a proof takes five checks, and only the last one involves cryptography. They work on any exchange.
- Find the proof page. Look for a reserves page on the exchange's own domain, linked from its footer or its security page.
- Check the date and the cadence. Read the date and time of the latest proof and how often a new one appears. A proof from months ago says little about today.
- Identify the verifier. Note who checked the proof: the exchange alone, a security firm or an accounting firm. Look for the verifier's own dated statement. A logo without a report is a claim, not evidence.
- Check which liabilities are included. Read the scope note. Does the total cover spot balances only, or also margin positions, unrealised profit and loss, lent assets and cash? Are the reserves held in the same assets that clients are owed?
- Verify your own inclusion. Fetch your leaf and its path, then recompute the root, preferably with open-source code that runs on your own device. Compare it with the published root, and the balance in your leaf with your account balance at the snapshot.
If the fifth step fails, or the exchange offers no way to perform it, the proof rests on trust in the exchange and its verifier.
How often should a proof be published?
The more often a proof is published, the less time there is to borrow assets for a single snapshot. Buterin's essay sets the ideal at real time, with a proof that updates after every block. Its second choice is a fixed schedule that exchanges share, so that the same coins cannot be shown by two of them on different days.
No rule read for this guide sets a publishing schedule for cryptographic proofs. The nearest benchmarks are the two provisions above: daily reconciliation and a six-monthly audit in Dubai, and a three-monthly client statement in the European Union. Those are floors for a firm's records and reports, not for public proofs.
Backpack's cadence is the one data point this guide can report. Its Learn article states that the proof is published every day, with internal reconciliation every 10 minutes. The same article says that most exchanges publish monthly; this guide did not check other exchanges, so it does not repeat that as a finding.
Worked example: the Backpack daily proof
Backpack states that it publishes a proof of reserves every day and names OtterSec as the independent verifier. The statements below come from the Backpack Learn article on exchange security and from the Backpack home page, both read on 6 October 2026. Here they are run through the five steps.
- The proof page. The reserves page of the main site, backpack.exchange/reserves. The home page describes it as a way to track assets and liabilities in real time.
- Date and cadence. Daily, by Backpack's statement, with internal reconciliation every 10 minutes. The date of the latest proof could not be read: the server HTML of the reserves page carried a title and no figures, because the numbers load in the browser.
- The verifier. OtterSec, whose own website describes a firm that performs security audits for blockchain projects. No OtterSec report, scope statement or date for a specific day's proof was found in the sources read.
- Liabilities included. Spot balances, margin positions and unrealised PnL, according to Backpack. Its article says the system uses zero-knowledge proofs to confirm that total user balances match on-chain holdings without exposing individual accounts. Lent balances and cash are not mentioned.
- Your own inclusion. Backpack's article says that any user can confirm on the reserves page that their account is included. The steps are not documented in the pages read.
The same article says that client assets are kept apart from the platform's own. The cadence and scope that Backpack describes go beyond a spot-only snapshot, but a reader can test them only inside the live reserves page. Until the report link, the latest ratio and date, and the inclusion steps are published as text that loads without scripts, this guide records them as Backpack's statements. The current list of what is published is kept with the Backpack daily proof of reserves and security facts.
Check the Backpack proof against the five steps
The security page lists what is published each day, who is named as verifier and which facts Backpack has not yet published.
Questions to ask any exchange
Eight questions cover what a proof of reserves can and cannot tell you about an exchange. Published answers to all eight are worth more than a badge on a home page.
- When was the latest proof published, and how often is a new one issued?
- Who verified it, and where is the verifier's own dated statement?
- Does it prove liabilities as well as assets?
- Which balances are in the liabilities total: spot, margin, unrealised profit and loss, lent assets, cash?
- Are reserves held in the same assets that clients are owed, or valued in something else?
- Can I verify my own inclusion, with code I can inspect?
- Are any reserve assets borrowed, pledged or issued by the exchange itself?
- Which company holds my assets, who supervises it, and are client assets kept apart from the company's own?
The last question applies to anything held on your behalf, not only coins. The stocks guide looks at it from the other side: how ownership of tokenized stocks is recorded.
Frequently asked questions
Is proof of reserves the same as an audit?
No. A proof of reserves checks one thing at one moment: whether the assets an exchange can show it controls cover the client balances it has published. A financial statement audit examines the whole company, including loans, costs, controls and bank accounts, over a full reporting period. Clients can check a proof themselves. An audit is read, not re-run.
Can proof of reserves be faked?
The mathematics is hard to forge, but the inputs can be gamed. An exchange could borrow assets for the snapshot, leave out accounts that are unlikely to check, or owe money that never appears in the client balance list. Frequent proofs, a named independent verifier and many clients checking their own inclusion each make those tricks harder.
Does proof of reserves cover margin and lending balances?
Only if the exchange says so. A proof may count spot balances and nothing else. Backpack states that its proof covers spot balances, margin positions and unrealised PnL. Its statement does not mention lending balances, so this guide does not assume they are included. Read the scope note on any proof before you rely on it.
How do I check that my balance is included?
Use the inclusion check the exchange provides. In a Merkle tree scheme you receive your leaf, built from your account identifier and balance, plus a short list of neighbouring nodes. Recompute the hashes up the tree and compare the result with the published root. If the two match, your balance was counted in the total.
How often do exchanges publish proof of reserves?
There is no single standard. Each exchange chooses its own cadence, so the date of the latest proof is the first thing to read. Backpack says it publishes every day and reconciles internally every 10 minutes. In Dubai, the VARA rulebook requires reserve assets to be reconciled daily and audited at least every six months.
Sources
Sources 1 to 7 were accessed in October 2026 for this guide. Source 8 is a Backpack page.
- Vitalik Buterin, Having a safe CEX: proof of solvency and beyond, 19 November 2022.
- Internet Engineering Task Force, RFC 6962, Certificate Transparency, section 2.1 on Merkle hash trees and audit paths, June 2013.
- ethereum.org, Zero-knowledge proofs, developer documentation.
- Commodity Futures Trading Commission, release 8638-22 on the complaint against FTX Trading and Alameda Research, 13 December 2022.
- Virtual Assets Regulatory Authority, Company Rulebook, Part VI, section E: Reserve Assets, in effect since 19 June 2025.
- European Securities and Markets Authority, Interactive Single Rulebook, MiCA, Article 75, custody and administration of crypto-assets on behalf of clients.
- OtterSec, company website.
- Backpack Learn, Is Backpack Exchange safe? Proof of reserves, licences and how it works, 26 June 2026, read on 6 October 2026.