Whenever a major centralized exchange collapses, a common question is whether we can use cryptographic technology to solve the problem. Instead of relying solely on legal avenues such as government licenses, auditor reviews, and background checks on the individuals operating the exchange, exchanges can use cryptography to prove that the funds they hold on-chain are sufficient to cover their liabilities to users. Moreover, exchanges can establish a system in which they cannot withdraw depositor funds without the depositor’s consent. We can explore the boundary between ambitious CEXs that “actively choose not to do wrong” and CEXs that “are incapable of doing wrong,” but at present, people often merely look toward inefficient and privacy-leaking on-chain DEXs.
This article will discuss the attempts to move CEXs one step closer to trustlessness, the limitations of these techniques, and some solutions that rely on advanced technologies such as ZK-SNARKs, as well as more powerful ideas. Balance Sheets and Merkle Trees: Traditional Proof of Solvency The earliest attempts by exchanges to cryptographically prove that they were not deceiving users date back a long time. In 2011, MtGox, then the largest Bitcoin exchange, proved it had funds by sending a transaction that moved 424,242 bitcoins to a pre-announced address. In 2013, discussions began on how to solve the other side of the problem: proving the total size of customer deposits. If you prove that customer deposits equal X (proof of liabilities) and prove ownership of the private keys holding X tokens (proof of assets), then you have a proof of solvency—you have proven that the exchange has the funds to repay all depositors. The simplest way to prove deposits is to simply publish a list of (username, balance) pairs. Each user can check that their balance is included in the list, and anyone can check the full list to see that: – Every balance is non-negative; – The total equals the claimed amount. Of course, this destroys privacy, so we can modify the scheme slightly: – Publish a list of (hash(“username, salt”), balance) pairs, and privately send each user their salt value. But even this leaks balances and patterns of balance changes. To protect privacy, we come to the next invention: Merkle Tree technique Green: the node representing Charlie.Blue: Represents a node that Charlie will receive as part of the proof. Yellow: Represents the root node, which is publicly displayed to everyone. The Merkle tree technique involves placing customer balance tables into a Merkle sum tree. In a Merkle sum tree, each node is a pair of (balance, hash). The bottom leaf nodes represent the username hashes of individual customer balances and salts. At each higher-level node, the balance is the sum of the two balances below, and the hash is the hash of the two nodes below. A Merkle sum proof, like a Merkle proof, is a “branch” of the tree, consisting of the sibling nodes along the path from the leaf to the root. The exchange will send each user a Merkle deposit proof. The user is then given a guarantee that their balance is correctly included as part of the total. A simple example code implementation can be found here. This design leaks far less privacy than a fully public list, and can be further reduced by moving branches each time the “root” is published, but some privacy leakage still exists: Charlie learns that someone has a balance of 164 ETH, that two users’ balances sum to 70 ETH, and so on. An attacker controlling multiple accounts may still be able to learn a significant amount of information about exchange users. An important subtlety of this scheme is the possibility of negative balances: what if an exchange has 1390 ETH in customer balances but only 890 ETH in reserves, and attempts to cover the difference by adding a -500 ETH balance under a fake account somewhere in the tree? It turns out that this possibility does not break the scheme, which is precisely why we need a Merkle sum tree rather than a regular Merkle tree. Suppose Henry is a fake account controlled by the exchange, and the exchange places -500 ETH there: Greta’s proof verification will fail: the exchange would have to give her Henry’s -500 ETH node, and she would reject it as invalid. Eve’s and Fred’s proof verifications will also fail because the intermediate node above Henry has -230 ETH, making it invalid as well. To avoid being caught for misappropriation, the exchange would have to hope that no one on the right half of the tree checks their balance proof. If the exchange can identify users worth 500 ETH whom they believe will either not bother to check the proof or will not be trusted when they complain that they never received a proof, they could potentially avoid being caught for misappropriation.
However, exchanges can also exclude these users from the tree and achieve the same effect. Therefore, if the sole goal is to implement proof of liabilities, Merkle tree technology is essentially as effective as proof-of-liability schemes. Nevertheless, its privacy attributes remain suboptimal. One could employ Merkle trees in a more sophisticated manner, such as making each satoshi or wei an individual leaf, but ultimately, through more modern techniques, there are superior approaches. Improving Privacy and Robustness Using ZK-SNARKs ZK-SNARKs represent a powerful technology. The relationship between ZK-SNARKs and cryptography may resemble that of transformers to artificial intelligence. We can utilize ZK-SNARKs to greatly simplify and enhance privacy in proof-of-liability protocols. The simplest measure we can take is to place all user deposits into a Merkle tree (or, more straightforwardly, a KZG commitment) and employ a ZK-SNARK to prove that all balances in the tree are non-negative and sum to a claimed value. If we add a layer of hashing for privacy, the Merkle branch (or KZG proof) provided to each user will not disclose any other user’s balance. Using KZG commitments is one method to avoid privacy leakage, as it eliminates the need to provide “sibling nodes” as proof, and a simple ZK-SNARK can be used to prove both the sum of balances and that each balance is non-negative. We can construct a dedicated ZK-SNARK to prove the sum and non-negativity of balances within the aforementioned KZG commitment. Here is a simple example. We introduce an auxiliary polynomial I(x), which encodes a portion of each balance (assuming balances are below 2^15), tracking a sum with offsets at every 16 positions, and its sum equals zero only when the actual sum matches the claimed sum. If z is a primitive 128th root of unity, we can prove the following equation: Further explanation of ZK-SNARKs can be found here. With only a few additional equations, such a constraint system can accommodate more complex environments. For instance, in a leveraged trading system, individual users may have negative balances, provided they possess sufficient other assets to cover the funds at a certain collateral maintenance margin. A SNARK can be used to prove this more intricate constraint, reassuring users that the exchange does not risk funds by secretly exempting other users from compliance.
In the longer-term future, this kind of ZK debt proof could be used not only for customer deposits on exchanges, but also for broader lending. Anyone who makes a loan would place a record into a polynomial or a tree containing that loan, and the root of that structure would be published on-chain. This would allow anyone seeking a loan to prove to lenders that they have not already taken on an excessive amount of other loans. Eventually, legal innovation might even make loans committed in this way have a higher priority than loans not so committed. This is exactly in the same direction as an idea discussed in our article “Decentralized Society: Finding Web3’s Soul” — the concept of generating negative reputation on-chain through some form of “soulbound tokens.”
Proof of Assets The simplest version of proof of assets is the protocol we saw above: to prove that you hold X tokens, you simply move X tokens at a pre-agreed time, or move X tokens in a transaction whose data field contains the words “these funds belong to Binance.” To avoid paying transaction fees, you can sign an off-chain message. Both Bitcoin and Ethereum have standards for off-chain signed messages. There are two practical problems with this simple proof-of-assets technique: Cold wallet handling; Collateral reuse. For security reasons, most exchanges keep the vast majority of customer funds in cold wallets. On an offline computer, transactions require manual signing and transfer to the internet. The cold wallet setup I used to use for personal funds required a permanently offline computer to generate a QR code containing the signed transaction, which I then scanned with my phone. Current exchange protocols are even more elaborate, often involving multi-party computation across multiple devices. In such a setup, producing an additional message to prove control of an address is an expensive operation. Exchanges can adopt several approaches: Keep some public long-term addresses. The exchange would generate a few addresses, publish a proof of ownership for each address once, and then reuse those addresses. This is by far the simplest option, although it does add some restrictions on how security and privacy are handled. Have many addresses and prove only a few at random. The exchange would have many addresses, possibly each used only once and then abandoned after a single transaction. In this case, the exchange could have a protocol in which some addresses are randomly selected from time to time and must be “opened” to prove ownership. Some exchanges already do something similar with auditors, but in principle this technique could be turned into a fully automated procedure.More complex ZKP options exist. For example, an exchange could set all of its addresses as 1/2 multisig, where each address has a distinct private key and the other key is a blinded version of some “critical” emergency backup key stored in a complex but secure manner, such as a 12/16 multisig. To protect privacy and avoid revealing all of its addresses, the exchange could even run a zero-knowledge proof on-chain, proving the total balance of all addresses on-chain that have this format.
Another major issue is preventing collateral double-spending. It is easy for exchanges to transfer collateral back and forth between each other to prove reserves, which would allow them to pretend to be solvent when they are actually not. Ideally, proof of solvency should be performed in real time, with an updated proof after every block. If that is impractical, the next best approach is to coordinate among different exchanges on a fixed schedule, for example, proving reserves every Tuesday at 2:00 PM UTC. The final question is: can you prove assets in fiat terms? Exchanges hold not only cryptocurrencies but also fiat currencies within the banking system. In this regard, the answer is yes, but such a procedure will inevitably rely on a “fiat” trust model—the bank itself can certify balances, auditors can certify balance sheets, and so on. Given that fiat cannot be cryptographically verified, this is the best that can be done within that framework, but it is still worth doing. Another approach is to completely separate an entity that operates an exchange handling asset-backed stablecoins (such as USDC) from another entity that handles the cash-in and cash-out process moving between cryptocurrency and the traditional banking system (USDC itself). Because USDC’s “liabilities” are simply on-chain ERC20 tokens, proof of liabilities is “free”—only proof of assets is needed. Plasma and validiums scaling solutions: can we achieve non-custodial CEX? Suppose we want to go further: we do not merely want to prove that an exchange has funds to repay users. Instead, we want to prevent exchanges from misappropriating user funds altogether. The first major attempt was Plasma, a scaling solution popular in the Ethereum research community in 2017 and 2018. Plasma works by splitting balances into a set of independent “tokens,” where each token is assigned an index and located at a specific position in the Merkle tree of a Plasma block.To perform a valid token transfer, a transaction must be placed in the correct position of the root of the tree that has been published on-chain. An oversimplified diagram of one version of Plasma. Tokens are held in a smart contract that enforces the rules of the Plasma protocol upon withdrawal. Since the peak of Plasma discussions in 2018, ZK-SNARKs have become far more applicable to scaling-related use cases. As mentioned above, ZK-SNARKs change everything. A more modern Plasma idea is what Starkware calls a validium: essentially the same as a ZK-rollup, except that data is stored off-chain. This structure can be used in many use cases, including any scenario where a centralized server needs to run some code and prove that it is executing that code correctly. Within the validity period, the operator has no way to steal funds, although depending on the implementation details, if the operator disappears, a certain amount of user funds may become stuck. CEX and DEX are not binary. In practice, they represent a spectrum of choices, including various forms of hybrid centralization, where one can obtain certain advantages such as efficiency while still retaining substantial cryptographic safeguards that prevent abuse by a centralized operator. Handling user errors is also a major issue. By far the most important category of errors is: what should be done if a user forgets their password, loses their device, is hacked, or is otherwise unable to access their account? Exchanges can address this problem. First, through email recovery, and if even that fails, through more complex recovery via KYC. However, in order to resolve these issues, the exchange must have real control over the tokens. In order to have the ability to recover funds from a user’s account for legitimate reasons, the exchange must also have the ability to steal funds from a user’s account for illegitimate reasons. This is an unavoidable trade-off. The ideal long-term solution is to rely on self-custody, supported by technologies such as multi-signature and social recovery wallets to assist users in emergency situations. In the short term, however, there are two clear alternatives with significantly different costs and benefits: Summary: Looking Toward More Advanced Exchanges in the Future In the short term, there are two distinct categories of exchanges: custodial exchanges and non-custodial exchanges. Today, the latter category mainly consists of DEXs like Uniswap. In the future, we may also see cryptographically constrained CEXs, where user funds are held in a validium-like smart contract.
We may also see semi-custodial exchanges, where we trust them to use fiat currency rather than cryptocurrency.
Both types of exchanges will continue to exist, and the simplest backward-compatible way to improve the security of custodial exchanges is to add proof of reserves. This involves a combination of proof of assets and proof of liabilities. There are technical challenges in developing good protocols for both, but we can and should make progress on both fronts as much as possible, and open-source the software and processes as much as possible, so that all exchanges can benefit. In the long run, I hope that we move increasingly closer to all non-custodial exchanges, at least where cryptocurrency is concerned. Wallet recovery will exist, and highly centralized recovery options may be necessary for new users handling small amounts, as well as for institutions that require such arrangements for legal reasons, but this can be done at the wallet layer rather than within the exchange itself. The interaction of magic.link with platforms such as Polymarket is an example of this approach. On the fiat side, the flow between the traditional banking system and the cryptocurrency ecosystem can be accomplished through native cash in-and-out processes for asset-backed stablecoins such as USDC. However, it will take some time before we fully realize this. Disclaimer: This article solely represents the author’s personal views and opinions, and does not represent the views or positions of this platform. All content and opinions are for reference only and do not constitute investment advice. Investors should make their own decisions and trades. The author and this platform shall not bear any responsibility for direct or indirect losses arising from investors’ transactions. Disclaimer: This article is only intended to provide market information. All content and opinions are for reference only and do not constitute investment advice, nor do they represent the views or positions of this platform. Investors should make their own decisions and trades. The author and this platform shall not bear any responsibility for direct or indirect losses arising from investors’ transactions.
