Merkle Proofs in Crypto: How Exchanges Verify Your Balance Without Revealing Everyone Else's

Summary

A Merkle tree is a cryptographic data structure that compresses a large collection of records into a single top-level hash called a Merkle root.

In crypto, Merkle trees are used to efficiently prove that a specific transaction or record belongs to a larger data set. In exchange Proof of Reserves, they can allow customers to verify that their account balances were included in a liability snapshot without requiring the exchange to publicly reveal every customer's balance.

But a Merkle proof has an important limitation:

It proves inclusion, not completeness.

A valid proof can show that your record belongs to a particular tree. It does not automatically prove that every customer was included, that the exchange has sufficient assets, or that the exchange is solvent.

Key Facts

What Is a Merkle Tree?

A Merkle tree, also called a hash tree, organizes many pieces of data using cryptographic hashes.

Instead of treating thousands or millions of records separately, the records are repeatedly hashed and combined until only one hash remains.

That final hash is the:

Merkle root

A simplified example looks like this:

                 Merkle Root
                /           \
             Hash AB       Hash CD
             /    \        /    \
          Hash A Hash B  Hash C Hash D
            |      |      |      |
          Data A Data B Data C Data D

Each piece of data sits at the bottom of the tree.

The system hashes those records, combines neighboring hashes, hashes them again, and repeats the process until reaching the root.

Why Is a Merkle Tree Useful?

The main advantage is efficient verification.

Imagine a data set containing:

10,000,000 records

You want to prove that:

Record #5,821,492

belongs to that data set.

Without an efficient data structure, verification could require handling a huge amount of information.

A Merkle tree allows the verifier to use only:

• The relevant record
• A relatively small number of neighboring hashes
• The Merkle root

to check inclusion.

This is why Merkle trees are widely used in cryptographic systems.

What Is a Cryptographic Hash?

A cryptographic hash function converts input data into a fixed-size output.

For example:

Input:
Alice — 1.25 BTC

↓

Hash Function

↓

Hash:
8f34c2...

If the input changes even slightly:

Alice — 1.26 BTC

the resulting hash should change substantially.

This property is important because it makes tampering easier to detect.

Hashing Is Not Encryption

Hashing and encryption are different.

Encryption

Encryption is designed to be reversible with the correct key:

Plaintext
↓
Encryption
↓
Ciphertext
↓
Decryption Key
↓
Plaintext

Hashing

Hashing is generally designed as a one-way transformation:

Data
↓
Hash Function
↓
Hash

A Merkle tree primarily relies on hashing, not ordinary encryption.

How Does a Merkle Tree Work?

Suppose a Proof of Reserves snapshot contains four customer records:

Alice — 1 BTC

Bob — 2 BTC

Carol — 3 BTC

David — 4 BTC

The process can be simplified into several steps.

Step 1: Hash Each Record

Each record becomes a cryptographic hash:

Alice — 1 BTC
↓
Hash A

Bob — 2 BTC
↓
Hash B

Carol — 3 BTC
↓
Hash C

David — 4 BTC
↓
Hash D

These are the bottom-level nodes, commonly called:

leaves

Step 2: Combine Neighboring Hashes

The system combines:

Hash A + Hash B
↓
Hash AB

and:

Hash C + Hash D
↓
Hash CD

Step 3: Create the Merkle Root

The remaining hashes are combined again:

Hash AB + Hash CD
↓
Merkle Root

The final structure becomes:

                 Merkle Root
                /           \
             Hash AB       Hash CD
             /    \        /    \
          Hash A Hash B  Hash C Hash D

The Merkle root acts as a compact cryptographic commitment to the data used to build the tree.

What Is a Merkle Root?

The Merkle root is the top-level hash of the tree.

Instead of repeatedly handling millions of individual records, a system can publish one root corresponding to the committed data set.

Conceptually:

Millions of Records
↓
Merkle Tree
↓
One Merkle Root

If one underlying record changes, the hashes along its path change, which in turn changes the root.

What Happens If One Record Changes?

Suppose Alice's balance changes from:

1 BTC

to:

1.1 BTC

Then:

Alice's Data Changes
↓
Hash A Changes
↓
Hash AB Changes
↓
Merkle Root Changes

This means a previously published root will no longer match the modified data set.

That makes Merkle trees useful for detecting changes to committed data.

What Is a Merkle Leaf?

A Merkle leaf is a record or hash at the bottom of a Merkle tree.

In exchange Proof of Reserves, a leaf may represent information associated with one customer account.

For example:

Account Identifier
+
BTC Balance
+
ETH Balance
+
USDT Balance
↓
Hash
↓
Merkle Leaf

The exact construction differs between PoR implementations.

What Is a Merkle Proof?

A Merkle proof is the information required to prove that a particular leaf belongs to a particular Merkle tree.

It is sometimes called a:

Merkle inclusion proof

or:

Merkle path

The user does not need every record in the tree.

Instead, they need the hashes required to recreate the path from their leaf to the root.

A Simple Merkle Proof Example

Suppose the tree is:

                 Root
                /    \
              AB      CD
             /  \    /  \
            A    B  C    D

Alice corresponds to:

Leaf A

To verify Alice's inclusion, the proof may provide:

Hash B
Hash CD

Alice can calculate:

Hash A + Hash B
↓
Hash AB

then:

Hash AB + Hash CD
↓
Calculated Root

If:

Calculated Root
=
Published Root

the proof succeeds.

What Does a Successful Merkle Proof Mean?

In a Proof of Reserves context, it can support the statement:

This customer record was included in the data set committed to by this Merkle root.

For a user, that can answer:

"Was my balance included in this PoR snapshot?"

That is an important transparency improvement.

But the scope of the claim must remain precise.

What Does a Merkle Proof NOT Mean?

A successful Merkle proof does not mean:

The exchange is safe.

It does not automatically prove:

• Every customer was included
• Every liability was included
• The exchange has sufficient assets
• Reserve wallets belong to the exchange
• Reserve assets are unencumbered
• The company has no other debts
• Customer assets are segregated
• The exchange is solvent

The proof establishes one much narrower fact:

Your record belongs to this committed tree.

Why Do Crypto Exchanges Use Merkle Trees?

A centralized exchange may have millions of customer accounts.

During a Proof of Reserves review, it may want customers to verify that their balances are part of the liability calculation.

But it cannot reasonably publish:

Alice
$500,000

Bob
$28,000

Carol
$4,300,000

for millions of users.

That would expose sensitive financial information.

Merkle trees allow the exchange to create a cryptographic commitment to the data set without publishing all customer balances in plaintext.

How Merkle Trees Fit Into Proof of Reserves

A simplified PoR liability process can look like:

Customer Account Balances
↓
Snapshot
↓
Customer Records
↓
Hashes
↓
Merkle Tree
↓
Merkle Root

Then individual users can receive:

My Account Data
+
Merkle Proof
↓
Verify Against Root

This can make customer-balance inclusion independently verifiable.

Does a Merkle Tree Prove Customer Liabilities?

It helps verify data representing customer liabilities.

But this needs careful wording.

A Merkle tree can prove:

The committed tree contains these records.

It cannot automatically prove:

These records represent every liability the exchange actually has.

That distinction is critical.

Inclusion vs Completeness

This is probably the single most important limitation of Merkle-based PoR.

Inclusion

A user can prove:

My account is in the tree.

Completeness

A much harder question is:

Did the exchange include every account and every liability that should have been included?

An individual Merkle proof cannot answer that second question.

Therefore:

Proof of Inclusion
≠
Proof of Completeness

Can an Exchange Omit Customers From a Merkle Tree?

Technically, the party constructing the tree controls the input data.

Cryptography cannot detect a record that was never supplied as an input unless another part of the verification process establishes that the data set should have contained it.

For example:

Actual Customers
10 million

Included in PoR Data
9.5 million

A mathematically valid Merkle tree could still be built from those 9.5 million records.

The tree itself cannot say:

500,000 additional customers should have been included.

This requires broader liability verification.

Data Integrity vs Data Completeness

Merkle trees are very useful for:

data integrity

because changing a committed record changes the root.

But:

data completeness

is a different problem.

A data set can be:

Cryptographically intact

while still being:

Incomplete

That distinction matters far beyond Proof of Reserves.

Why Are Negative Balances Important in PoR?

Crypto exchanges may offer:

• Margin
• Futures
• Borrowing
• Lending

This creates more complex customer balances.

For example:

Customer A
+10 BTC

Customer B
-8 BTC

A simplistic calculation might produce:

10 + (-8)
=
2 BTC

Depending on the accounting methodology, inappropriate treatment of negative balances could reduce reported liabilities.

That is why sophisticated PoR systems need rules governing how liabilities are calculated.

Can a Basic Merkle Tree Prevent Negative-Balance Manipulation?

Not automatically.

A normal Merkle tree proves:

These committed records produce this root.

It does not inherently enforce:

Every balance must satisfy a particular financial rule.

Additional techniques may be needed to prove those constraints.

What Is a Merkle Sum Tree?

A Merkle sum tree extends the Merkle-tree concept by including numerical sums in the tree.

Instead of each node representing only hashes, nodes can also carry aggregated balance information.

Conceptually:

Leaf A
Balance 5 BTC

Leaf B
Balance 3 BTC

↓

Parent
Total 8 BTC

This can help make liability totals more verifiable.

However, the implementation still needs to address issues such as:

• Negative balances
• Data completeness
• Privacy
• Correct record construction

A Merkle sum tree does not automatically solve every PoR problem.

Why Are Zero-Knowledge Proofs Added?

Zero-knowledge proofs can be used to prove additional mathematical properties without publicly revealing individual customer balances.

For example, a system may try to prove that:

All included balances satisfy rule X

or:

The total was calculated correctly

without publishing each private account balance.

This is why PoR systems can combine:

Merkle Tree
+
Zero-Knowledge Proof

Merkle Tree vs Zero-Knowledge Proof

They perform different functions.

They are complementary technologies.

Does a Merkle Tree Protect Privacy?

It can help, but:

A Merkle tree is not automatically a complete privacy system.

Hashing user data does not guarantee that sensitive information can never be inferred.

For example, if:

• Inputs are predictable
• Balances come from a small set of possibilities
• Identifiers are exposed
• Hash construction is poorly designed

an attacker may be able to infer information.

PoR systems can therefore use techniques such as:

• Random identifiers
• Salts
• Commitments
• Zero-knowledge proofs

to improve privacy.

Is a Merkle Tree Anonymous?

No.

A Merkle tree is a cryptographic data structure.

It is not an anonymity system.

Privacy depends on:

• What is placed in the leaves
• What is publicly disclosed
• How identifiers are generated
• What additional cryptographic methods are used

Why Does Bitcoin Use Merkle Trees?

Merkle trees are not specific to exchanges.

Bitcoin uses them to summarize transactions inside a block.

Transaction identifiers are hashed and combined until one:

Merkle root

remains.

That root is included in the block header.

Conceptually:

Transactions
↓
Transaction Hashes
↓
Merkle Tree
↓
Merkle Root
↓
Block Header

This allows efficient proofs that a transaction was included in a block without requiring every verifier to receive every other transaction as part of that proof.

Merkle Tree vs Blockchain

They are not the same thing.

Merkle Tree

A cryptographic data structure used to commit to and verify collections of data.

Blockchain

A broader distributed ledger structure consisting of ordered blocks linked through cryptographic mechanisms.

A blockchain can:

use Merkle trees as one of its components.

Therefore:

Merkle Tree
≠
Blockchain

Merkle Root vs Block Hash

These are also different.

A Bitcoin block can contain:

Block Header
├── Previous Block Hash
├── Merkle Root
├── Timestamp
├── Difficulty Data
└── Other Header Data

The Merkle root summarizes the transactions in the block.

The block hash identifies the block header itself.

They serve different purposes.

Can a Merkle Proof Be Faked?

A verifier calculates the root using:

• The claimed leaf
• The supplied proof hashes

If the calculated root does not match the trusted published root, verification fails.

This makes it computationally impractical under the security assumptions of the hash function to alter committed data while preserving the same expected root.

However:

Cryptographic verification is only meaningful if the reference root itself is authentic and tied to the correct data set.

What Happens If the Published Merkle Root Is Changed?

If an exchange simply replaces:

Old Root

with:

New Root

it can represent a different data set.

That is why PoR systems benefit from:

• Independent publication
• Third-party verification
• Historical records
• Timestamping
• Transparent methodology

The root is useful because it commits to data.

But users also need confidence in the context in which that root was published.

Can a Merkle Proof Prove the Exchange Has the Crypto?

No.

A liability Merkle tree and reserve assets are separate parts of PoR.

Conceptually:

Merkle Tree
↓
Customer Liabilities

while:

Exchange Wallets
↓
Reserve Assets

need separate verification.

Therefore:

Valid Merkle Proof
≠
Proof of Assets

Can a Merkle Proof Prove Wallet Ownership?

No.

A Merkle proof about customer balances does not prove that the exchange controls reserve wallets.

Wallet control needs separate evidence such as:

• Cryptographic signatures
• Signed messages
• Independent verification

Can a Merkle Proof Prove Solvency?

No.

Even a perfectly constructed liability tree does not necessarily include:

• Corporate loans
• Vendor liabilities
• Tax liabilities
• Legal claims
• Other creditors
• Asset encumbrances

Therefore:

Valid Merkle Tree
≠
Complete Balance Sheet

and:

Valid Merkle Proof
≠
Proof of Solvency

Can a Merkle Proof Prove Customer Assets Are Segregated?

No.

Asset segregation is a legal and operational question.

It asks:

Are customer assets legally separated from the exchange's corporate assets?

A Merkle proof asks:

Was this record included in this committed data set?

These are fundamentally different questions.

How Do Exchange Users Verify a Merkle Proof?

The exact process depends on the exchange.

A typical process can look like this.

Step 1: Find the Relevant PoR Snapshot

Check:

• Snapshot date
• Covered assets
• Verification provider

Step 2: Find Your Verification Data

The exchange may provide:

• Record ID
• Merkle Leaf ID
• Account balance data
• Proof hashes

Step 3: Recreate Your Leaf

The system may allow you to calculate the hash representing your account record.

Step 4: Follow the Merkle Path

Combine your leaf with the sibling hashes supplied by the proof.

Step 5: Calculate the Root

Continue hashing upward until reaching a root.

Step 6: Compare the Result

If:

Calculated Root
=
Published Merkle Root

your record is cryptographically included in that tree.

Real-World Example: Kraken Proof of Reserves

Kraken's current Proof of Reserves process provides a clear example of user-level Merkle verification.

Its PoR methodology takes anonymized client balances and aggregates them into a Merkle tree.

Customers can then use account-specific information, including a Merkle Leaf ID, to verify their path to the Merkle root.

This allows a user to confirm:

My covered balance was included in this particular PoR review.

Importantly, Kraken also explains that the verification applies to:

• In-scope assets
• Balances at the snapshot time

and does not automatically represent transactions occurring after the snapshot or assets outside the review scope.

That distinction is essential when interpreting any Merkle-based PoR.

What Should You Check When an Exchange Says "Merkle Tree Verified"?

Do not stop at the phrase:

Merkle Tree ✓

Ask the following questions.

Can I Verify My Own Account?

If there is no user-level proof, the Merkle tree may provide less direct value to individual customers.

Which Balances Are Included?

Check:

• Which assets
• Which account types
• Which products
• Which snapshot date

Are Liabilities Independently Verified?

A tree can be mathematically valid while the source data is incomplete.

How Are Negative Balances Handled?

This matters for margin, futures and borrowing products.

Is a Merkle Sum Tree or Other Enhanced Method Used?

The methodology matters.

Are ZK Proofs Used?

ZK systems can add constraints that a basic Merkle tree cannot enforce.

Are Reserve Assets Verified Separately?

Customer liability verification is only one side of PoR.

Is the Methodology Public?

Users should be able to understand what the proof actually demonstrates.

Merkle Tree vs Proof of Reserves

So:

A Merkle tree is a tool inside a PoR system, not PoR itself.

Frequently Asked Questions

What is a Merkle tree?

A Merkle tree is a cryptographic hash-based structure used to represent and efficiently verify a large collection of data.

What is a Merkle root?

A Merkle root is the final hash at the top of a Merkle tree and acts as a cryptographic commitment to the data used to construct the tree.

What is a Merkle proof?

A Merkle proof is a set of hashes that allows a verifier to confirm that a particular leaf belongs to a specific Merkle tree.

What is a Merkle leaf?

A Merkle leaf is an individual record or hash at the bottom level of the tree.

What is a Merkle path?

A Merkle path contains the sibling hashes needed to calculate the path from one leaf to the Merkle root.

Why are Merkle trees used in crypto?

They allow large data sets to be represented compactly and support efficient inclusion proofs.

Why does Bitcoin use Merkle trees?

Bitcoin uses a Merkle tree to combine transaction hashes into a Merkle root included in each block header.

Why do crypto exchanges use Merkle trees?

They can use Merkle trees in Proof of Reserves to allow customers to verify that their balances were included in a liability snapshot.

Can I verify my exchange balance with a Merkle proof?

Yes, if the exchange provides user-level verification data and a valid proof path.

Does a Merkle proof reveal other users' balances?

It does not require disclosure of every other customer's plaintext balance.

Does a Merkle tree guarantee privacy?

No. Privacy also depends on how leaves, identifiers and other information are constructed.

Does a Merkle proof prove all customers were included?

No.

Can an exchange omit users from a Merkle tree?

A Merkle tree cannot by itself detect records that were never provided as inputs.

What is a Merkle sum tree?

A Merkle sum tree extends a Merkle tree by including numerical sums in nodes, which can help make aggregated liability totals more verifiable.

Is a Merkle tree the same as a zero-knowledge proof?

No. They are different cryptographic techniques and can be used together.

Does a Merkle proof prove the exchange owns reserve wallets?

No.

Does a Merkle tree prove Proof of Reserves?

It can be one part of a Proof of Reserves system, particularly for liability verification, but it does not replace asset verification.

Does a Merkle proof prove an exchange is solvent?

No.

Is a Merkle tree the same as a blockchain?

No. Blockchains can use Merkle trees as components.

What happens if a record in a Merkle tree changes?

The corresponding leaf hash and hashes above it change, eventually producing a different Merkle root.

Key Takeaway

A Merkle tree gives crypto users something extremely useful:

the ability to verify a specific inclusion claim without seeing the entire underlying data set.

In Proof of Reserves:

My Balance
↓
Merkle Leaf
↓
Merkle Proof
↓
Merkle Root
↓
Verify Inclusion

This can answer:

"Was my balance included in this PoR snapshot?"

But it cannot automatically answer:

Were all customers included?
→ No

Were all liabilities included?
→ Not proven by my inclusion proof

Does the exchange hold enough assets?
→ Requires separate reserve verification

Does the exchange own those assets free of claims?
→ Not proven

Does the exchange have other debts?
→ Not proven

Is the exchange solvent?
→ Not proven

The crucial distinction is:

Merkle Proof
=
Proof of Inclusion

not:

Merkle Proof
=
Proof of Financial Safety

That is the correct way to interpret a Merkle tree when evaluating crypto exchange transparency.