As exchanges continue to face challenges ensuring their users' funds are safe, we believe it's time for the industry to acknowledge what is working well and what isn’t. The industry is now adopting Proof of Reserves standards as a necessary progression going forward. Proof of Reserve (PoR) is cryptographic proof provided by an exchange of the amount of funds the exchange holds on-chain. This enables users to self-verify the solvency of an exchange without needing to trust any third-party auditors or accounting reports.
Providing institutional and retail investors access to assets they cannot self-custody is a critical market function. However, their advocates argue that more transparency is preferable to none, regardless of whether proof of reserves can provide the same transparency as non-custodial, blockchain-based platforms. Users may feel safer if they see proof of reserves, but the audit provides an overview of assets held at the platform's associated addresses without divulging the company's liabilities. So the reality is that the proof of reserves allows a platform to show the number of assets it holds, which is not sufficient to calculate its true solvency risk.
Proof of Reserve is only half of the story to ensure solvency: we also need a Proof of Liability (PoL) to ensure certainty around the sum of all account balances. A thorough auditing process for any given crypto exchange can benefit from transparent blockchain properties cryptographically proving that they hold enough funds on-chain to match their liability. When proof of reserve is in place, an exchange can simply publish its wallet addresses - which will give insight into its holdings, providing clear proof of ownership. An example of this is Binance’s latest Commitment To Transparency.
The Real Challenge
So, where does the real challenge lie in proving the correctness of any claimed liability? A solution for this was proposed before the Mt. Gox bankruptcy disaster in 2014, and it hasn’t lost any relevance since. So, how does it work? It basically requires a Merkle tree construction which allows users to prove that their account balance is included in the liability the exchange publishes. The more users run and confirm their proof, the more likely it is that the claimed total liability is correct - or, at least, is not lower. In a Merkle proof, you want to show that your account balance is included, which requires hashing two nodes at each level of the tree. You have only one to start: your hashed account balance plus ID. The other hashes must be provided so users can make their way up to the root.
This liquidity proof uses Merkle summation trees. Without diving into too much technical jargon, let’s look at an example with four account IDs - each carrying a specific amount of ETH: Alice (50), Bob (100), Charlie (150), and David (200).
At the bottom layer of the Merkle tree, the leaves reflect hashes of the balance for each account ID. The intermediate nodes contain the hashes of the child nodes in conjunction with the account balances in the child nodes. The Merkle tree's root is the hash of the child nodes' and the account balances' sum. If Alice wants to prove the inclusion of her balance in the exchange’s published liability, she needs the hash h_6, the balance of Bob (without knowing that it is Bob’s), and for the second layer, she needs the hash h_2 and the balance sum 350 of David and Charlie. This information is provided by the exchange (marked green), and allows Alice to calculate a Merkle proof, i.e. a path up to the root. If the final hash matches the published Merkle root, Alice’s balance is, in fact, included in the total liability.
The shortcomings of PoR and PoL
Although Proof of Reserve and Proof of Liability can greatly improve the current obscurity of balance sheets, they, unfortunately, can't provide 100% guarantees for the correctness of exchanges' claimed numbers. Presented reserve sizes are only snapshots in time and can be faked by short-time borrowings. Ideally, proof of reserve and proof of solvency should be done in almost real-time, but this poses big challenges for exchanges holding their funds in cold storage. Moreover, this means these numbers can never be fully trusted since keys might be lost or accounts confiscated or hacked.
On the liability side, without having all users run their proof, there is no 100% guarantee that some (important) liabilities were excluded in the Merkle tree. Here, having an additional external auditor can increase confidence - but this is based on trust again, something we’ve (again, recently) learned isn’t always the best option in trading. So…
Future of solvency risk: Non-custodial Exchanges
The future of cryptocurrency exchanges will require a design that completely prohibits them from mishandling user funds by enabling users to self-custody their assets while using the exchange. In a permissionless, non-custodial exchange, all deposits remain under the full control of the end user. Users have, by default, a 100% guarantee that their funds are available at all times since they are stored in smart contracts, which can only be handled with the user's full authorization; not even the exchange itself can access the funds. In short, in this model, there is no need for Proof of Reserve and Proof of Liabilities. Because users don't have to give custody of their assets to an exchange (or third party), non-custodial exchanges can eliminate solvency risks.