· four exchange APIs · rebuilt daily
A proof of reserves exchange report only shows half the
The finding
A standard proof of reserves exchange attestation verifies 100% of user balances in a Merkle tree at a single block height, but fails to audit off-chain liabilities or corporate debts.
Static balance snapshots allow venues to borrow assets shortly before the audit block and return them immediately after.
Without an audit of non-custodial liabilities and negative account balances, a public hash tree provides zero guarantee of solvency.
What a proof of reserves exchange attestation actually verifies
A proof of reserves exchange report relies on a Merkle tree data structure. The exchange hashes individual user account balances into leaf nodes. These leaves repeatedly hash together in pairs until producing a single Merkle root.
The venue publishes the Merkle root alongside public wallet addresses. You can verify your balance by hashing your individual account ID and balance with intermediate branch hashes up to the root. This confirms that your balance was included in the final sum generated by the exchange for that exact block height.
A valid Merkle tree proves two specific facts. First, it proves the exchange created a data structure containing your specific balance. Second, it proves the exchange holds private keys capable of signing a message from public wallets containing a set quantity of assets. It does not verify whether those assets are unencumbered, nor does it confirm if the exchange omitted user balances from the tree before generating the root hash.
Where this goes wrong
An exchange can forge a passing proof of reserves by creating internal sub-accounts with large negative balances. If the Merkle tree nets a hidden negative 5,000 BTC account against 10,000 BTC in user deposits, the published liability sum appears as 5,000 BTC, making an undercollateralized venue look fully solvent on paper.
The missing liabilities half of the balance sheet
Solvency requires total assets to exceed total liabilities. On-chain addresses verify only the asset side of the equation.
A complete balance sheet requires auditing three distinct liability categories: user spot deposits, open perpetual futures margin obligations, and corporate debt facilities. Most published attestations cover only spot deposits.
Consider an exchange with 10,000 BTC in user spot deposits. The exchange also carries a 2,000 BTC corporate loan owed to an institutional lender and a hidden 1,000 BTC margin deficit from liquidated accounts. Total liabilities equal 13,000 BTC.
If the exchange holds 10,000 BTC in on-chain cold wallets, a standard attestation reports assets of 10,000 BTC against liabilities of 10,000 BTC. The asset-to-liability ratio appears as 100%. In reality, total liabilities are 13,000 BTC, meaning the venue holds only 76.9% of the assets required to cover its total obligations.
Worth knowing
On-chain signatures only prove key possession at the snapshot block. They do not prevent the venue from using those same assets as collateral for off-chain rehypothecation contracts three minutes after the snapshot closes.
How snapshot tricks obscure real backing ratios
Static quarterly snapshots incentivize balance sheet manipulation. Because attestations occur at pre-announced block heights, venues can borrow funds temporarily to inflate reported reserves.
An undercapitalized exchange holding 8,000 BTC against 10,000 BTC of user obligations faces a 2,000 BTC shortfall. To pass an upcoming snapshot at block height 800,000, the exchange borrows 2,000 BTC from an over-the-counter credit facility at 23:50 UTC.
The lender transfers 2,000 BTC to the exchange wallet. At 00:00 UTC, the snapshot captures 10,000 BTC in on-chain reserves. The exchange signs the verification message, proves 100% backing, and returns the 2,000 BTC to the lender at 00:10 UTC. The loan fee for twenty minutes of capital equals a fraction of a percent, while the published attestation claims full backing for the next ninety days.
| Attestation Model | Asset Verification Method | Liability Scope Covered | Snapshot Borrowing Risk |
|---|---|---|---|
| Self-Reported Snapshot | Unsigned address lists | User spot balances only | High (unmonitored timing) |
| Merkle Tree + Signatures | Cryptographic key signing | User spot balances only | High (block-specific loans) |
| Third-Party Attestation | Auditor verified keys | Spot and futures accounts | Medium (periodic sampling) |
| Continuous Zero-Knowledge | Real-time ZK proofs | All account states and margin | Low (automated state updates) |
Evaluating attestation quality across perpetual venues
When choosing where to hold perpetual futures positions, evaluate the technical structure of a venue's reserve reports rather than marketing press releases.
Look for four criteria in an attestation:
- Cryptographic message signing. The venue must sign a unique string with the private keys of declared cold wallets at the exact snapshot block. Address lists without signatures prove nothing.
- Complete inclusion of margin accounts. Futures positions generate dynamic equity changes. The attestation must include realized and unrealized profit liabilities alongside spot deposits.
- Zero-knowledge liability proofs. Advanced implementations use ZK-SNARKs to prove every user leaf is positive, preventing the venue from hiding negative sub-accounts while preserving account privacy.
- Frequency of publication. A static quarterly report leaves a 90-day window for unmonitored capital movements. Venues providing daily or real-time cryptographic updates eliminate snapshot borrowing tactics.
What to do instead
Verify your individual hash directly in the Merkle tree after every published snapshot, and reject attestations that do not explicitly state that negative user balances are excluded from the total liability calculation.
What does a proof of reserves attestation actually prove?
It proves that an exchange possessed the private keys for specific on-chain wallets at a set block height, and that your account balance was included in the published Merkle tree root. It does not prove that those assets are free from off-chain loans or that total liabilities were accurately disclosed.
How can an exchange fake a proof of reserves report?
An exchange can borrow assets right before the snapshot block to temporarily inflate wallet balances, or create internal sub-accounts with hidden negative balances to artificially reduce reported user liabilities.
What is the difference between a proof of reserves and a full financial audit?
A proof of reserves is a point-in-time snapshot of on-chain asset ownership versus reported user balances. A full financial audit evaluates off-balance-sheet debt, corporate loans, operational expenses, and internal controls over an extended accounting period.
Why are perpetual futures liabilities harder to verify than spot balances?
Perpetual futures balances fluctuate continuously based on unrealized profit, unrealized loss, leverage, and position funding settlements. Verifying perps requires auditing dynamic margin requirements across all active positions rather than static wallet deposits.