LIVE
/
ECOSYSTEMTidoEx Hybrid AMM + Orderbook Protocol v2 is live! Trade digital assets securely with institutional execution.Learn more

This is a local cryptographic verifier. It computes the Merkle root from the leaf data and proof path you provide and compares it with the root published by your exchange. Nothing is uploaded, and Coinorama does not supply exchange proof data — download your inclusion proof and published root from your exchange's Proof of Reserves page.

Account Leaf Data

Merkle Sibling Path

Cryptographic Proof of Reserves: The Mathematical Standard for Institutional Exchange Solvency

The collapse of major centralized custodians throughout 2022 fundamentally transformed expectations regarding cryptocurrency custody and fiduciary transparency. In legacy banking, fractional reserve systems operate under the presumption of central bank backstops and periodic government audits. In cryptocurrency, where transactions are irreversible and bailouts do not exist, exchanges must prove full backing through cryptographic verification rather than reputational trust.

Proof of Reserves (PoR) is a cryptographic auditing methodology that allows depositors to mathematically verify that a custodial venue holds sufficient assets in reserve to fulfill 100% of user liabilities. When implemented correctly through Merkle Sum Trees and Zero-Knowledge proofs (zk-SNARKs), PoR establishes an unprecedented level of real-time fiduciary transparency while rigorously protecting user privacy and institutional proprietary data.

Anatomy of a Merkle Sum Tree

A standard Merkle tree aggregates transactional hashes up to a single cryptographic root. A Merkle Sum Tree augments each node with balance data:

Parent_Node = Hash(Child_L || Child_R)
Parent_Sum = Child_L.Sum + Child_R.Sum

Leaf nodes represent individual user accounts, containing the user ID, a private salt (nonce), and their token balances. Each parent node sums the balance of its children, culminating in the Merkle Root, which represents the exact cumulative customer liability of the exchange at that specific block height.

Zero-Knowledge Proofs (zk-SNARKs) in Solvency

A critical vulnerability in early Merkle tree implementations was the potential inclusion of synthetic negative-balance accounts to mask unbacked liabilities. If an exchange owes \$100M but enters a fictitious account with a -\$20M balance, the calculated liability root falsely reports only \$80M.

Modern zero-knowledge Proof of Reserves (such as OKX and Binance V2) uses zk-SNARKs circuits to mathematically prove that every single leaf node balance is strictly non-negative ($Balance \ge 0$) and that all leaf values sum up to the published root, without revealing any individual account data.

Assets vs. Liabilities: The Solvency Equation

A complete proof of solvency requires proving two independent halves of the balance sheet:

  • Proof of Assets (PoA): The exchange signs a cryptographic message with the private keys of its cold, warm, and hot wallet clusters to prove total reserve ownership.
  • Proof of Liabilities (PoL): The exchange publishes a Merkle sum tree containing every active customer deposit balance.
  • Solvency Ratio: Reserves / Liabilities $\ge$ 100%. If reserves exceed liabilities, the venue is verifiably fully backed.

Step-by-Step Self-Sovereign Verification

Using Coinorama's interactive verifier, any depositor can independently audit their inclusion:

  1. Input your account UID and private nonce provided by the exchange.
  2. Enter your recorded token balances (BTC, ETH, USDT) at the audit snapshot block.
  3. The engine hashes your leaf node and traverses the cryptographic Merkle sibling path.
  4. If the computed root matches the audited published Merkle root, your balance is mathematically verified to be included in the exchange's reserves.

Frequently Asked Questions: Merkle Tree Proof of Reserves

Technical explanations of cryptographic auditing, hash functions, and exchange solvency safeguards.

Does verifying my balance reveal my portfolio size to others?

No. The verifier runs entirely client-side in your web browser. Your UID, nonce, and balance data are never transmitted to external servers. The Merkle sibling path only contains hash digests of neighboring subtrees, revealing zero balances of other depositors.

What hash algorithm is used in Proof of Reserves trees?

Most centralized exchanges use standard cryptographic hash algorithms such as SHA-256 or Keccak-256. For zero-knowledge SNARK circuits, algebraic hash functions like Poseidon are increasingly preferred because they minimize arithmetic constraint counts in zk-proof generation.

Can an exchange borrow funds temporarily to pass an audit snapshot?

While historical audits could theoretically be manipulated by borrowing assets right before a snapshot, modern PoR frameworks perform continuous, randomized, or monthly audits. Furthermore, on-chain blockchain analysis tracks wallet flows to verify that reserves have not been flash-borrowed.

Where do I get my leaf data and proof path?

Your exchange publishes these on its Proof of Reserves page: your account UID, your private nonce (salt), your balances at the snapshot block, the sibling hashes of your Merkle path, and the aggregate Merkle root. Coinorama does not provide or store this data — it only computes the root locally from what you enter.