Merkle Mountain Belt (MMB)

1d 6hrs ago

Deciding

Content

AI Summary

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

340'198 USDC until completion of all milestones, and
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!

Request

≈94.94KUSDC

≈23.73KUSDC

≈15.82KUSDC

≈118.67KUSDC

≈87.03KUSDC

Status

Decision28d

Confirmation

Attempts

Tally

39.4%Aye

60.6%Nay

Aye

≈13.44MDOT

Nay

≈20.69MDOT

0.0%
0.0%
Threshold
0.0%

Support

0.16%

≈2.48MDOT

Issuance

≈1.59BDOT

Votes

Nested

Flattened

Actions

Or do delegation here, check wiki.

Call

Metadata

Timeline3

Votes Bubble

Statistics

Comments

12mP...Eyoh

PolkaWorld votes NAY

We truly appreciate the team’s contributions and acknowledge the significance of the work that has been delivered. However, we believe that the previously approved $340,198 USDC already reflects the value of those contributions, and that requesting additional incentives on top of this amount may not be appropriate.

In our view, if a proposal has been funded by the Treasury, it already serves as recognition of its importance and utility. Additional rewards beyond the initial funding risk setting a precedent that may be difficult to sustain.

Moreover, for a two-person team over 11 months, the total amount requested already implies a relatively high compensation. Based on our internal guidelines, PolkaWorld does not support proposals that exceed an effective hourly rate of $100.

We share this feedback with respect and appreciation for the work completed, and we hope it is received in the constructive spirit in which it’s offered.

You can view our full feedback [here].

13NC...8YFJ

JAM DAO votes NAY on this Proposal

We acknowledge the technical merit of the MMB data structure and its potential to replace MMR, improving efficiency and reducing bridge-related transaction costs. The work is credible, and the collaboration with established figures in the Polkadot research community is a strong endorsement.

However, our vote is ultimately NAY due to the following considerations:

Cost-Benefit Concerns: The proposal requests over $340,000 USDC upfront, with an additional DOT-based bonus contingent on future savings. While the projected savings (~$1M/year) are compelling, Ethereum's evolving gas landscape may reduce the need for such optimization over time, blunting the long-term ROI.

Team Size vs. Budget: For what is essentially a two-person project, the requested budget appears high. While quality work deserves compensation, the scope-to-cost ratio currently feels misaligned with ecosystem funding priorities.

We’re open to supporting future iterations of this proposal, particularly if costs are better calibrated.

13zn...P5ju

Dear Proposer,

Thank you for your proposal. Our first vote on this proposal is ABSTAIN.

The Medium Spender track requires 50% quorum (at least 5 aye votes) and simple majority of non-abstain votes according to our voting policy v0.2, and any referendum in which the majority of members vote abstain receives an abstain vote. This proposal has received zero aye and one nay votes from ten available members, with six members abstaining. Below is a summary of our members' comments:

The comments reflected a cautious stance with uncertainties regarding the proposal’s technical merits and overall benefits. One voter had rejected the proposal pending a review by a dedicated fellowship, while others expressed reservations and a desire for further expert feedback from technical teams and renowned figures in the field. Several members highlighted their lack of expertise in the matter and indicated that their stance could change if more detailed clarifications emerged. Overall, the discussion revealed that additional technical analysis and confirmation of the proposal’s advantages were deemed necessary before any definitive support could be offered.

The full discussion can be found in our internal voting.

Please feel free to contact us through the links below for further discussion.

Kind regards,
Permanence DAO
Decentralized Voices Cohort IV Delegate

📅 Book Office Hours
💬 Public Telegram
🌐️ Web
🐦 Twitter
🗳️ Delegate

16Zi...r6x4

This will save all DOT holders transactions fee's, team has good experience, Aye!
~ flipchan

12ao...Wdv8

Protocol-level improvements that reduce transaction costs for users of bridges like Snowbridge and Hyperbridge are exactly the kind of investments the Treasury should be making. As these savings compound over time, it is a meaningful investment to make.

The team behind this proposal is well-known in the ecosystem and has a track record of impactful contributions. The cost is reasonable, given the expertise and experience required to implement such a fundamental part of the protocol.

As a Fellowship member actively working on bridges (Snowbridge), I can testify to the benefits of implementing this feature. The MMB’s design offers a clear and technically sound path to meaningful cost reductions.

I fully support this proposal and look forward to seeing its integration improve the efficiency and accessibility of trustless bridging in Polkadot.

1333...t7nM

I've had many discussions with rob & allistair on the performance improvements MMBs bring to cross-chain messaging. They are indeed a significant improvement over merkle mountain ranges and will only make bridgehub, xcmp & hyperbridge more efficient in one fell swoop.

I fully support this proposal

121d...GFvz

As Lead engineer on Parity's Bridges team, I confirm that upgrading BEEFY MMR to BEEFY MMB will have measurable positive impact on Snowbridge, Hyperbridge, Polkadot<>Kusama bridge as well as any future trustless bridges.

The cost is reasonable, given the expertise and experience required to formalize, implement and integrate this technology. I trust the team (Alfonso & Robert) to deliver the upgrade.

I also like that they split the funding in their proposal request into initial payment plus a completion payment dependent on measurable ecosystem savings. This provides clear incentivizes to not just develop the technology but actually apply it to Polkadot products and make it successful. I would like to see more of this success-driven funding model throughout OpenGov.