You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
How Does Proof of Reserves Work?
Proof of Reserves works by having an exchange sign a message that confirms it holds a certain amount of crypto. This message is usually a cryptographic hash that contains the following:
- The exchange’s public address
- The amount of cryptocurrency held in the address
- The date the message was signed
The exchange can then share this message with its users, who can verify that the exchange has the requisite amount of cryptoassets to cover its liabilities.
To elaborate a bit further, custodial institutions in crypto typically use a hot wallet for day-to-day operations, such as fulfilling withdrawal requests from users, and a cold wallet for long-term storage and security of a portion of users' deposits. Users are typically given a unique wallet address to make deposits, which are then moved between the hot and cold wallets as necessary.
While details of the institution-held assets can be partly obtained by tracing the details of transactions involving their hot and cold wallets, this only presents an aggregated view of the total assets in custody and doesn't provide any information about which users own what portion of the total assets.
A PoR audit involves a deeper study to collate the total assets held by the institution and prove that the institution holds the appropriate amount of assets to cover the users' deposits. This process typically uses Merkle tree technology, which creates a hash tree to organize and verify the data’s integrity. By publishing a Merkle root of the users' balances on-chain, a custodial institution can provide proof of the amount of assets it holds on behalf of its users, while still preserving the anonymity of individual user account balances.
What is a Merkle Tree?
A Merkle Tree is a data structuring approach that ensures the verifiability of stored data while simplifying data access. It partitions related data in a manner that gives an individual data access without going through each branch of data. The Merkle tree groups distinct data into autonomous branches connected to a single root known as the Merkle root. The Merkle root acts as the single point of connection for the data branches and ensures the right information is stored in each branch. It also provides a uniform protection system for stored data, preventing data manipulation or damage.
Merkle trees are a core component of blockchains, the main data management method used to keep track of the growing data set generated by network users. Each block added to the chain is identified with a hash and the Merkle tree stores and identifies the data according to their hash, eliminating the need to compute the whole blocks in the network.
In a Proof of Reserve, a mini Merkle tree records an exchange's assets and liabilities on-chain. To verify the records, an auditor takes a periodic record of an institution's asset in custody and arranges the individual data in the record using a Merkle tree. The PoR focuses on the amount of customer deposits locked in the exchange, whether the exchange as a custodian can access the funds, and whether customer deposits are included in the exchange’s assets.
The Merkle tree mechanism is deployed to reconcile customer deposits and assets of an exchange, while hash encryption ensures customers' personal information remains indecipherable. During the verification process, an auditor takes a snapshot of all balances held by the exchange and customers, creates a Merkle tree, and then customers check the ownership and receive part of the data required for verification from the Merkle tree. The verification process is completed by comparing the data to the hash values of the reserve and confirming the match of the values.
A Proof of Reserve, which proves the number of assets an exchange actually owns, is ultimately incomplete without a corresponding proof of liability, which proves the amount of debt an exchange claims to owe. When executed properly, these two proofs together can serve as conditional proof of solvency.
The Merkle approach, formalized by Greg Maxwell and Peter Todd, is the first method to prove solvency. It enables exchange users to verify that their balance is included in the list of all customer balances that the exchange publishes in their attestation. The Merkle approach consists of two parts: proving what an exchange owes and demonstrating what an exchange owns.
Proving reserves is relatively easy as the exchange signs a transaction with all of its unspent transaction outputs (UTXOs), which allows everyone to see the amount of Bitcoin the exchange owns. However, proving what an exchange owes is more challenging as this requires the use of a Merkle tree. The Merkle tree enables users to verify that their accounts and balances are included in the final hash without leaking the details of everyone’s balances and account information. By verifying their balance, users can have strong assurances that the exchange isn't lying.
The privacy issues associated with the Merkle approach prompted Dagher et al. to publish Provisions in 2015, which provides privacy-preserving proofs of solvency for Bitcoin exchanges. Provisions consist of three protocols: proof of assets, proof of liability, and proof of solvency. Proof of assets enables the exchange to prove that it owns a certain number of BTC without revealing that number.
Proof of liability commits the exchange to the total sum of user balances while allowing depositors to privately verify that the exchange is committing to the right balance. Proof of solvency allows the exchange to prove in zero-knowledge that the proof of assets and liability equals zero without revealing the exchange's balance. This approach improves upon the Merkle approach, as it outputs a simple 1 or 0, indicating whether the exchange is solvent or not, without revealing the exchange's balance.
The Merkle approach to proving solvency has a limitation in that it exposes an exchange's liability, with which some exchanges may not be comfortable. To address this issue, in 2015, Dagher, Bunz, Bonneau, Clark, and Boneh proposed Provisions, a privacy-preserving proof of solvency for Bitcoin exchanges. Provisions allow an exchange to prove that it owns sufficient Bitcoin to cover all its customers' balances while preserving the confidentiality of customer accounts and not revealing the exchange's total liabilities or assets or Bitcoin addresses.
Provisions comprise three protocols: Proof of assets/reserves, Proof of liability, and Proof of solvency. The exchange uses zero-knowledge proof (ZKP) techniques to prove that it owns a certain number of BTC without disclosing that number. Additionally, the exchange commits to the total sum of user balances, allowing depositors to privately verify that the exchange is committing to the correct balance.
Finally, the exchange proves in zero-knowledge that the proof of assets and liability sum to zero, indicating that the exchange is solvent. This approach is superior to the Merkle + sign message approach because it does not leak the exchange's balance, outputting a simple 1 or 0 indicating the exchange's solvency status.
How is a PoR Audit Actually Conducted?
In the Bitcoin protocol, transactions are paired and hashed until only a single hash value, called the Merkle Root, remains. This Merkle Root is incorporated into the block header of a Bitcoin block, streamlining the verification process.
The Merkle Approach integrates a user balance and a hashed user Account ID as primary data blocks. It uses the SHA256 hashing algorithm to create a digest of concatenated values and a random nonce for privacy. The balance is crucial for verifying liabilities, preventing malicious digital asset platforms from pairing customers with identical account balances and offering different tree versions to each.
Merkle Proof is a tool that enables management, consultants, and/or CPA auditors to invite customers to confirm their account and on-platform balance inclusion in the platform's Proof of Reserves calculation. It consolidates extensive data into a single alphanumeric hashed string, allowing users to verify their input's inclusion in the Merkle Root Hash. This customer participation method preserves privacy and enables customers to verify their individual claims on a digital asset platform.
Example
The external CPA auditor-assisted Merkleized liability proof process consists of three stages. First, the auditor creates the Merkle tree with user balances supplied by the digital asset platform. Second, the auditor confirms the total user balance and shares the Merkle tree and root hash. Finally, users independently validate their account balances using a Merkle verification tool.
For instance, Gate.io builds their Merkle trees using two components: user ID ("UID") and balance, which are initially hashed and then combined to form the leaf nodes. Gate.io excludes a nonce value when defining a Merkle tree's leaf nodes.
During an actual attestation, Gate.io supplies the auditor with user balances, which are incorporated into an HTML file to generate the Merkle tree. The auditor then validates the Merkle Root, user count, and total user balances, and publishes the plaintext Merkle tree for customer verification.
Customers are encouraged to participate in verifying their account and balance inclusion in the Merkle Approach by importing the plaintext file into a verified HTML file provided by Gate.io. Additionally, customers must submit their hashed UID and balance at the time of the Proof of Reserves evaluation. The Merkle tree's root is recalculated using the imported file, allowing the customer to confirm the hash's accuracy.
