Cobo Co-founder: Flaws in Merkle Tree Proof of Reserves and Improvement Approaches
TechFlow Selected TechFlow Selected
Cobo Co-founder: Flaws in Merkle Tree Proof of Reserves and Improvement Approaches
Two fundamental flaws in the existing Merkle Tree proof of reserves methodology.
Navigating Web3 tides with focused insightsAuthor: Changhao Jiang, Co-founder & CTO of Cobo
Following the collapse of FTX and the resulting erosion of trust in centralized institutions, CZ called on exchanges via Twitter to adopt Merkle Tree-based proof-of-reserves methods to demonstrate they are not misappropriating user assets. Subsequently, multiple exchanges began responding and actively preparing proof-of-reserves to reassure customers their funds are safe. However, the Merkle Tree-based proof-of-reserves method has several fundamental flaws. Specifically, centralized entities can easily circumvent the anti-misappropriation checks this method aims to enforce through various loopholes.
In the following sections, I will outline two fundamental shortcomings of the current Merkle Tree proof-of-reserves approach and propose some ideas for improvement.
How Current Proof-of-Reserves Methods Work
To mitigate information asymmetry between users and centralized institutions, existing proof-of-reserves approaches typically rely on traditional audits—where a trusted third-party auditing firm issues a report verifying that the institution's on-chain asset holdings (proof of reserves) match the sum of user account balances (proof of liabilities).
For proof of liabilities, the centralized institution generates a Merkle Tree containing user account details and their respective asset balances. The Merkle Tree essentially creates an anonymized, tamper-proof snapshot of user balances. Each user can independently compute the hash of their own account and verify whether it is included in the Merkle Tree.
For proof of reserves, the institution must disclose its on-chain addresses and undergo verification. A common practice requires the institution to provide digital signatures proving ownership of those on-chain addresses.
Once the Merkle Tree snapshot and on-chain address ownership are confirmed, auditors compare the total assets on both sides (reserves vs. liabilities) to determine whether user funds have been misappropriated.
Flaws in Current Proof-of-Reserves Methods
1. Possibility of Passing Audits Using Borrowed Funds
One major flaw with current proof-of-reserves is that audits are conducted at specific points in time and often only occur every few months or even years. This allows centralized exchanges the opportunity to temporarily borrow funds during audit periods to cover up any misappropriated user assets.
2. Risk of Collusion with External Parties to Pass Audits
Providing digital signatures does not equate to actual ownership of assets at the corresponding addresses. Centralized institutions could collude with external capital providers who lend their on-chain assets solely for the purpose of passing audits. In fact, the same set of funds could be reused across multiple institutions simultaneously. Current audit methods struggle to detect such fraudulent collusion.
Ideas for Improving Proof-of-Reserves
An ideal proof-of-reserves system should enable real-time verification of both liabilities and reserves by auditors and end users. However, this comes with high operational costs and risks of exposing sensitive user data. With sufficient data, third-party auditors might even infer individual user positions from supposedly anonymized datasets.
To prevent the forgery of reserve proofs during audits without compromising user privacy, I propose the following two key improvements:
1. Randomized Spot Audits
Conducting unpredictable, randomly timed audits would make it extremely difficult for centralized institutions to manipulate account balances or fabricate on-chain asset holdings. This unpredictability also serves as a deterrent against misconduct.
Implementation: Trusted third-party auditors could randomly issue audit requests to the institution. Upon receiving notice, the institution must immediately generate a Merkle Tree reflecting user balances (proof of liabilities) at that exact moment, marked by block height.
2. Accelerating Reserve Proofs Using MPC-TSS
During random audits, institutions must quickly prove their reserves—a significant challenge for platforms like exchanges managing numerous on-chain addresses. Even if most assets are stored in a few primary wallets (e.g., hot or cold wallets), substantial funds may still be scattered across many addresses. Consolidating all these funds into a small number of public addresses within a short timeframe is highly time-consuming, creating a window for illicit borrowing to cover shortfalls.
Is it possible for institutions to prove reserves directly from the actual addresses where assets are held—without first consolidating them? One promising solution lies in Multi-Party Computation Threshold Signature Schemes (MPC-TSS).
In brief, MPC-TSS is an advanced cryptographic technique that splits a private key into two or more shards, encrypted and distributed among multiple parties. These shard holders can jointly sign transactions without ever exchanging or reconstructing the full private key.This MPC-TSS custody technology is exactly what Cobo has recently launched as a product.
Under this model, a third-party auditor (such as a law firm, accounting firm, custodian, trustee, or even a regulatory body) holds one key shard, while the centralized institution holds the remaining shards. By setting the signing threshold to require more than one party, full control over assets remains with the institution. Importantly, to allow the creation of many co-managed addresses, the MPC-TSS scheme must support the BIP32 protocol. With possession of one shard, the auditor can definitively identify the institution’s complete set of on-chain addresses and accurately calculate its total asset holdings at any given block height.
Acknowledgments
I am grateful to my Cobo colleagues—including Discus Fish (Shen Yu), Lily King, Jeanette, Tavia, Linfeng, and Ellaine—for their valuable discussions and constructive feedback during the writing of this article.
If you are interested in Cobo’s MPC WaaS (Wallet-as-a-Service based on Multi-Party Computation Threshold Signature technology for self-custody or co-custody), please contact our customer success team. We’d be happy to discuss Web3 asset custody and secure DeFi deployment solutions with you.
Contact Cobo: https://mpc.cobo.com/mpc-zh
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Cobo
