What is a Proof of Reserve?

A Proof of Reserves (PoR) is an independent audit that is carried out by a third party. The purpose of a PoR is to verify that a custodian actually possesses the assets that it claims to retain on behalf of its customers. This auditor compiles all client balance information into a Merkle tree, which is a data structure that is respectful of clients’ right to privacy and which contains a snapshot of all customer balances that have been anonymized.

The auditor then acquires a Merkle Root, which is a form of cryptographic fingerprinting that provides a one-of-a-kind identifier for the combination of these balances at the moment that the snapshot was produced.

The auditor will then gather digital signatures generated by the cryptocurrency exchange. These signatures are used to demonstrate ownership over on-chain addresses that have balances that are publicly observable. In the last step, the auditor does a comparison and checks that these balances are more than or equal to the client balances that are reflected in the Merkle tree. This confirms that the client assets are stored on a basis that utilizes the whole reserve.

By comparing specific bits of data with the Merkle root, each and every customer has the ability to independently verify that their amount was taken into account during the Proof of Reserves audit. Any alterations made to the remaining data, no matter how minute, will have an effect on the root, which will make any tampering clear.

Why is Proof of Reserves so important?

Banks are regulated and compelled by government authorities to report how much assets they have in their annual reports so that customer funds are not jeopardized. However, because cryptocurrency exchanges and custodians are not regulated by the government, how can users have confidence in their services?

At the moment, the vast majority of centralized exchanges and other CeFi cryptocurrency platforms, such as lenders and custodians, store the information on their assets in confidential, proprietary databases. As a result, they are able to claim that the cash belonging to their users are secure with them, but it is impossible to verify these statements.

Customers don’t just have to take their word for it when they use a Proof of Reserve since they have undeniable confirmation of that promise. This goes back to the fundamental principle of cryptography, which is “Don’t trust, verify.”

The use of proof-of-reserve helps to guarantee that cryptocurrency custodians, exchanges, and lenders do not participate in financial transactions in secret, which may put the funds of their clients at danger.

Proof-of-reserve assures that a cryptocurrency lender does not loan out more money than the collateral it has, which enables its lenders to be reimbursed in full in the event that anything unexpected takes place.

Proof-of-reserve assures that a custodian of wrapped tokens, such as WBTC (wrapped Bitcoin), truly has the bitcoins in reserve. Similarly, it ensures that stablecoin issuers, such as Circle, genuinely have the USD to back all of the USDC that it issues.

How Does a Merkle Tree Proof-of-Reserve Work?

The “Merkle Tree,” sometimes known as a “hash tree,” is the component that ensures the success of the Proof of Reserve protocol. Verification of assets held in reserve can be carried out using a tamper-proof and cryptographically secure approach with the use of a Merkle Tree (see below section for a more detailed explanation on how it works).

Because it is a data structure that is based on a hash, it is extremely sensitive to even the most minute changes and may thus be used to protect against data fraud and manipulation.

An unaffiliated third party is responsible for carrying out the Merkle Tree Proof of Reserve (PoR), as was previously indicated. The operation is as follows:

1. The independent auditor begins by compiling all of the user balances that are kept on a cryptocurrency exchange into a Merkle Tree after taking a snapshot of all of the user balances.

2. A cryptographic hash function is used to this enormous data collection. A cryptographic hash function is a computer algorithm that scrambles data and spits it out as just one single, 64-character string, such as the following: 3537fkhjtyti67182njkaurghcryrgsjakektio9101sjrrlgekb1644afffnd25.

3. The auditor will collect the digital signatures from the exchange that reveal the total balances it has and will then check to see whether they match the balances that are recorded in the Merkle tree for the users. The phrase “proof-of-reserve” comes from the fact that this demonstrates that all user assets are stored in the reserve of the exchange and consequently that all users’ trading money are also stored there.

4. The user can subsequently verify that his assets were accounted for in the Proof of Reserves audit using a unique record ID and comparing it with the Merkle root.

5. If there was any change to his asset balance, no matter how small, or it is a fake balance, it would result in a change that cascades up the tree to the Merkle root and changes the value completely.

6. The user can subsequently verify that his assets were accounted for in the Proof of Reserves audit using a

The Merkle Tree is the single value that establishes the integrity of all of the transactions by making even the tiniest amount of tampering evident. As such, the Merkle Tree is a value that proves the integrity of all of the transactions.

Limitations of Proof of Reserve

The goal here is to demonstrate to the broader public, and more specifically to the people who have placed deposits with you, that the amount of your cryptocurrency that is kept on deposit corresponds with user balances. Of course, when you put this into reality, you’ll find that it’s not quite so easy. It is not difficult to demonstrate that you are in charge of certain cash on chain; nevertheless, if you need those funds in the near term, you can always borrow them. Because of this, point-in-time attestations don’t carry a whole lot of weight. In addition, exchanges run the risk of having concealed liabilities or of having debtors claim priority over depositors, particularly if they do not lawfully separate customer assets on the platform where they operate.

In the process of auditing and verifying funds, having proof of reserve does ensure some transparency. However, there are a few things about it that could be improved reserve does ensure transparency. However, there are a few things about it that could be improved. Even if Proof of Reserve is able to demonstrate control over on-chain data as well as the cash that is being kept, it is not able to verify that an individual is the only owner of a private key.

There is also the potential for the auditor and the auditee to work together to commit fraud. On the other hand, the obligation to maintain openness rests equally with both parties. Discrepancies may also be represented by the loss of keys and the theft of cash. The Proof of Reserves method is also unable to determine if an exchange has borrowed funds in order to pass an audit. This may reflect inconsistencies that occurred during the verification process. To accurately paint the full picture the Proof of Reserves should preferably be combined with some form of Proof of Liabilities.

Proof of Reserves + Proof of Liability = Proof of Solvency

What is Proof of Liabilities?

In comparison to a Proof of Reserves, a Proof of Liabilities is a far more complicated concept. The combination of these two proofs, however, can provide what is known as a Proof of Solvency, at least with regard to a certain token.

Along the same lines as the Proof of Reserves, an exchange may choose to publish a list of all of the liabilities that exist at a certain point in time. This list may, in theory, include the account balance as well as the name of each creditor (for further explanation of the reasons why this is not practicable due to privacy concerns, see below). However, an exchange might easily exclude some obligations from the list, giving the impression that the firm is solvent despite the fact that it is truly in a position where it is insolvent.

There is the suggestion that each and every individual creditor should look through the public list of obligations and check to see whether they are included in it as a means of mitigating the effects of this issue. The possibility exists that the public will view the transaction as fraudulent if even a single creditor asserts that they are not included on the list. The fact that some of the creditors do not verify the list is a concern, of course. However, this approach is likely to be quite resilient, which means that consumers may have much greater certainty regarding the solvency of the exchange when compared to platforms that do not undertake this procedure at all. This is in contrast to platforms that do not conduct this process at all.

The methods described above is obviously highly detrimental to the users’ right to privacy, given that the general public would be aware of each user’s name and the history of their account balance. Before this study was released, there were two approaches that, when used in conjunction with one another, may significantly increase the user’s ability to maintain their privacy. Around the year 2014, Greg Maxwell was the first person to articulate both of these concepts.

1. Obfuscating the relationship between published balances and user identities – The user’s account name might be omitted from the list; in its place, the list may contain a hash of the user’s name or email address conjugated with a random nonce that is issued to each user. An individual user would have the ability to guarantee that they were featured on the list without their name being disclosed to the general public in this manner.

2. Publication of user balances in part – The full list of liabilities is not made public; rather, the liabilities are presented in the form of leaves arranged in a Merkle tree structure. The total liabilities of the exchange are displayed at the top of the Merkle tree, and the hash at the top of the Merkle tree is made public. After that, the bare minimum of information required to go from the user’s account balance to the beginning of the Merkle tree is presented to the user. As a result, every user may have a high degree of trust that their balance is included in the total, while simultaneously acquiring very little information about the other users in the system.