Merkle Mountain Belt (MMB)
Beneficiary: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!
Comments (11)
Voting has Started
2
of 3Decision Period
23 / 28 days
Confirmation Period
0 / 4 days
Summary
0%
Aye
0%
Nay
Aye (25)0.0 PAS
Support0.0 PAS
Nay (24)0.0 PAS
Comments (11)
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].
The proposed work is useful and the proposers can credibly do it very well.
It is nice to see a treasury proposal where it is clear when it pays for itself. Note that this would require a mich higher usage of the Ethereum bridge. This is not unreasonable but this is not urgent work for its immediate cost savings. That said, I don't expect Ethereum gas costs to be low in the long run Ethereum's L1 doesn't really have any scaling planned so this will be useful.
The gain from this proposal is that proofs that something happened in Polkadot recently are shorter. While MMBs are only saving us a small number of hashes in proofs, we have use cases like the Ethereum bridge (or any other bridge) for which this saving might be significant. Any apporach to proving what happened on Polkadot needs a state proof, an MMB(or MMR) proof or to put such a proof in a SNARK. State proofs are going to be longer and don't use EVM firendly hashes. Some bridges, like Hyperbridge, will use SNARKs. For thise we'd normally have fixed sized circuits for the SNARK which means that this still benefits from this proposal's bound on the proof length.
JAM could also benefit from MMBs. As of v0.7.0, the gray paper appears to contain only MMRs and they don't appear to be forward bagged, which they would need to be to reduce the proof size of recent appends. If MMBs are added to the gray paper, that would only cover maintaining the commitment, not maintainging the data structure or producing proofs. As such a clear write-up and implementation of all algorithms would still be vey useful to future users of MMBs.
There is still work to be done on the paper to publish it and for a Rust implementation. I don't doubt that this will take time. I would leave it to the community to judge the cost.
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].
The proposed work is useful and the proposers can credibly do it very well.
It is nice to see a treasury proposal where it is clear when it pays for itself. Note that this would require a mich higher usage of the Ethereum bridge. This is not unreasonable but this is not urgent work for its immediate cost savings. That said, I don't expect Ethereum gas costs to be low in the long run Ethereum's L1 doesn't really have any scaling planned so this will be useful.
The gain from this proposal is that proofs that something happened in Polkadot recently are shorter. While MMBs are only saving us a small number of hashes in proofs, we have use cases like the Ethereum bridge (or any other bridge) for which this saving might be significant. Any apporach to proving what happened on Polkadot needs a state proof, an MMB(or MMR) proof or to put such a proof in a SNARK. State proofs are going to be longer and don't use EVM firendly hashes. Some bridges, like Hyperbridge, will use SNARKs. For thise we'd normally have fixed sized circuits for the SNARK which means that this still benefits from this proposal's bound on the proof length.
JAM could also benefit from MMBs. As of v0.7.0, the gray paper appears to contain only MMRs and they don't appear to be forward bagged, which they would need to be to reduce the proof size of recent appends. If MMBs are added to the gray paper, that would only cover maintaining the commitment, not maintainging the data structure or producing proofs. As such a clear write-up and implementation of all algorithms would still be vey useful to future users of MMBs.
There is still work to be done on the paper to publish it and for a Rust implementation. I don't doubt that this will take time. I would leave it to the community to judge the cost.