Proof of reserves (PoR) is a verification method that shows whether an exchange or custodian controlled enough specified assets to cover specified customer liabilities at a defined point in time. It combines evidence about the assets an organisation controls with evidence about the customer liabilities included in the calculation.
A credible PoR therefore has two sides. The exchange has to show what it controls, and it has to establish how much it owes the customers included in the calculation. The two figures are then compared, usually asset by asset.
That sounds simple. The difficult part is making both sides independently checkable without publishing every customer's balance or exposing private wallet information.
A useful PoR therefore comes down to five questions:
- What assets are included?
- Which customer liabilities are included?
- How is wallet control established?
- How can customers or third parties verify the calculation?
- Who performed the verification, and what exactly did they verify?
The answers determine how much evidence the report provides.
What does proof of reserves prove?
The basic calculation is straightforward.
If an exchange owes customers 1,000 BTC and controls 1,050 BTC in the wallets included in the verification, the reported BTC coverage is 105%.
But the wallet balance alone does not establish that result. It proves only that the specified address contained 1,050 BTC when it was checked. The exchange must also establish that 1,000 BTC is an accurate representation of the customer liabilities included in the same assessment.
This is why a useful PoR has three parts:
- Proof of assets: evidence that the exchange controls the wallets or other assets included in the reserves.
- Proof of liabilities: evidence that the customer balances included in the calculation are complete and have not been manipulated.
- Coverage calculation: comparison of the verified assets with the verified liabilities.
In simple terms:
Proof of reserves = proof of assets + proof of liabilities + comparison
The scope matters as much as the ratio. A report showing 110% BTC coverage does not necessarily mean that every customer asset held by the exchange is 110% backed. Other assets, products or liabilities may be outside the calculation.
How does an exchange prove liabilities without exposing customer balances?
The liability side is where privacy becomes a technical problem.
An exchange cannot normally publish a spreadsheet containing every customer's name, account number and balance. Instead, it can commit to the dataset cryptographically and give each customer enough information to verify their own entry.
The most common mechanism is a Merkle tree.
Customer records are converted into cryptographic hashes and combined repeatedly until they produce a single Merkle root. The root acts as a fingerprint of the dataset used for the calculation.
A customer can receive their own record and the hashes required to reconstruct the path from that record to the root. If the calculated root matches the published root, the customer can establish that their record was included without seeing the balances of other customers.
Kraken, for example, provides customers with tools to reconstruct their Merkle record and verify its path to the published root. BitMEX has also published an implementation in which customer liabilities are committed through a Merkle-based proof system.
The important distinction is between inclusion and completeness.
A Merkle proof can show that your balance was included. It does not by itself prove that every liability was included in the dataset.
Under Hacken's Proof of Reserves methodology, the verifier reviews the database structures and scripts used to extract customer balances, observes their execution against a production replica, and reconciles the resulting totals and record count.
This addresses a question that a customer-level Merkle proof cannot answer on its own: did the tree start with the right population of liabilities?
Why are zero-knowledge proofs used in proof of reserves?
A basic Merkle tree can establish that a particular balance was included, but it has limitations.
One historical concern is negative balances. If an exchange could insert artificial accounts with negative values into the liability tree, the apparent amount it owes customers could be reduced.
Zero-knowledge proofs can add mathematical constraints to the calculation without exposing the underlying customer data.
Binance's zk-SNARK implementation, for example, was designed to prove that the balances represented in the Merkle structure contribute to the claimed total and that a user's overall net balance is not negative.
The implementation itself can still contain security flaws. Four days after Binance released its zk-SNARK system in February 2023, Hacken researchers found a missing range check on the BasePrice input. The flaw could have allowed an exchange to lower its proved liabilities by introducing fake user debt. Binance merged Hacken's fix in GitHub PR #5.
The finding illustrates an important limitation of cryptographic PoR systems: a proof can be mathematically valid while the software generating the values being proved contains an implementation error.
Hacken's security assessment of Gate.io's PoR implementation examined its cryptographic implementation, dependencies and verification logic after Gate.io introduced zero-knowledge technology. It found no critical, high, medium or low-severity vulnerabilities, and recommended that the Merkle root be signed by a trusted third party or published on-chain so it could be verified.
When comparing PoR implementations, therefore, compare how their code was reviewed. Cryptography can reduce the amount of information an exchange has to disclose, but it does not remove the need to review the software implementing the proof.
How is wallet control verified?
Blockchains make reserve balances relatively easy to observe. The harder question is whether the exchange controls the addresses being presented as its reserves.
An exchange can demonstrate control by signing a message with the relevant private key or by executing a transaction from the address.
The method depends on the wallet architecture and the scope of the engagement. Multisignature wallets, smart-contract-controlled assets and custodial arrangements can require additional procedures.
Hacken's methodology includes both signed-message verification and controlled on-chain transactions. For a transaction-based test, the exchange sends a specified amount from the address under review and the verifier checks the resulting transaction on-chain.
This establishes control of the relevant address at the time of testing.
It does not establish that the exchange's broader key management system is secure. Key generation, storage, signer access and transaction approval are separate security questions, covered by the Cryptocurrency Security Standard and tested in a CCSS audit.
Is proof of reserves an audit?
A proof of reserves is not necessarily an audit. The term «PoR audit» is often used broadly for different types of engagements, but the procedures and assurance provided can differ substantially.
A technical verifier examines the mechanism used to establish reserves and liabilities. An accounting firm may perform agreed-upon procedures or an assurance engagement under applicable accounting standards.
Hacken's PoR is a technical verification. It is not a CPA attestation and not a PCAOB audit.
The PCAOB's Office of the Investor Advocate explicitly states that PoR engagements are not audits and are not performed under PCAOB auditing standards. Its 2023 advisory also warned that PoR reports may not address liabilities, borrowed assets or what happens after the reporting date.
The relevant question is therefore not simply who signed the report. It is what procedures that provider actually performed.
For a technical PoR, those procedures may include:
- extracting and reconciling customer liabilities;
- verifying control of reserve wallets;
- checking the reserve calculation;
- validating Merkle proofs;
- reviewing the cryptographic implementation; and
- calculating asset-by-asset coverage.
Hacken's Gate.io PoR assessment provides an example of a technical review of a PoR implementation, while its Proof of Reserves verification service covers the verification of scoped assets and liabilities.
If a regulator, bank or other stakeholder specifically requires an accountant's attestation, a technical PoR verification does not replace it.
How often should an exchange publish proof of reserves?
PoR is a snapshot, so read the verification date as closely as the publication date. Best practices include verifying reserves on a monthly to quarterly basis.
It's important because asset coverage and composition are never consistent: an exchange could have 105% coverage on Monday and a different position later in the week. A single report cannot show what happened between the snapshot and the next assessment.
That is why recurring verification is more informative than a one-off disclosure. Exchange programmes run on different schedules, from monthly verifications to less frequent independent reviews.
Frequency should not be confused with quality, however. A monthly report with unclear liabilities can provide less useful evidence than a less frequent report with a clearly defined scope and independent verification.
In the PoR equation, quality components are:
frequency + scope + verification method + independent review
For example, Bybit provides a practical example of recurring verification. Hacken has performed monthly PoR assessments for Bybit since June 2024. Five days after the February 2025 theft, Hacken's assessment of 26 February showed every covered asset above 100% (case study).
The incident illustrates an important boundary: PoR can show whether covered assets exceeded covered liabilities at the assessment date. It does not test whether the exchange's wallets, signing infrastructure or wider systems can resist an attack.
That is why PoR should not be presented as a substitute for an exchange security assessment or penetration test.
What should a proof of reserves report contain?
A good report lets an external reader reconstruct the basic claim being made.
At minimum, look for:
- the verification or snapshot date;
- the assets and networks included;
- the reserve wallet addresses or another way to identify the verified assets;
- the method used to establish wallet control;
- the customer liabilities included;
- the products or balance types included;
- asset-by-asset coverage;
- the method customers can use to verify their own inclusion;
- the independent verifier and its scope; and
- material exclusions or limitations.
A useful way to assess the evidence is to ask what each component establishes:
Then look at what the reserves are made of.
Suppose an exchange reports 120% total coverage in dollar terms. That figure could conceal a BTC surplus offsetting a USDT shortfall. Asset-by-asset coverage shows the shortfall the dollar total hides.
Liquidity changes the picture as well. A reserve composed largely of an exchange's own token behaves differently from a reserve composed of independently traded, liquid assets, particularly when customers are withdrawing at scale.
The same applies to encumbrances. If reserves are lent, pledged, locked or subject to another claim, that should be visible in the report.
For historical context, Hacken's analysis of the FTX collapse examines the role of FTT and related balance-sheet exposures.
Hacken has also described what greater centralised-exchange transparency could look like.
What does proof of reserves not prove?
A passing PoR is not a statement that the exchange is financially healthy in every respect.
Depending on its scope, a PoR may not establish:
- the exchange's complete corporate liabilities;
- obligations to lenders, suppliers or related parties;
- assets or liabilities held outside the assessed entities;
- whether reserve assets are encumbered;
- what happens to the reserves after the snapshot;
- the security of the exchange's infrastructure;
- the security of its signing systems; or
- whether the exchange can meet obligations that fall outside the PoR scope.
The PCAOB has highlighted several of these limitations, including the possibility that assets could be borrowed for the purpose of a snapshot and the fact that PoR reports do not establish future coverage.
A PoR is therefore best understood as a defined piece of evidence, not a general safety certificate.
Does MiCA require proof of reserves?
Not as a general requirement for crypto-asset service providers.
MiCA contains specific reserve requirements for issuers of asset-referenced tokens. Article 36 establishes requirements for the reserve of assets, and Article 36(9) requires an independent audit of that reserve every six months.
These requirements concern asset-referenced token issuers. They should not be presented as a general requirement for every exchange or CASP to publish a PoR report.
MiCA also contains separate requirements concerning the safeguarding of client crypto-assets and funds by crypto-asset service providers.
A PoR can provide technical evidence relevant to an organisation's transparency or regulatory programme, but it does not automatically satisfy every MiCA, accounting or custody obligation.
For the broader regulatory context, see Hacken's MiCA guide and global stablecoin regulation overview. Organisations working through their wider regulatory obligations can also review Hacken's CASP and VASP compliance services.
How can a customer verify their own balance?
The simplest customer-level test is to verify inclusion in the liability dataset.
The exchange provides a customer-specific record and the corresponding Merkle proof. The customer reconstructs the path from that record to the published Merkle root.
If the root matches, the customer can verify that their balance was included in the committed dataset.
That does not prove that every other customer was included. It also does not prove that the exchange controls all of its claimed reserves or that the reserves will remain sufficient after the snapshot.
Those questions require the other parts of the verification.
How should you evaluate a proof of reserves?
Start with the report, not the headline percentage.
Check the date. Check the assets. Check the liabilities. Check how wallet control was established. Check whether you can verify your own balance. Check who performed the work and what procedures they performed.
Then check what is outside the scope.
A useful PoR should make those boundaries easy to understand. If the report gives you a reserve ratio but leaves you unable to determine which liabilities were counted, which wallets were checked or when the evidence was collected, the percentage tells you less than it appears to.
The question a sceptic should be able to ask is simple:
What can I independently verify from this report?
If the answer is clear, the PoR is doing its job
