Proof of reserves explained for the people who actually have to rely on it: customers choosing an exchange, boards approving a custodian, and counterparties doing due diligence on someone else's balance sheet.

Almost every large crypto platform now publishes something called proof of reserves. Very few of those publications prove what the name implies. The usual artefact is a dashboard showing wallet balances, a large percentage figure, and a logo. That is a statement about assets. Solvency is a comparison between two numbers, and the second number — what the platform owes its customers — is the one most commonly missing, unverified, or quietly supplied by the platform itself.

This guide is about reading rather than producing. If you want to know what a rigorous engagement involves on the inside, our proof of reserves attestation service sets out the methodology. What follows is the other half: how to evaluate a report that someone else has published, and how to tell assurance from marketing.

Assets Alone Prove Nothing

Start with the arithmetic, because everything else follows from it. A reserve ratio is reserves divided by liabilities. If a platform publishes only the numerator, it has published a number with no denominator and no meaning.

Consider a platform showing 100,000 BTC in verified cold storage. Impressive, until you ask what customers are owed. If the answer is 95,000 BTC, the platform is over-collateralised. If it is 130,000 BTC, the same wallets now describe a hole. The on-chain figure did not change. Only the half nobody published did.

So the first question is not "how much do they hold" but "against what". When you open any attestation, look for an explicit total customer liability, expressed per asset rather than as a single blended dollar figure. Blending matters: a platform can be 150% covered in stablecoins and 70% covered in a token it lent out, and the aggregate USD ratio will hide that. Reserves and liabilities should be compared asset by asset, or the comparison is cosmetic.

Proving Wallet Control Must Be Cryptographic

The asset side has its own failure mode. A list of addresses is not evidence of ownership. Anyone can point at a wallet on a block explorer and call it theirs, and blockchains have no concept of a name attached to an address.

Control has to be demonstrated, and there are only two credible ways to do it. The first is a signed challenge message: the verifier supplies a phrase, the platform signs it with the private keys controlling each reserve address, and the signature verifies against that address. The second is a nominal transfer executed on the verifier's instruction, at a moment and amount the verifier chooses. Both prove possession of keys. Neither can be produced by someone who has merely borrowed sight of a wallet.

When you read a report, look for language describing how control was established. "Management provided a list of wallet addresses" is an assertion the verifier accepted. "Control of each address was demonstrated by signature over a challenge message specified by us" is proof. If the report is silent on the point, treat the addresses as unproven, and ask whether any address was excluded because control could not be shown. A report that excludes nothing has often tested nothing.

Merkle Trees and How a Customer Verifies Inclusion

The liability side has a genuine problem: a platform cannot publish every customer balance without destroying customer privacy. The standard solution is a Merkle tree, and it is worth understanding because it is the one part of proof of reserves that individual users can check themselves.

The construction is simple. Every customer's account balance is hashed into a leaf. Pairs of leaves are hashed together into parent nodes, then pairs of parents into their parents, until a single hash remains at the top. That top value is the Merkle root, and the platform publishes it alongside the attestation. Change any single balance anywhere in the tree, and the root changes completely.

Here is how a customer performs the check in practice:

Retrieve your own proof. Log in and find the proof of reserves or verification section. The platform should give you a record ID, your balance as it was included at the snapshot, and a short list of sibling hashes — your Merkle path.
Recompute the leaf. Hash your own record using the algorithm the platform documents. If the result does not match the leaf they gave you, your balance was recorded as something other than what you hold.
Walk the path upward. Combine your leaf with each sibling hash in turn, in the specified order, hashing at each level. This takes about twenty steps even for a platform with a million customers.
Compare to the published root. If your final hash equals the root the auditor attested to, your balance was inside the total that was verified. If it does not, it was not.

Most platforms provide an in-browser tool for this. Prefer the ones that also publish an open-source verifier you can run yourself, since a check performed entirely by the party being checked is not much of a check. Reputable implementations publish the hashing scheme in enough detail that a third party can reimplement it.

Now the crucial limitation. A Merkle proof shows that your balance was included. It says nothing about whether everyone else's was. A platform can omit a class of accounts, or insert a leaf with a negative balance to shrink the total, and every individual proof will still verify. This is why the tree has to be built or independently tested by the verifier from the complete ledger, with controls testing around ledger completeness, rather than accepted as a finished output from the platform. If a report describes a Merkle root but says nothing about how the leaves were sourced and tested, the cryptography is decorating an unaudited number.

The Snapshot Problem

Every attestation describes a moment. That moment is the weakness anyone determined to game the process will attack.

If the snapshot time is known in advance, assets can be borrowed shortly before it and returned shortly after. The wallets are genuinely controlled, the signatures genuinely verify, and the report is genuinely accurate about a position that existed for a few hours. Related-party transfers between affiliated entities produce the same effect without any external lender at all.

Three things reduce this risk, and you can check for all of them:

Unannounced or verifier-selected timing. The platform should not choose the block height it is measured at.
Investigation of large inbound movements. A competent verifier looks at what arrived in the reserve wallets shortly before the snapshot and where it went afterwards. Large round-number inflows immediately before a snapshot are the signature to look for, and any credible report addresses them.
An unbroken series. This is the single strongest signal available to a non-specialist reader. Window dressing one snapshot is feasible. Window dressing every snapshot, on a published schedule, for eight consecutive quarters, requires sustaining the deception continuously — which is a different order of difficulty.

So look at the archive before you look at the latest report. A platform with three years of quarterly attestations, including through bad quarters, is telling you something a first-time publisher cannot. Watch for gaps. A missed period, a change of verifier without explanation, or a quiet shift from monthly to annual publication is worth more attention than the current ratio.

Who Signed It

An attestation is only as good as the party standing behind it, and that party should be independent, professionally regulated, and named.

Check whether the signer is a licensed accounting firm subject to professional standards and disciplinary oversight — in Cyprus, that means licensed by ICPAC — or a consultancy with no such obligations. Check whether the firm is named at all, or whether the report is self-published with a vendor's dashboard embedded. Check the engagement letter description: an attestation performed under a recognised assurance standard carries obligations that a "report of factual findings" prepared to the client's specification does not.

Independence deserves a moment of thought too. A verifier who is also a large shareholder, a lender, or a commercial partner of the platform is not independent, however competent. Reports rarely volunteer this, so it is a fair question to ask directly.

Attestation Is Not an Audit

This distinction is routinely blurred in marketing and it matters enormously.

A proof of reserves attestation is narrow and deep: it addresses specified assets and specified customer liabilities at a point in time. A financial statement audit is broad: it covers the whole entity — revenue, expenses, related-party transactions, off-balance-sheet obligations, going concern. The two answer different questions. Proof of reserves can be run quarterly or monthly; a full audit cannot.

The practical consequence is the honest limitation of the entire exercise. Proof of reserves is not a solvency guarantee. It cannot see debts that never touch the customer ledger — a loan from an affiliate, an undisclosed guarantee, a legal judgment, a commitment to a related entity. It says nothing about whether the business is profitable or whether its operating costs exceed its revenue. A platform can pass a reserves attestation cleanly on Monday and fail for reasons entirely outside its scope on Friday.

That is not an argument against proof of reserves. It is an argument for reading it as what it is: strong evidence about one specific and important question, published frequently, rather than a clean bill of health. Treat a report that claims more than that as a warning in itself. Any verifier worth trusting states the limitations plainly in the document.

The Checklist: Twelve Questions to Ask of Any Attestation

Take these to any published report, or send them to a platform that has not published one. The answers, or the absence of them, will tell you most of what you need to know.

Are liabilities stated at all? If the report shows only wallet balances, it is a balance disclosure, not proof of reserves. Stop here.
Are reserves and liabilities compared asset by asset? A single blended ratio can conceal a serious shortfall in one asset behind a surplus in another.
How was wallet control proven? Signed challenge message or verifier-instructed transfer. Not a list of addresses supplied by management.
Were any addresses excluded, and why? Exclusions are a sign the verifier actually tested something.
Where did the liability ledger come from, and was it tested for completeness? This is the question that separates real engagements from theatre.
Is a Merkle root published, and can you verify your own inclusion? Ideally with an open-source verifier you can run independently.
Who chose the snapshot time? Verifier-selected or unannounced timing is materially stronger than a date the platform announced weeks earlier.
Were large pre-snapshot inflows investigated? The report should say so explicitly.
Is there a series, and is it unbroken? Check the archive for gaps, cadence changes, and changes of verifier.
Who signed it, and are they licensed and independent? A named, regulated, independent firm — or not.
What is in scope, and what is out? Assets held with third-party custodians, staked, or lent out carry counterparty risk and should be identified separately rather than counted at face value.
What limitations does the report itself disclose? A report that names its own blind spots is more trustworthy than one that does not. Silence here is the loudest signal in the document.

A platform that can answer all twelve is doing serious work. A platform that answers three and calls the result proof of reserves is relying on the phrase rather than the practice.

Why This Is Becoming a Regulatory Question

Until recently, publishing reserves was voluntary and reputational. In the EU it is turning into evidence. The Markets in Crypto-Assets Regulation does not use the phrase "proof of reserves", but it requires crypto-asset service providers to segregate and safeguard client assets and imposes specific reserve and reporting obligations on token issuers. A recurring, independently signed reserves attestation is the practical way to evidence compliance with obligations of that shape — which is why the standard of what counts as credible is rising, and why the closing MiCA transition window has pushed a number of platforms to publish for the first time.

The reader's advantage in this environment is simple. The gap between platforms that can withstand the twelve questions above and platforms that cannot is wide, visible, and free to check.

How Ondology Labs can help: We perform independent proof of reserves attestations for exchanges, custodians, stablecoin issuers, and funds — verifying cryptographic wallet control, establishing customer liabilities, and publishing reports written to be read by the people above rather than filed. We also provide broader blockchain auditing for firms that need the full picture, and counterparty reviews for boards assessing someone else's attestation.

Related reading: MiCA's closing transition window · Inside the CoinDCX $44M hack.

How to Read a Proof of Reserves Report (And Spot a Meaningless One)