100% Proof of Reserves

ZKE launches Merkle Tree-based Proof of Reserves system, a new transparency program that allows its users to directly verify ZKE holdings and the individual assets they deposit on the exchange.

In a centralized trading platform, each user's assets are recorded through a ledger in a database, and it is a self-proving challenge to prove that the platform has intact custody of all users' assets.
ZKE stores the hash of each user's account assets in the leaf nodes of the Merkle tree by means of a Merkle tree. A snapshot of the user's assets is taken every month and can be verified independently by each user.

Unlike full nodes, centralized exchanges (CEXs) do not provide unequivocal proof of funds. In most of these cases, cryptocurrencies are simply sent into a black box, leaving users with little choice but to cross their fingers and trust that their money isn't being misused.

To combat this, CEXs are increasingly creating cryptographic proofs to demonstrate that their on-chain funds are sufficient to cover their users' liabilities, rather than solely relying on government-issued licenses and audits. This attempt to provide public transparency to centralized cryptocurrency reserves through a verifiable auditing practice is called Proof of Reserves.

Proof of Reserves is a means of demonstrating that institutions or exchanges are capable of honoring withdrawals on their platforms at all times. In general, it consists of two parts: a current record of customers' coin deposits (known as Proof of Liabilities), and the pool of coins held within a set of exchange addresses (also known as Proof of Assets). If Proof of Assets > Proof of Liabilities, then the exchange is solvent and can always honor withdrawal requests (Proof of Reserves).

A Merkle tree is a data structure that is created by combining the customer balance and the username hash into a tree structure where each node represents a (hash, balance) pair. Leaf nodes at the bottom of the tree represent individual customer balances and the hashed username. Nodes higher up in the hierarchy have a balance equal to the sum of the two balances below, and the hash is the hash of the two nodes below.

All transactions in a Merkle tree are related and grouped together to obtain a root hash or "root address" (yellow box). This root hash is related to all the other hashes of the tree. The Merkle tree Proof of Liability saves a great deal of time since it is not necessary to verify every transaction in a network. Instead, this method relies only on a subset of data to verify funds, which is why it’s considered the industry gold standard for user fund verification.

How does it work? Based on the Merkle tree above, let's assume that Charlie wants to verify his funds. For this purpose, he does not need to know all Merkle tree entries, just the ones highlighted in blue. As long as Charlie receives the hashed information from David, as well as the hashes of the other two blue blocks, he will be able to verify that his funds indeed are on the exchange –– without the need of any other information.

It is also worth noting that if a hash in a Merkle tree is changed, all the others will also change (root hash). As a result, the authenticity of the information for the entire tree will be invalidated. This feature allows Merkel trees to provide the high level of safety they are known for.

A very important proposition is the non-negativity allowance for leaves. For some reason, if a malicious node with a negative balance were added to the tree, then the neighboring nodes and all nodes above would fail the proof verification. Such a malicious attack can only succeed if no one on the entire side of the tree where the malicious node is checks and verifies their balances.