obsidiate.
Set up & trade safely
BeginnerLesson 7 of 106 min read

Proof of reserves, explained simply

Every exchange that ever collapsed said “funds are safe” right up until the end. The phrase has appeared in so many final announcements that traders treat it as an omen. The lesson the industry eventually drew is simple: a custodian saying it holds your assets is worth nothing by itself. What is worth something is a custodian proving it — publicly, repeatedly, in a way you can check without trusting anyone’s word. That is what proof of reserves attempts to be.

The previous lesson established that your exchange balance is a claim on a ledger. Proof of reserves is the discipline of demonstrating, on a regular schedule, that the assets backing those claims actually exist and actually suffice. It has two halves — proving the assets and proving the liabilities — and the second half is where the clever part lives.

Why said-so is not enough

The failure mode is always a version of the same story. A platform quietly lends out customer assets, or trades with them, or fills a hole in one pocket with money from another. The ledger still shows everyone their full balance; the vault no longer contains it. Nothing looks wrong from outside, because withdrawals keep working — right up until too many people withdraw at once and the gap becomes visible. By then it is far too late. The entire purpose of proof of reserves is to make that gap impossible to hide for long, by forcing the vault and the ledger into public view on a schedule.

Step one: prove the assets

The asset side is the easy half, because blockchains are public. The exchange publishes the addresses of its reserve wallets, and anyone — you, a journalist, a rival — can look up their balances and sum them, at any hour, without permission. To prove it actually controls those addresses rather than merely pointing at someone else’s, the platform signs messages with the wallets’ private keys or moves a specified amount at an agreed moment — things only the true keyholder can do. Obsidiate publishes its on-chain reserve wallets this way: the watching is the point.

Step two: prove the liabilities, without doxxing anyone

Big wallets alone prove nothing — what matters is whether they cover what customers are owed. But publishing every customer balance would be a privacy disaster. The solution is a structure called a Merkle tree, which sounds intimidating and is actually just disciplined fingerprinting.

  1. Picture every customer balance written on its own card. Each card gets a fingerprint — a hash, a short code computed from the card’s contents that changes completely if even one digit on the card changes.
  2. Fingerprints are then paired, and each pair is fingerprinted together. Those results are paired and fingerprinted again, level after level, until a single fingerprint remains: the root.
  3. The exchange publishes the root. Because every card fed into it, the root is a commitment to the entire set of balances — change any single balance anywhere and the root no longer matches.
  4. You can be given your card plus the short chain of fingerprints linking it upward, and verify with simple math that your exact balance is included in the published total. You learn nothing about anyone else, and they learn nothing about you.

Summing the tree gives total liabilities. Set that against the proven on-chain assets, and the central claim becomes checkable: reserves meet or exceed what customers are owed. On Obsidiate, customer liabilities are hashed into a Merkle tree exactly this way, and reserves exceed liabilities.

The attestation: an outsider checks the math

An attestation adds an independent party to the process. At a point in time, the outside firm verifies that the platform controls the published wallets, that the liability tree was computed honestly from the real customer ledger, and that assets cover liabilities. Obsidiate runs this monthly. Frequency matters more than it first appears: a single snapshot can be staged, but staging a clean picture every month, from consistent long-lived wallets, with numbers that reconcile month over month, becomes steadily harder to fake and steadily more telling.

When reading any proof of reserves, find the liabilities side first. Screenshots of large wallets are advertising; a published Merkle root with per-customer verification is evidence.

What it does not cover — honestly

Proof of reserves is a major improvement on trust-me, and it still has edges you should know about, because a tool you overtrust is a tool that fails you.

  • It is a snapshot. It proves the situation at the moment of measurement, not continuously. Regular cadence narrows this gap; nothing eliminates it.
  • Assets can in principle be borrowed for the photo and returned after. Consistent wallets and monthly repetition make this expensive and visible, not impossible.
  • It shows assets versus customer liabilities, not the whole balance sheet. Debts to lenders or other obligations elsewhere are outside its frame — covering those requires fuller audited statements.
  • An attestation is narrower than a full financial audit. It verifies specific claims at a specific time; it does not opine on the entire business.
  • Fiat balances live in banks, not on chains, so the fiat side rests on bank confirmations rather than public ledgers — third-party checkable, but not by you directly.

Key takeaways

  • A custodian’s claim to hold your assets is worth nothing unverified — every collapsed platform said funds were safe.
  • Assets are proven with published on-chain wallets and signatures only the true keyholder can produce.
  • A Merkle tree commits the exchange to every customer balance at once, and lets you verify your own inclusion without exposing anyone’s privacy.
  • Independent, regular attestation — monthly on Obsidiate — checks that proven assets meet or exceed proven liabilities.
  • Know the limits: snapshots in time, customer liabilities only, narrower than a full audit. Better than trust — still not a substitute for judgment.