A Merkle tree is what lets an exchange publish a single short value that commits it to every user balance at once. Each user becomes a leaf, leaves are hashed in pairs upward until one root remains, and any change anywhere below produces a completely different root. That is why a published root is a commitment rather than a promise, and why you can prove your own inclusion without seeing anyone else's data.
The problem a Merkle tree solves
An exchange wants to say something about millions of balances without publishing them. Publishing the list would expose every customer; publishing a total proves nothing, because a total can be assembled from any set of numbers.
What is needed is a value small enough to publish, derived from every balance, and impossible to reconcile with a different set of balances. Then the exchange can commit to the whole set publicly while each user separately verifies that their own row was part of what was committed.
That is exactly the job a Merkle tree does, and it is why this structure rather than a simple hash of a concatenated list. A flat hash would also change if data changed, but it would force you to hold every balance to check it, which defeats the privacy requirement.
The parts, named
| Term | What it is | Why it matters |
|---|---|---|
| Leaf | One user's snapshot balances, hashed | It is the row you personally verify |
| Leaf payload | The exact text hashed to make a leaf | Format differences change the hash |
| Sibling | The other hash needed at each level | These are what your proof file contains |
| Proof path | The siblings from your leaf to the root | It is short even for millions of users |
| Root | The single hash at the top | The value the exchange publishes |
Read the second row twice. A leaf is a hash of a specific string, and if the string is built differently the hash is different, which is why the algorithm version has to be published alongside the root.
How a leaf is built
A leaf is a hash of a short piece of text describing one account at the snapshot moment. That text names the algorithm version, the identifier of the disclosure it belongs to, a record identifier for the account, and the balances in the covered assets.
Two formatting rules do more work than they appear to. Balances are written to a fixed number of decimal places, so the same amount always produces the same text, and the assets appear in a fixed order rather than whatever order a system happened to emit. Without both rules, two implementations would hash the same account differently and independent verification would fail for reasons that have nothing to do with honesty.
The account is identified by a record identifier rather than by anything about you. That is what allows the tree to be publishable in structure while remaining uninformative about who is in it. The published fields around it are covered in how to read a proof of reserves report.
How the tree is built upward
Leaves are combined in pairs. Two hashes are joined into one string and that string is hashed, producing a node one level up; those nodes are paired the same way, and the process repeats until a single value remains.
Order matters at every join, and this is the detail that trips people implementing a verifier. Each step has a left side and a right side, and hashing them in the wrong order produces a different result. A proof file therefore records not only which sibling hash to use at each level but which side it sits on, and your verifier has to respect that instruction rather than sorting the two values.
Because the tree halves at every level, the path from any leaf to the root is short. A set of millions of accounts produces a proof of a few dozen hashes, which is why this check runs instantly on a phone rather than requiring a download of the whole dataset.
Why tampering is detectable
Hash functions have the property that a small change in the input produces an unrelated output. Change one balance by the smallest representable amount and its leaf hash changes completely, its parent changes, and every node on the path up to the root changes with it.
That is what turns publication into commitment. Once the root is public, the exchange cannot revise a balance, insert an account, or drop one without producing a different root. It cannot do it quietly, and it cannot do it for one user without breaking verification for everyone whose path runs through the same branch.
The commitment only binds if the root was published before anyone needed it to be wrong, which is why the timing and the public record of the root matter as much as the mathematics. Running the comparison yourself is covered in how to verify proof of reserves.
Why your neighbours stay private
Your proof path contains hashes of other parts of the tree, and a hash is not reversible into the data it came from. You learn that a sibling exists and what its hash is; you learn nothing about whose balances are underneath it or what they are.
That asymmetry is the whole reason this structure suits the problem. Every user can confirm their own inclusion, and no user learns anything about another, without the exchange having to trust anybody or publish a customer list.
Implementations usually strengthen this further by processing the check locally rather than sending your verification data back to a server. The privacy argument and the verification argument point the same way here, which is unusual and worth noticing.
Where the structure stops helping
A Merkle tree proves membership in a set. It says your row was in the tree whose root was published, and it says nothing whatsoever about whether that set was the right set.
Three limits follow directly. The tree cannot tell you whether every account was included, since an omitted account leaves no trace for the people who remain. It cannot tell you whether the assets exist, which is a separate on-chain claim rather than a property of the structure. And it cannot tell you anything about liabilities beyond the balances that went in, which is the gap discussed in proof of reserves and liabilities.
None of that is a flaw in the cryptography. It is the boundary of what a membership proof can be asked to do, and knowing the boundary is what stops the structure being oversold.
The bottom line
A Merkle tree turns millions of balances into one publishable value, and gives every user a short path proving their own row is under it. Leaves are hashes of fixed-format records, nodes are hashes of pairs, and the concatenation order at each level is part of the specification rather than a detail.
Its strength is that tampering after publication is impossible to hide, and that inclusion can be proven without exposing anyone. Its boundary is that membership is all it proves: whether the set was complete, whether the assets exist, and what the liabilities are all sit outside the tree. For more from Bitbase Academy, keep reading.
Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.
References
[1] Bitbase, Proof of Reserves — monthly disclosure, Merkle root and open-source verifier www.bitbase.com
