Proof-of-reserves (PoR) is usually a proof-of-assets statement: a custodian discloses assets it controls and proves those assets exist at the time of the snapshot.
The stronger goal is proof-of-solvency: assets are at least as large as liabilities, and the liability set is correctly represented.
A widely referenced framework on exchange safety treats this as an assets-and-liabilities problem and explains why a “proof of assets only” approach can leave critical gaps. Most retail-facing PoR implementations sit somewhere between the two.
They do not necessarily prove all liabilities, all assets, or the absence of hidden leverage.
PoR is still useful when its scope is understood.
If an exchange discloses a set of on-chain addresses, anyone can confirm balances for those addresses. This proves the disclosed assets exist at the moment of measurement.
It does not prove the exchange owns assets that are not disclosed.
It does not prove the exchange does not owe more than it holds.
Many modern PoR systems use a Merkle tree for user liabilities, enabling users to verify their own inclusion without revealing other users’ balances.
PoR can also be seen as a cryptographic accounting procedure where clients can verify in-scope balances are backed by assets held in custody, using a process designed for user-level verification.
Some exchanges publish an in-scope reserve ratio by comparing disclosed on-chain assets to the sum of in-scope liabilities.
This is useful as a lower bound. It is still limited by what is in-scope and by the accuracy of liabilities representation.
The most common misinterpretation is treating PoR as a guarantee of safety. A PoR report cannot usually prove the exchange has no hidden debt, off-chain liabilities, or contingent obligations.
PoR also cannot prove assets are unencumbered. If assets are borrowed short-term to pass a snapshot, an asset-only proof will still show balances.
Even when liabilities are included, PoR cannot usually verify:
PoR verification has two mechanical layers.
A user gets a Merkle leaf or a proof path and verifies that their balance was included in the liabilities Merkle root at the time of the snapshot.
This answers a narrow question: “Was this account included in the liabilities set?”
It does not answer: “Are all accounts included?”
The exchange discloses addresses and the snapshot compares balances in those addresses to the liabilities root.
Some systems also include cryptographic proofs to support integrity. Binance’s system describes the use of Merkle tree properties for verifying individual inclusion and references a zk-based mechanism for validating aspects of the liabilities report.
Ownership verification is separate from balance verification. Seeing funds at an address does not prove who controls the keys unless control is demonstrated through signing, third-party attestation, or operational proofs.
Verification tools fall into three buckets: exchange-native self-verification, independent aggregation dashboards, and custom query tooling.
Kraken runs recurring proof-of-reserves processes and supports user-level verification, including a Merkle verification workflow described as an open-source Merkle verification tool in its PoR communications.
Kraken fits best for users who want an exchange-native, user-level inclusion check plus a recurring cadence that can be monitored over time.
Binance provides a PoR system built around user inclusion checks and a liabilities snapshot, with a user-facing PoR surface designed for individual verificatio.
Binance fits best when the workflow is verifying inclusion in the liabilities snapshot and checking disclosed on-chain wallet balances for the in-scope assets.
OKX maintains an open-source proof-of-reserves repository that includes tooling such as a Merkle validator for checking account inclusion in the published Merkle tree and references zk-proof validators used in its PoR framework.
OKX fits best for users who want a code-verifiable workflow that can be rerun independently.
CryptoQuant maintains a proof-of-reserve dashboard that aggregates disclosed addresses and presents a monitoring view for exchange reserves, with a framing that relies on disclosed wallet addresses from PoR announcements.
CryptoQuant fits best for monitoring changes and comparing multiple exchanges under a consistent dashboard format.
DefiLlama’s CEX Transparency pages publish live exchange rankings by assets and inflow data, which can be used as a real-time monitoring layer for disclosed exchange wallets and flows.
DefiLlama fits best for cross-exchange monitoring, especially when the workflow needs asset and inflow trend context rather than a one-off snapshot.
Dune hosts community dashboards that track exchange wallets and reserves as a lower bound for holdings on specific chains, including dashboards dedicated to exchange proof-of-reserves tracking.
Dune fits best for analysts who want transparency into methodology and the ability to fork dashboards or build custom reserve tracking.
PoR can be evaluated quickly by checking scope, cadence, and verification openness.
A PoR that covers only a subset of assets can still be useful, but it should not be treated as a full exchange balance sheet.
A PoR that covers only on-chain assets cannot represent fiat liabilities or off-chain obligations.
PoR is more credible when it is recurring and consistent. One snapshot is a marketing moment. A recurring cadence is a monitoring tool.
User-level inclusion checks are the minimum bar. Kraken explicitly frames user-level verification as a core part of the process, and OKX provides a validator toolkit designed for account inclusion checks.
Reserve verification depends on disclosed addresses. If the address set is partial or unclear, third-party dashboards become less reliable because they are forced to operate on an incomplete list.
Liability completeness is the hardest part of solvency proof. A liabilities Merkle tree can prove inclusion for a user, but it cannot guarantee that the exchange did not omit accounts unless stronger disclosure and auditing constraints exist.
The proof-of-solvency framing emphasizes that the missing piece is often liabilities, not assets, and that better cryptographic and auditing designs are needed to reduce the omission and manipulation surfac.
A PoR snapshot that coincides with unusual inflows to disclosed wallets can indicate window dressing. This is not conclusive by itself, but it raises the need for monitoring flows pre- and post-snapshot.
A PoR that cannot be independently verified by users increases trust dependency on the exchange.
A PoR that lacks clarity on in-scope assets, liabilities snapshot date, and address ownership proofs is not decision-quality transparency.
A PoR that is not repeated creates a false sense of security because the operational reality can change quickly.
The best proof-of-reserves verification tools in 2026 combine user-level inclusion checks, disclosed on-chain wallet monitoring, and repeatable workflows. Exchange-native tools such as Kraken’s PoR verification and Binance’s PoR surface enable account inclusion checks, while OKX’s open-source validators provide a rerunnable verification path. Aggregators such as CryptoQuant, DefiLlama’s CEX Transparency pages, and Dune dashboards add ongoing monitoring and cross-exchange context.
PoR is still not full solvency proof. It can validate certain assets and certain liabilities snapshots, but it cannot guarantee liability completeness or reveal hidden leverage and off-chain obligations. The highest-signal approach is treating PoR as a lower-bound transparency tool, then combining it with flow monitoring, scope analysis, and a clear understanding of what the cryptography can and cannot prove.
The post 2026 Proof-of-Reserves Verification Tools: What You Can (and Can’t) Prove appeared first on Crypto Adventure.
