You're running a light client. A counterparty wants proof that a specific transaction exists somewhere in ten thousand blocks of history. You reach for the Merkle proof, find the root you anchored to an hour ago, and realize it's already stale because three new blocks landed while you were looking. Rebuilding the whole tree from scratch is not a solution. It's a punishment.
That's the problem Merkle Mountain Ranges were designed to solve. They solve it well.
An Append-Only Structure That Doesn't Freeze
A Merkle Mountain Range (MMR) is a forest of perfect binary Merkle trees, each a different height, arranged tallest-left to shortest-right. Think of it as a city skyline drawn by someone who only owns a ruler: one tall tower, then a shorter one, then maybe a single story. Each individual tree is "perfect" in the strict sense, meaning every leaf sits at the same depth and every internal node has exactly two children.
When you add a new leaf, nothing gets rebuilt. You append the leaf as a new single-node tree on the right. If the two rightmost trees share a height, you merge them by hashing their roots into a new parent. Then you check again. You keep checking until no two adjacent trees have the same height.
The result accepts new data the way a sorted list accepts a new element: cheaply, locally, without disturbing anything that came before.
A concrete run illustrates the pattern. Start with eight leaves and you get one perfect binary tree of height three. One mountain. Add a ninth leaf and you have that height-three tree plus a lone leaf. Add a tenth and the two lone leaves merge into a height-one tree, giving you a height-three and a height-one. Two mountains. Add an eleventh and you have a height-three, a height-one, and a lone leaf. Three peaks. Eleven in binary is 1011, meaning peaks of height three, one, and zero. That correspondence is not decorative. It is precisely how the structure works.
Producing a Proof Without a Single Root
Here is where the classic Merkle intuition breaks down.
A standard Merkle proof hands you sibling hashes along the path from a leaf to the root. The verifier recomputes upward and checks the result against a known root. Clean, fast, done.
An MMR has no single root. It has several peak hashes, one per tree in the forest. So a proof of inclusion requires two components: first, a standard sibling-path proof from the target leaf up to the root of whichever peak tree contains it; second, the full list of peak hashes. The verifier recomputes the leaf's peak root from the sibling path, then confirms that root appears in the peak list. Presence in the list means presence in the MMR.
To commit the entire MMR state in one hash (useful for block headers), you "bag the peaks": hash all peak hashes together in sequence, right to left. This produces what practitioners call the MMR root or "bagged peaks" hash. It changes with every new leaf appended. Old proofs, though, remain valid. A proof anchored to a particular MMR size holds forever against that size's bagged root, provided the verifier knows how many leaves existed when the proof was generated.
That last clause is the critical distinction from a fixed tree. Inclusion is always relative to a specific MMR size, not a timeless root. Whether that feels like a limitation or a feature depends entirely on your application, though for append-only chains it is plainly the latter.
A Worked Scenario: Two Validators, One Transaction
Call them Mara and Jonas. Both run light clients on a UTXO-based chain that uses an MMR to commit to its full transaction history.
Mara wants to prove to Jonas that a specific coinbase transaction from block 4,200 exists in the chain. At proof time, the MMR holds exactly 10,000 leaves. The bagged-peaks hash for size 10,000 is published in a recent block header Jonas's client has already verified.
Mara's wallet software fetches the sibling-path proof for that transaction's leaf (fourteen hashes, since the relevant peak tree has depth fourteen) plus the five peak hashes comprising the size-10,000 MMR. Total proof: nineteen hashes at 32 bytes each. That is 608 bytes.
Jonas's client recomputes the leaf's peak root from the fourteen sibling hashes, finds it in the five-peak list, recomputes the bagged-peaks hash, and matches it against the block header. No full node required. No re-download of 4,200 blocks.
The chain later grows to 50,000 leaves. Jonas updates his view of the chain tip. Mara's 608-byte proof still validates against the size-10,000 bagged root. It does not expire. It does not require reissuance. The transaction did not move.
Where This Actually Ships
MMRs are not theoretical. Grin, the privacy-focused chain that launched in early 2019, uses them to commit to its UTXO set, kernel set, and range proofs. Each grows monotonically as the chain extends. Grin's design also requires that spent outputs be prunable without invalidating the commitment structure, and MMRs handle both requirements at once: append-only growth and local pruning, without one undermining the other.
The Mimblewimble protocol underlying Grin relies on the property that interior nodes can be pruned once the leaves beneath them are no longer needed, while retaining only the peak hashes to preserve verifiability. Leaf positions become permanent identifiers. A transaction's index in the kernel MMR is a stable reference that survives pruning entirely.
Bitcoin researchers have proposed related structures as a path toward stateless clients, where a full node foregoes storing the entire UTXO set and instead verifies inclusion proofs supplied alongside each transaction. (Utreexo is the most developed proposal in this space, using an accumulator that shares MMR's core intuitions.) Proof-size overhead per transaction is logarithmic in total UTXO count, which stays manageable well into the millions.
The Honest Limits
MMRs are not universally superior to fixed Merkle trees. A few points worth stating with precision.
Proof size grows with MMR size. Logarithmically, yes, but it grows. A proof against an MMR of one million leaves requires roughly twenty sibling hashes; against a billion leaves, thirty. Small in absolute terms, but not a flat cost.
The bagged-peaks root is position-dependent. Two MMRs containing identical leaves in different insertion orders produce different roots. For most blockchain applications, insertion order is semantically meaningful and naturally preserved, so this is rarely a problem in practice. It is, however, worth knowing before you design a system that assumes order-independence.
Verification requires knowing the MMR size at proof time. Without a trusted size anchor (a block header committing to the leaf count, for instance), the proof cannot be verified. Fixed-root trees impose no such requirement. Systems using MMRs must publish size alongside root, and any implementation that omits this detail will produce proofs that are technically well-formed and practically useless.
MMRs also do not support efficient membership proofs for non-leaf data the way some other accumulators do. They are purpose-built for append-only logs where every item holds a permanent position.
Why Append-Only Fits Blockchains
The instinct, on first hearing "no fixed root," is to read it as a weakness. It isn't, and the instinct is worth correcting directly. Blockchains are append-only by design. Transactions do not move. Blocks do not get reordered outside of reorgs, which MMR-based systems handle by rolling back peak state. The entire history is a log, and logs are precisely what MMRs were built for.
A fixed Merkle root over a growing dataset requires either a new root with every addition (invalidating every prior inclusion claim) or a pre-allocated tree of fixed maximum size (which means guessing the future with confidence no engineer should have). Neither scales gracefully at chain depth.
MMRs sidestep both problems. Ask yourself: if your system appends data and never mutates it, why would you want a structure that treats growth as an exceptional event requiring a full rebuild? The mountain range keeps growing. The old peaks do not move. That is not a compromise. That is the correct design for the problem.