This article explores the cryptographic methods that centralized exchanges (CEXs) can use to prove their solvency, moving beyond traditional audits and regulatory assurances to more transparent, verifiable systems. We'll examine historical attempts, their limitations, and newer approaches leveraging advanced technologies like ZK-SNARKs.
Balance Sheets and Merkle Trees: Traditional Proof of Solvency
Early efforts by exchanges to cryptographically prove they weren't defrauding users date back over a decade. In 2011, MtGox, then the largest Bitcoin exchange, proved it held funds by moving 424,242 BTC to a pre-announced address. By 2013, discussions began about proving the other side of the equation: the total size of customer deposits.
If you prove customer deposits equal X (liability proof) and demonstrate ownership of private keys controlling X coins (asset proof), you have proof of solvency. The exchange shows it has enough funds to cover all depositors.
The simplest way to prove deposits is to publish a list of (username, balance) pairs. Each user checks if their balance is included, and anyone can verify the entire list to ensure all balances are non-negative and sum to the correct total. This approach, however, sacrifices privacy.
To improve privacy, exchanges can publish a list of (hash(username, salt), balance) pairs, sending each user their salt privately. But even this leaks information. The desire for greater privacy led to the next innovation: Merkle tree technology.
How Merkle Trees Work for Liability Proof
Merkle trees structure customer balances into a Merkle sum tree. Each node is a (balance, hash) pair. Leaf nodes represent individual customer balances and salted username hashes. Higher-level nodes contain the sum of the two balances below them and the hash of those two nodes.
The exchange sends each user a Merkle sum proof—a branch of the tree consisting of sibling nodes along the path from their leaf to the root. This proves their balance is included in the total. A code example can be found here.
Privacy leaks are lower than with a public list but still exist. Attackers controlling multiple accounts can learn significant information about other users. Additionally, exchanges might attempt to insert negative balances to hide shortfalls. However, Merkle sum trees mitigate this: any user verifying their proof would detect an invalid negative balance, making fraud difficult to conceal.
Improving Privacy and Robustness with ZK-SNARKs
ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are a transformative technology for cryptography. They can simplify and enhance privacy in proof-of-liabilities protocols significantly.
Instead of a Merkle tree, we can use a KZG commitment—a polynomial commitment scheme that allows efficient proofs. A ZK-SNARK can prove that all balances in the commitment are non-negative and sum to a claimed value, without revealing any individual balances.
This approach eliminates privacy leaks since no sister nodes are disclosed; only a cryptographic proof is provided. We can design a special-purpose ZK-SNARK to enforce these constraints. For instance, we can use a polynomial to represent balances and running totals, ensuring the sum matches the declared total and all balances are non-negative.
With additional constraints, this system can handle more complex scenarios, like leveraged trading, where negative balances might be allowed if users have sufficient collateral. A SNARK can prove that the exchange isn’t secretly exempting certain users from rules, thus protecting all depositors.
In the future, ZK liability proofs could extend beyond exchanges to broader lending systems. Borrowers might provide ZK proofs that they haven’t over-extended themselves, and legal innovations could prioritize loans committed this way.
Proof of Assets
The simplest proof of assets involves moving coins to a pre-agreed address or signing a message with the address’s private key. But this faces two practical challenges:
- Cold Storage Handling: Most exchanges keep funds offline for security. Manually signing messages for proof is cumbersome and expensive.
- Collateral Reuse: Exchanges might temporarily shift collateral between each other to fake solvency.
Solutions for Asset Proof
- Reusable Addresses: Use a few long-term addresses, proving ownership once per address. Simple but limits security and privacy.
- Random Address Audits: Maintain many addresses (even one-time use), and periodically prove ownership of randomly selected ones. This can be automated.
- ZK Proofs for Total Balances: Use zero-knowledge proofs to show the total balance of all addresses without revealing the full set. This enhances privacy.
For fiat currencies, proof of assets relies on traditional trust models: bank statements and audited balance sheets. While not cryptographically verifiable, it’s the best available for fiat.
Alternatively, exchanges can separate crypto and fiat operations. Using asset-backed stablecoins like USDC for liabilities allows free liability proofs (since ERC-20 tokens are on-chain), leaving only asset proofs needed.
Plasma and Validiums: Can We Make CEXs Non-Custodial?
What if we want to prevent exchanges from stealing funds entirely? Early attempts like Plasma (2017-2018) aimed to achieve this by representing balances as individual “coins” in a Merle tree, with roots published on-chain. Transfers required updating the tree correctly.
Plasma faced technical challenges, but modern approaches like validiums (e.g., Starkware) combine ZK-rollups with off-chain data storage. Validiums allow centralized operators to run code while proving correct execution cryptographically. Operators can’t steal funds, though users might lose access if operators disappear.
This illustrates a spectrum of options between fully centralized and decentralized exchanges, offering efficiency with cryptographic safeguards against abuse.
However, a fundamental issue remains: user error. If users lose access to their accounts, exchanges need recovery mechanisms (e.g., email reset, KYC). But granting this power also enables potential theft. The trade-off is inevitable.
Long-term solutions involve self-custody with social recovery wallets and multi-sigs. Short-term, we must choose between convenience and security.
Frequently Asked Questions
What is proof of reserves?
Proof of reserves combines asset proof (showing an exchange holds enough coins) and liability proof (showing customer deposits match those holdings). It assures users the exchange is solvent.
Why use ZK-SNARKs for proof of reserves?
ZK-SNARKs enhance privacy and robustness. They allow exchanges to prove solvency without revealing individual user balances, preventing information leaks and enabling more complex constraints.
Can exchanges fake proof of reserves?
Yes, if they collude to temporarily share collateral or use false data. Real-time proofs and coordinated scheduling between exchanges reduce this risk. Always verify proofs independently.
How do cold wallets affect proof of assets?
Cold wallets make proof of assets challenging since they’re offline. Solutions include reusable addresses, random audits, or ZK proofs for total balances without revealing all addresses.
What’s the difference between validiums and Plasma?
Plasma uses Merkle trees to represent balances on-chain, while validiums use ZK-SNARKs to prove off-chain computations. Validiums offer better scalability and privacy but rely on data availability.
Will centralized exchanges become non-custodial?
In the long term, yes. Advances in wallet recovery and stablecoins may reduce the need for custodial exchanges. For now, proof of reserves improves trust in centralized models.
Conclusion: Toward Better Exchanges
In the short term, we have two exchange categories: custodial (CEXs) and non-custodial (DEXs and validium-based CEXs). Improving custodial exchanges requires robust proof of reserves—both asset and liability proofs. Despite technical challenges, progress is essential, and open-source tools can help all exchanges benefit.
Long-term, we should aim for non-custodial exchanges for crypto, with recovery options at the wallet level, not the exchange. Fiat on-ramps can use asset-backed stablecoins like USDC. While we’re not there yet, each step toward cryptographic verification enhances trust and security in the ecosystem.
👉 Explore advanced cryptographic techniques for securing digital assets and verifying exchanges.