Research
Proof of Reserves Solvency: Why Assets Alone Do Not Prove It
July 14, 2026
8 mins read
Most proof of reserves shows assets on one side of the ledger. Proof of reserves solvency requires both sides: assets and the full liabilities they are supposed to cover. This explains the gap and how it is closed.
TL;DR: Proof of reserves solvency means proving an issuer's assets are greater than or equal to its total liabilities, not just that assets exist. Most published proof of reserves shows the asset side and omits or attests the liability side, demonstrating backing, not solvency. Proving both requires a committed liability set alongside the asset proof; zkDatabase can generate that combined proof.
The common form of proof of reserves proves only that assets exist, which is a weaker claim than solvency: assets equal to or greater than everything the issuer owes. zkDatabase's role is to make both sides of the ledger provable over committed data, so a counterparty can verify coverage rather than trust a headline reserve figure. The outcome is a check that survives scrutiny.
Key Takeaways:
- Proof of reserves solvency requires proving assets are greater than or equal to total liabilities, not just that reserves exist on the asset side.
- Asset-only proofs answer "does the issuer hold funds," while solvency answers the question that matters in a crisis: "does it hold enough to cover every claim."
- The liability side is the harder half, because it means committing to the full set of outstanding claims, not a single reported total.
- Real failures separate the two: USDC in 2023 had adequate assets that were briefly inaccessible, while an algorithmic collapse is a liabilities-versus-value failure.
- zkDatabase can prove both sides over committed data as a supplementary layer, without exposing individual balances, and does not replace an auditor.
What does proof of reserves solvency actually require?
Proving solvency requires two committed quantities, total assets and total liabilities, and a proof that the first is greater than or equal to the second. An asset figure on its own, however large, cannot establish solvency because it says nothing about what is owed against it. Solvency is a relationship, not a balance.
The distinction is the whole subject. Backing means the issuer holds reserves. Solvency means those reserves cover every outstanding claim. A stablecoin can show a large reserve wallet and still be insolvent if it has issued more claims than the wallet covers, and no amount of asset transparency reveals that unless the liability side is proven with equal rigor. This is why a plain proof of reserves is a starting point rather than a solvency statement.
| Question | Asset-only proof of reserves | Solvency proof |
|---|---|---|
| What it proves | Reserves exist and total a value | Assets are greater than or equal to liabilities |
| Ledger side covered | Assets only | Assets and liabilities |
| Liability handling | Reported or attested figure | Committed set of outstanding claims |
| Failure it catches | Missing or overstated reserves | Over-issuance against backing |
| What it still cannot confirm | Whether assets exceed claims | Whether the off-chain assets are genuine |
The right column is the harder engineering problem, which is exactly why so much of the market stops at the left one.
An asset-only proof shows reserves exist; a solvency proof shows assets cover the claims against them.
The liabilities side is the harder half to prove
Proving liabilities means committing to the complete set of outstanding claims against the issuer, so that no claim can be hidden to make the books look balanced. That is structurally harder than pointing at a reserve wallet, which is a single public balance. The asset side can often be read straight off a chain; the liability side has to be constructed honestly.
The established technique borrows from exchange proof-of-reserves design: build a Merkle tree of every liability, publish the root, and let each holder confirm their balance is included in the total. Combined with an asset proof, this shows assets cover the sum of all committed liabilities. The weakness is omission. If an issuer can leave liabilities out of the tree, the coverage ratio is flattering and false. Solvency therefore depends on the liability commitment being complete and tamper-evident, not just present. For yield-bearing and synthetic-dollar designs, where obligations compound and shift, that completeness is even harder to maintain, a tension explored in the yield-bearing stablecoin dual-mandate trap.
Real depegs split across the assets-versus-liabilities gap
Recent failures fall into distinct halves of the ledger, which is the clearest argument for proving both. Some issuers had sufficient assets that were temporarily inaccessible; others were structurally short of claims regardless of what a snapshot showed. Naming the half tells you what a proof needed to catch.
USDC in March 2023 is an asset-side, access-side event: roughly $3.3 billion of reserves were sound but briefly trapped at a failed bank, and the token recovered within days once access was restored, per S&P Global reporting. The 2022 collapse of an algorithmic dollar was the opposite, a liabilities-versus-value failure where the mechanism backing the claims evaporated and more than $40 billion in value unwound. The 2026 msUSD depeg added a third pattern, where the issue was that no one outside the vendor could re-run the check at all, covered in the msUSD depeg and re-runnable proof of reserves. Different halves, one lesson: a proof that only ever looked at assets would have described each of these issuers as fine right up to the break.
Solvency risk does not live on one side of the ledger, so a proof that only reads one side is measuring the wrong thing.
How can an issuer prove solvency without exposing every balance?
An issuer can prove solvency with a Zero-Knowledge Proof that assets are greater than or equal to committed liabilities, revealing the coverage result without publishing individual holder balances or the composition of the book. Privacy and verifiability are not in conflict here; the proof discloses the condition, not the records.
The construction commits both sides of the ledger and proves the inequality over them. Holders can confirm inclusion in the liability set, a regulator or counterparty can verify the coverage proof, and no individual balance becomes public in the process. Privacy should not mean hiding everything; it should mean proving the relevant condition without exposing the full record behind it. This is the difference between an oracle-reported reserve figure and a cryptographic one, compared in detail in proof of reserves for stablecoins: oracle feeds versus cryptographic proof and in the privacy-first construction behind privacy-preserving proof of reserves.
Where zkDatabase fits in proving solvency
zkDatabase generates a proof over committed asset and liability data showing that reserves cover outstanding claims, published so any counterparty can re-run the check, as a supplementary layer alongside attestation rather than a replacement for it. The claim is deliberately bounded: it proves a computation over reported data, not that the underlying assets are genuine.
The database commits to both ledgers and produces a Zero-Knowledge Proof that the coverage condition holds against that committed state. A holder, a lending protocol, or a regulator verifies the proof without seeing individual balances, and because the artifacts are public the check does not depend on one vendor staying online. What zkDatabase does not do is certify that the assets exist or the liabilities were reported honestly at the source, which remains the work of custodians and auditors. It makes the solvency relationship continuously checkable by parties other than the issuer, which asset-only reporting cannot. For how cryptographic proof and periodic attestation reinforce each other, see proof of reserves audit: cryptographic verification versus attestation.
Explore zkDatabase
See how zkDatabase proves assets cover liabilities over committed data, without exposing the balances behind either side.
FAQ
What is proof of reserves solvency?
Solvency here means an issuer's assets are greater than or equal to its total liabilities, not merely that reserves exist. Proving it requires committing to both the asset side and the full set of outstanding claims, then proving the coverage relationship between them. Asset-only proof of reserves shows backing exists but cannot establish that the backing is sufficient to cover every claim.
Why is proving liabilities harder than proving assets?
The asset side is often a public on-chain balance that anyone can read. The liability side means committing to the complete set of claims against the issuer, and the honest version cannot omit any of them. The standard method builds a Merkle tree of all liabilities and publishes its root, so holders confirm inclusion. If liabilities can be left out, the resulting coverage ratio looks healthier than reality.
Does proving reserve solvency guarantee a stablecoin will not depeg?
No. Solvency proof shows assets cover committed liabilities at the time of proof, which is a strong signal but not a guarantee. It cannot confirm that off-chain assets are genuine or that reported data is honest at the source, and it does not address liquidity access, the issue in the 2023 USDC event. It complements attestation and audit rather than replacing them.
How does zkDatabase prove solvency without exposing balances?
zkDatabase commits to both the asset and liability ledgers and generates a Zero-Knowledge Proof that assets are greater than or equal to liabilities. The proof reveals only that the coverage condition holds, not individual balances or book composition. Any counterparty can verify it from published artifacts, so the check does not depend on trusting the issuer or a single vendor's dashboard.
Related toResearch
