top of page

Proof of Reserves Doesn't Prove Solvency: What Binance's Latest Attestation Teaches Payment Teams About Verification

2 days ago
5 min read

For payment teams, counterparty risk is not an abstract question about whether a provider is trustworthy. It is a practical one: what evidence shows that funds are available, obligations are covered and settlement can continue when conditions change?

Binance’s latest proof of reserves offers a useful case study in both the value and the limits of verification. On 6 November, the exchange said the zero knowledge proof for its latest reserves snapshot was ready. That snapshot, taken at 00:00 UTC on 4 November, covered 44 tokens, up from 10 in the previous snapshot. Generating the proof took approximately 50 to 60 hours, according to Exchange.news’ report on the update.

The headline is meaningful: eligible users can check that covered balances were backed at least 1:1 at the snapshot time. But that is a defined test, not a complete assessment of an institution’s financial health.

What 1:1 proof of reserves actually checks

Binance describes its proof of reserves process as using Merkle trees and zk-SNARKs. A Merkle tree organises account balances into a structure that lets a user check whether their balance is included. A zero knowledge proof can demonstrate that specified calculations meet defined conditions without publishing every customer’s account details.

In practical terms, a customer can verify that their balance was included in the relevant data set. The proof is designed to show that the covered customer balances are supported at least 1:1 by assets attributed to exchange controlled wallets at the time of the snapshot. Binance explains its methodology on its proof of reserves page.

That is a valuable form of transparency. It can reduce reliance on a provider’s headline claim alone by allowing users to test their own inclusion in the proof. It also makes the scope visible: in this case, the November 4 snapshot covered 44 tokens, while the October 31 snapshot covered 10. The Block’s 2 November report described that earlier snapshot and its initial ten-token scope.

But cryptographic verification is not the same as an independent, full balance sheet audit. The provider defines and supplies the data set, and the proof addresses particular assets and customer balances within that scope. It does not, on its own, verify every financial claim against the institution.

Luminous branches converge into a single cryptographic root, representing account inclusion in a Merkle proof

What proof of reserves does not prove

It is not a complete liabilities test. A 1:1 ratio relates the covered assets to the covered customer balances in the proof. It does not establish that all corporate liabilities are included. Off chain debts, loans, contingent obligations and other claims may sit outside the data set. A provider could show assets sufficient for specified customer balances while still facing other financial obligations.

It is not a solvency opinion. Solvency requires a broader view of assets, liabilities and the ability to meet obligations. Proof of reserves does not establish that the institution as a whole is solvent, or that it will remain so. Nor does it prove the provider can meet every withdrawal or settlement request immediately.

It is not a complete encumbrance check. A snapshot does not automatically establish that every reported asset is free from liens, pledges or other claims. Nor does a point in time proof show whether funds were temporarily borrowed or arranged around the snapshot date. Those questions require additional evidence and controls.

It is not continuous monitoring. The November 4 snapshot represents balances at a specific moment. It cannot confirm the position the next day, or after a major movement of funds. The proof also took around 50 to 60 hours to generate, so the verification was available after the snapshot rather than continuously.

This is why the word “proof” needs careful interpretation. The cryptography can prove that particular data meets particular rules. It cannot make the data set complete by itself, or expand the conclusion beyond what the rules and inputs cover.

Why the wider recovery context matters

The latest proof arrived alongside separate recovery milestones. Binance said on 4 November that approximately 98% of the assets affected by the security incident had been replenished, with less liquid tokens still being bought through market and over the counter channels. The Recovery Update #7 announcement also reported the expanded 44 token snapshot.

On 6 November, Binance announced a further reopening of withdrawals across nine networks and 58 network and token pairs. That operational update, covered in Exchange.news’ report on Recovery Update #9, is distinct from proof of reserves. A reserves proof can help test backing at a snapshot; withdrawal availability is evidence about service access and operational readiness. Neither replaces the other.

For merchants, the distinction is familiar. A provider can show that a defined pool of assets exists while still having operational constraints, settlement delays or exposures that matter to a customer. Counterparty assessment should therefore combine asset verification with service continuity, access and liability checks.

Our earlier analysis of Binance’s post incident outflows examined how flows can inform a counterparty assessment. Our initial analysis of the security incident as a payments story considered control, authorisation and recovery. The verification lesson now is to make evidence gathering a routine discipline, not a one off response to a crisis.

A verification cadence for merchant teams

Payment providers are not all crypto exchanges, and proof of reserves is not a universal requirement for every service relationship. The underlying discipline is broadly useful, however: define what evidence you need, how often it should be refreshed and what action follows when it is missing or changes.

A moving neon asset stream passes through a glass snapshot frame, highlighting the limits of point in time verification

Use this six point checklist to strengthen your counterparty reviews:

  1. Map which providers hold, move or settle your funds, including the entities and custodians involved.

  2. Request evidence that matches the exposure: covered assets, customer liabilities, relevant legal entities and the date of the evidence.

  3. Ask how assets are controlled and whether custody is separated from operating funds. For digital asset custody, clarify who can authorise transfers and under what conditions.

  4. Check the limits of each report: whether it is self reported or independently reviewed, what liabilities it includes and whether it addresses encumbrances.

  5. Set a verification cadence based on risk. Schedule recurring evidence reviews and define triggers for an out of cycle check, such as a material incident or a change in settlement access.

  6. Record escalation steps in advance. Identify who assesses a gap, what alternative settlement arrangements are available and how treasury and operations teams will be informed.

The aim is not to demand one universal report from every provider. It is to avoid treating a single metric or document as proof of risks it was not designed to test. A disciplined review considers custody, controls, liabilities, operational access and how quickly the evidence becomes stale.

Frequently asked questions

Does 1:1 proof of reserves mean an exchange is solvent?

No. It can show that specified customer balances are backed by specified assets at a particular snapshot. It does not test every corporate liability or establish overall solvency.

Can users verify Binance’s proof themselves?

Binance provides a process for users to check whether their account balance is included in the relevant proof. The result applies to the snapshot and assets covered, not to every balance, liability or future position.

How often should merchants verify payment counterparties?

There is no single suitable interval for every business. Set a recurring review based on the provider’s role, funds held, settlement exposure and operational importance. Add event driven reviews when material changes occur.

Distinct secure layers and verification gates separate custody pathways in a dark neon fintech scene

Binance’s latest proof is a meaningful example of verifiable disclosure. It shows how cryptography can help customers check a defined claim rather than simply accept it. It also illustrates the boundary: proof of reserves is evidence about a particular snapshot, not proof of solvency.

For payment teams, the strategic takeaway is to institutionalise verification. Understand what each piece of evidence proves, what it leaves out, and when it needs to be refreshed. Counterparty risk is better managed through a repeatable process than through trust in any single attestation.

 
 
bottom of page