Merkle Mountain Belt (MMB)

NEW (24 July): for a much simpler explanation of MMB than the full proposal, check out Alfonso's blogpost: https://hackmd.io/@MerkleMountainBelts/Bringing-MMB-to-Polkadot.
NEW (31 July): for answers to questions we've received frequently, please see our FAQ: https://hackmd.io/@MerkleMountainBelts/FAQ

Executive Summary

We propose the Merkle Mountain Belt (MMB) as a novel data structure that improves upon and replaces the Merkle Mountain Range (MMR), such as used in BEEFY. The final deliverables of this proposal are

• a paper preprint on MMB, coauthored with Alistair Stewart (Head of Research at Web3 Foundation), and
• a Rust library implementing MMB.

Once deployed on Polkadot, this library will produce immediate cost savings - estimated to be in the order of a million USD per year - for users of bridges like Snowbridge and Hyperbridge, as well as other potential applications within the Polkadot/JAM ecosystem. The preprint will be submitted to the arXiv public repository.

Timeframe

August 2025 - June 2026 for completion of all milestones.

Requested Funds

1. 340'198 USDC until completion of all milestones, and
2. an additional 42'187 DOT once the savings accrued by the Polkadot/JAM ecosystem exceed the aggregate cost of the proposal.

See the funding section in the full proposal for details and rationale. All requested funds use the Swiss National Bank USD/CHF foreign exchange rate and the 30-day EMA of USD/DOT via Subscan at the date of submission (10. July 2025).

Preimage content can be verified against @MerkleMountainBelts/MMB-Proposal-Preimage, most conveniently using dev.papi.how/extrinsics.

Technical description

The Merkle Mountain Belt (MMB) is a novel type of Merkle structure, from the same family as the hash chain and the Merkle Mountain Range (MMR), which are very common in blockchain protocols, e.g., they are used to commit to block headers in Polkadot and Zcash, respectively. In general, these Merkle structures are used to issue a short public commitment that represents a large database, and then provide a compact proof of the existence of a data entry to a verifier.

To oversimplify, we can say that if most user queries are for data from the latest handful of blocks, the most efficient structure (in terms of proof size) would be a chain, while if most queries tend to be for very old data, the most efficient structure would be an MMR. MMB is "the best of both worlds", with a performance always comparable to the better of these two structures for any query recency. Yet MMB considerably outperforms both the chain and the MMR for queried data that was generated between the last minute and the last day.

In most real-life applications, we naturally observe that users' queries are heavily concentrated over recent events, in the above-mentioned time window (from one minute ago to one day ago). Hence, MMB is specifically designed to reduce the operational and data access costs for them. Examples of use cases in Polkadot include XCMP messages, and the BEEFY commitment to all finalized blocks, which is used in cross-chain bridges. Our cost savings analysis focuses only on the latter use case.

However, we stress that MMB offers potential benefits to light-client protocols of any application, as most of them observe a recency bias in their user queries. In fact, the use of MMB has recently been suggested for JAM, and since mentioned in the gray paper to commit to the set of accumulation outputs.

While MMR maintains a well balanced tree in its structure, MMB keeps a slightly unbalanced tree, so that the leaves that correspond to recently generated data are shallower, closer to the root. In a cross-chain bridge, for example, a user's fees for a message are proportional to the size of the accompanying Merkle proof, and this size in turn depends on the depth of the corresponding leaf in the tree. Hence, shallower leaves means lower fees.

Read more on the MMB features and its structure.

Timeline & Payment details

Our proposal consists of 5 milestones that we anticipate to deliver until June 2026. We will post regular updates of our progress on https://ogtracker.io/.

We show in the image our projected delivery dates. We establish a conservative staggered payment schedule, wherein the payment for each milestone is executed a few weeks after its expected delivery. Naturally, this payment schedule can be modified in the future, e.g., in case we do not deliver a milestone before its scheduled payment.

Notice in particular that 30% of the proposal's cost is only to be paid if and when the library's aggregate savings for the ecosystem have exceeded our proposal's cost. We expect this to occur before May 2028; we have scheduled the corresponding payment for a conservative November 2028 which, again, can be rescheduled if needed.

The team

The members of our team are highly qualified and have worked in Polkadot since pre-mainnet days. Our principal researcher Alfonso Cevallos has a Ph.D. in mathematics and is a co-author of many Polkadot papers, including the 2020 overview paper. Our principal developer Robert Hambrock has been one of the earliest stewards of the Polkadot-Ethereum bridge, going back to its initial W3F grant, design of protocols, and implementation.

More details on ourselves and Cryp GmbH are available here.

Changes against previous referendum attempt

Please see our recent post, where we explain in detail what's different in this referendum relative to our previous attempt.

In summary, the main changes are:

• the commitment to a success reward was removed, and
• the content was significantly reduced, resulting in a 40% cut in the cost of the proposal (measured in our local currency CHF, slighty smaller cut in USD).

The following milestones were removed:

• the publication of the paper in a top computer science conference,
• an analysis of the integration of MMB to other potential use cases in Polkadot beyond bridges, such as XCMP, UTXO-based projects, and FlyClient,
• adding parameters to taylor the structure (and performance) of MMB to any application with a specific distribution of data queries,
• the implementation of increment proofs, which would allow a verifier to detect dishonest behavior from a full node that maintains the MMB, and trigger a slash, and
• the implementation of the "forward-bagged" variant of MMB.

Such milestones may be added to a follow-up referendum in the future. We highlight, however, that the current referendum will deliver very robust milestones: a publication-worthy preprint that fully describes MMB, and an implementation that will start saving transaction fees as soon as it is deployed.

Full version tracking against the previous proposal is available here.

We thank in particular the following people, whose feedback had an important impact on our previous and/or current proposal:

• Alistair Stewart (in particular wrt. trimming scope of the latest proposal),
• Raul Romanutti,
• Saxemberg (preproposal feedback prior to last referendum shared with consent here),
• Parity Bridge Team (in particular Adrian Catangiu),
• Snowfork Team (in particular Vincent Geddes and Aidan Musnitzky),
• Hyperbridge Team (in particular Seun Lanlege),
• Oak Security, and
• AAG regulars

---

For more details, we strongly encourage reading the full proposal, and reaching out to us with questions/feedback either in comments here or in our Telegram group: https://t.me/+b-a0VFO1NZVhZDE0.

We also recommend studying our Sub0 2022 MMB overview talk.

Thank you for reading and happy voting!