Merkle Mountain Range (MMR)

What Is a Merkle Mountain Range?

A Merkle Mountain Range (MMR) is a hash-based data structure designed for efficiently committing to a growing, potentially unbounded list of elements. Where a standard Merkle tree builds a single balanced binary tree over a fixed dataset, an MMR maintains a collection of perfect binary trees of decreasing size. Each tree is called a "peak," and the collection of peaks at varying heights creates the characteristic mountain range profile.

Peter Todd introduced MMRs around 2012, motivated by reducing the hardware costs of running Bitcoin full nodes and validating growing datasets. His original application was the OpenTimestamps project, where a structure was needed that could continuously absorb new data and produce compact proofs without rebuilding from scratch. Todd later discussed MMR commitments on the bitcoin-dev mailing list in 2016, sparking debate with Bram Cohen about the merits of MMRs versus alternative Merkle constructions.

The key insight behind MMRs is that any positive integer can be expressed as a sum of distinct powers of two. An MMR with n leaves decomposes into perfect binary trees whose sizes correspond to the set bits in the binary representation of n. For example, 13 leaves (binary 1101) produce three peaks: trees of 8, 4, and 1 leaf respectively.

How It Works

MMRs grow by appending elements strictly from left to right. When a new leaf arrives, the structure checks whether it can be merged with an adjacent tree of the same height. If so, a parent node is created, potentially triggering a cascade of merges up to the largest possible tree. This process mirrors binary addition: carrying a 1 when two bits sum to 2.

Appending Elements

Consider building an MMR by appending leaves L0 through L6:

After 4 leaves (binary 100):     After 7 leaves (binary 111):
        N6                               N6       N9   L6
      /    \                            /    \   /  \
    N2      N5                         N2     N5  L4  L5
   /  \   /  \                       /  \  /  \
  L0  L1  L2  L3                     L0  L1 L2  L3

  One peak (height 2)             Three peaks (heights 2, 1, 0)

After 4 leaves, the MMR is a single perfect binary tree with one peak. After 7 leaves, three peaks exist because 7 in binary (111) has three set bits. Adding an 8th leaf would merge all peaks into a single tree of height 3.

Node Storage

Nodes are stored in a flat array using post-order traversal indexing. Every node's height can be computed directly from its position using binary operations, eliminating the need for explicit tree pointers or metadata. The hash of each node includes its position to prevent domain confusion between leaf and internal nodes:

// Leaf node hash
leaf_hash = H(position || data)

// Internal node hash
internal_hash = H(position || left_child_hash || right_child_hash)

Position prefixing is a critical security measure. Without it, an attacker could construct a leaf whose data matches the concatenation of two child hashes, creating a false internal node that passes verification.

Bagging the Peaks

Since an MMR can have multiple peaks (unlike a standard Merkle tree with a single root), the peaks must be combined into a single commitment. This process, called "bagging," iteratively hashes peaks from right to left, prepending the total MMR size:

root = H(size, H(peak_0, H(peak_1, H(peak_2, ... H(peak_k-1, peak_k)))))

Including the size prevents ambiguity between MMRs of different sizes that might share peak hashes. The resulting single hash is the MMR root: a compact commitment to the entire dataset.

Inclusion Proofs

Proving that a specific element exists in an MMR requires:

1. The sibling hashes along the path from the leaf up to its peak (the standard Merkle path within that subtree)
2. The hashes of all other peaks (needed to recompute the bagged root)
3. The total MMR size

A verifier reconstructs the peak hash from the leaf and its sibling path, confirms it matches one of the declared peaks, then bags all peaks to check against the known root. Proof size is O(log n) hashes: at most log(n) sibling nodes plus at most log(n) peak hashes.

MMR vs. Standard Merkle Tree

Both structures provide O(log n) proofs, but they optimize for different workloads:

Standard Merkle trees remain ideal for static commitments like the transaction tree within a single block. MMRs excel when data grows continuously and existing proofs should remain valid after new elements are appended.

Use Cases

Utreexo: Compact UTXO Set Accumulation

Bitcoin's UTXO set grows with every transaction that creates new outputs. As of 2026, the full set consumes multiple gigabytes of storage, creating a barrier for resource-constrained nodes. Utreexo, proposed by Tadge Dryja at MIT's Digital Currency Initiative, uses a Merkle forest closely related to MMRs to compress this data into under 1 kilobyte of peak hashes.

Instead of storing every unspent output, a Utreexo node stores only the forest roots (peaks). Transaction senders attach inclusion proofs for the UTXOs they spend, and the node updates its peaks as outputs are created and consumed. Three draft BIPs for Utreexo were submitted in August 2025, moving the concept from research prototype toward standardization. Note that Utreexo extends the pure MMR model by supporting deletions for spent UTXOs, making it a dynamic accumulator rather than strictly append-only.

Grin and MimbleWimble

Grin was the first production blockchain to use MMRs extensively. The MimbleWimble protocol stores transaction kernels, outputs, and range proofs in separate MMRs. The append-only property combined with pruning makes this particularly efficient: spent outputs can be removed from the output MMR, and the remaining structure remains valid without rebuilding. New nodes can validate the chain from a pruned MMR snapshot rather than replaying the entire transaction history.

FlyClient: Ultra-Light Clients

FlyClient is a light client protocol that uses MMRs to allow clients to verify an entire blockchain's proof-of-work history with logarithmic proof sizes. Block producers maintain an MMR over all past block headers and commit the MMR root in each new block. A light client can then probabilistically sample blocks and verify their inclusion using MMR proofs, rather than downloading every header.

Zcash adopted FlyClient in its Heartwood network upgrade, embedding MMR roots in block headers. Nervos Network implemented a similar scheme through its Extensible Block Header RFC. The approach has also been proposed for Ethereum Classic via ECIP-1055.

OpenTimestamps

Peter Todd's original motivation for MMRs was the OpenTimestamps project, where timestamp digests are accumulated into growing trees. As digests arrive, they are appended to the MMR. A single commitment (the bagged root) proves the existence and ordering of all timestamps in the range. The append-only property guarantees that existing timestamps cannot be modified or removed after being committed.

Why It Matters

As blockchains mature, the datasets they must commit to grow without bound: UTXO sets expand, block header chains lengthen, and audit logs accumulate. Standard Merkle trees force a choice between padding to powers of two (wasting space), rebuilding on every append (wasting computation), or accepting imbalanced trees (complicating proofs). MMRs eliminate this tradeoff by supporting arbitrary growth with efficient appends, compact proofs, and natural pruning.

A 2025 paper accepted at CRYPTO 2025 proved that MMRs are essentially optimal for witness update frequency among cryptographic accumulators with succinct commitments. This theoretical result confirms what practitioners have observed: MMRs provide the best available balance of append efficiency, proof compactness, and implementation simplicity for growing datasets.

For systems like Utreexo that aim to make Bitcoin more accessible by reducing node storage requirements, MMRs are a foundational building block. By compressing gigabytes of UTXO data into a handful of peak hashes, they enable lightweight full validation on devices that could never store the complete dataset.

Risks and Considerations

Proof Size Overhead

MMR inclusion proofs carry a small overhead compared to standard Merkle proofs. In addition to the sibling path within a single subtree, the proof must include all peak hashes for the bagging step. In the worst case, an MMR with n leaves has up to log(n) peaks, effectively doubling the proof size. For most practical applications this remains negligible, but it is a measurable cost in bandwidth-constrained environments.

Implementation Complexity

The position-based indexing scheme, peak-finding algorithms, and bagging procedure add complexity compared to a straightforward Merkle tree implementation. Incorrect position prefixing can introduce second preimage vulnerabilities, and flawed peak validation has led to real-world security issues. The Herodotus cross-chain proof system, for example, required a fix after researchers discovered that intermediate hash nodes could pass peak validation without explicit peak count checks.

Append-Only Limitation

Pure MMRs do not support deletion: once an element is appended, it is part of the structure permanently. Systems that need to remove elements (like Utreexo removing spent UTXOs) must extend the basic MMR model into a dynamic accumulator, adding complexity for update proofs and synchronization. Pruning can reduce storage by discarding leaf data, but the logical structure of the MMR remains unchanged.

Evolving Alternatives

Researchers continue to improve on the MMR concept. The Merkle Mountain Belt (MMB), proposed in 2025, achieves O(1) constant-time appends instead of amortized O(log n) and provides recency-biased proof sizes that favor recent elements. As these alternatives mature, the optimal choice of accumulator may shift for specific use cases, though MMRs remain the most battle-tested option in production blockchain systems.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.