Encrypted Mempools as Shared Infrastructure for Polkadot
TL;DR:
- The problem: Most parachains have no MEV protection, instead losing value to MEV bots (Hydration alone loses ~$2M/year to MEV).
- Solution: Encrypted mempools as shared infrastructure can prevent front-running and redirect value back to parachains and the treasury (as predictable revenue).
- Question: Is this a problem the community wants solved?
Hey everyone,
I’m Tony, a co-founder of Ideal Labs. Last week we launched the Ideal Network: the first-and-only Verifiable-Randomness-as-a-Service protocol built for (and funded by) the Polkadot ecosystem. This post is to share our vision for the evolution of the IDN and to seek input from the community on solving what we believe is an existential threat to Polkadot’s growth.
The Problem: Polkadot is Losing Value and Users
Let’s start with a fact: If we don’t encrypt the mempool, someone else will profit from Polkadot’s transparency.
Case Study: Hydration’s Exposure:
- Hydation has seen ~$2.2B in trading volume over the past three years with no MEV protection
- with documented frontrunning vulnerabilities
- Even conservative estimates of 0.1% of trading volume lost amounts to ~$2M/year in value extracted.
We can identify active sandwich attackers, like this wallet in block #9819146:
| Extrinsic ID | Action | Asset Flow / Role | Interpretation |
|---|---|---|---|
| 9819146-2 | router (sell) | asset_in: 1000771 asset_out: 10 | Front-Run Buy: The attacker sells a large amount of an asset (1000771) to buy the target asset (10). This transaction executes first and drives up the price of asset 10. |
| 9819146-3 | router (buy) | asset_in: 9 asset_out: 10 | Victim’s Trade: A large trade is executed, buying asset 10. Because of the front-run buy, this transaction is executed at a worse price (higher cost) than the user expected. |
| 9819146-4 | router (sell) | asset_in: 9 asset_out: 10 | Back-Run Sell: The attacker sells their position in asset 10 immediately after the victim’s trade. The victim’s large buy order (9819146-3) drove the price of asset 10 even higher, allowing the attacker’s final sell to realize a profit. |
The Ecosystem Reality: Most Parachains are Unprotected
- Mangata Finance (departed , became Gasp):
- The one parachain with comprehensive MEV protection: Raised $4.2M led by Polychain Capital and spent 3 years building “Themis” consensus that prevented front-running.
- In April 2024, they pivoted entirely to Ethereum’s rollup ecosystem via EigenLayer, citing better opportunities for their cross-chain technology.
- Hyperbridge’s Intents Gateway creates new attack surfaces. Liquidity providers must rebalance inventory across chains where these transactions sit exposed in public mempools, vulnerable to front-running that erodes filler profitability.
- Moonbeam/StellaSwap: “No MEV” marketing applies only to specific cross-chain swap contexts, not general DEX trading.
- Bifrost captures MEV and distributes to treasury, but solution is proprietary and chain-specific
- Hydration, Polkadex, and many others: No protection at all.
Note: There are two types of MEV: “productive”/“good” MEV (e.g. DEX arbitrage is victimless backrunning that makes markets more liquid and tradeable, Bifrost’s liquid staking derivative consistently needs rebalancing), and “parasitic”/“bad” MEV (frontrunning, backrunning, sandwich attacks, etc). We envision a solution that preserves good MEV while eliminating economic attacks.
We see a pattern: Parachains will either develop expensive, custom solutions (and sometimes still leave) or else remain vulnerable. There is no shared infrastructure for mempool privacy. If we don’t address the issue of MEV extractions, the issue can compound:
- User attrition: Users who are continually front-run or sandwiched will take their business elsewhere.
- Centralization Pressure: Economically powerful actors have more opportunity to extract MEV, making them more economically powerful, which is especially concerning in a PoS network.
- Parasitic Value Leakage: Value is extracted from Parachains’ mempools without contributing to their security or availability. Think of MEV as a tax paid by users, but instead of application and infrastructure builders, parachain operators, and DOT holders, it will fund opportunistic searchers and MEV bots.
The Solution: Encrypted Mempools as Shared Infrastructure
From Verifiable Randomness to Encrypted Mempools
We built the Ideal Network to provide low-latency, low-cost verifiable randomness. While this serves as a powerful tool for gaming, DeFi, and coordination protocols, the same underlying cryptography can be used to eliminate MEV, which we believe should be our next focus.
The Vision: Just as MEV-BOOST brought proposer-builder separation to Ethereum, we want to bring encrypted block building to Polkadot, where:
- users pay no extra fees
- parachains earn MEV revenue instead of losing it to bots
- the Polkadot treasury captures additional ecosystem value
- No single parachain needs to solve this independently
The IDN would act as a coordination and settlement layer for an encrypted mempool shared service that multiple parachains use.
What Changed: BEAST-MEV
Our original encrypted transaction pool prototypes using timelock encryption work, but do not scale:
- Sequential decryption (using BF-IBE) does not scale well beyond ~300 txs/block
- Time-dependent decryption creates inflexibility, as encrypted transactions cannot be rescheduled or re-encrypted
- Operational complexity: maintaining N beacons per parachain can quickly become unmanageable
- Poor UX: parachains must implement complex decryption logic (timelock decryption)
- Latency: XCM round-trips would make it slow and expensive
While we could enable an encrypted mempool natively, it can not scale to supporting the entire ecosystem. Breakthroughs in threshold encryption, specifically batched threshold encryption with silent setup, or BEAST-MEV (by TU Darmstadt/PolyCrypt), remove these restrictions, making encrypted mempools as shared infrastructure possible for parachains at production scale. Put simply, BEAST-MEV enables:
- Silent setup: No DKG required, making it a perfect fit for rotating authority sets
- Batched Decryption: Constant-size partial decryptions regardless of ciphertext size.
- Atomic revelation: Either the entire batch is decrypted or nothing is.
- Flexible ciphertexts: Not tied to specific epochs or round numbers.
An academic prototype has been implemented that demonstrates the feasibility of the solution, in addition to an article on cointelegraph.
This unlocks a flavor of “practical witness encryption” infrastructure for Polkadot, where transactions can be encrypted for provable conditions rather than just time.
What is Threshold Encryption?
Threshold encryption splits decryption power across many parties, so no single party can decrypt alone.
Quick version: It’s like a vault that needs t out of n keys to open (t < n). Each committee member holds one key, or a “share”. They each use their key to create a “partial decryption” (like partially turning the lock). When >= t partial decryptions combine, the full plaintext is revealed. Until then, contents are completely hidden.
Architectural Fit: Block Production, Not Consensus
As discussed in forum discussions, there is a separation of concerns between parachains and the relay chain. Parachains are responsible for transaction sequencing and block production, while the relay chain validates state transitions and provides consensus (finality). That is, collators are already sequencers. An encrypted transaction pool operates at the block production level, not as part of consensus, where collators sequence encrypted transactions and commit to it.
Alignment with JAM: Encrypted mempools are a natural fit as a JAM service as a refine function.
Economic: How This Sustains Itself
Unlike transparent mempools that are vulnerable to MEV (which is uncontrolled and extractive), encrypted mempools create predictable and governable revenue streams that could benefit all ecosystem participants.
Revenue Model (for community discussion)
We haven’t yet determined a specific revenue model, but there are various mechanisms that could capture consistent value to sustain the solution. In any model, we aim to provide value to all relevant ecosystem actors:
- The threshold encryption committee members must be compensated for their work.
- Parachain operators could earn a share in revenue, e.g. based on how much traffic they bring and for integrating with the service.
- The Polkadot Treasury could receive a portion of any fees, creating a sustainable ROI.
User-Pays
Users could pay a small per-transaction fee (e.g. 0.001% of trading volume). Users may prefer predictable and small fees over an unpredictable MEV risk.
Parachain-Pays
Parachains could subsidize use of mempool privacy, where they pay a subscription fee to use the service. The cost could be offset to users as ‘premium’ blockspace.
Alternatives?
There are various other mechanisms that can be investigated as well, such as priority-auctions, or perhaps leveraging staking mechanisms that allow parachains to use it ‘for free’ (e.g. stake 10k DOT at 12% APY, rewards fund the threshold encryption committee).
In all cases, instead of value being leaking to industrious bots, it goes to infrastructure providers, parachain operators, and the treasury in a controlled and governable way.
Value to Stakeholders
For DOT Holders:
- Today: Vulnerable to MEV, lose out 0.5-2% on average per trade, all actions in web3 games are public.
- With encrypted mempools:
- Eliminate MEV: no more front-running or sandwich attacks on your trades
- Better prices: Trades execute closer to expected prices, pay predictable and small fee instead of unpredictable MEV losses
Why it matters - Users favor predictable fees over the risk of getting sandwiched. Better UX leads to more users,leads to higher trading volume, greater demand for DOT, and more earned staking rewards and fees.
For Parachains:
Today:
- Losing $50K-1M+/year to MEV bots (e.g. Hydration estimated at ~$2M/year),
- Must either build costly bespoke solutions or stay vulnerable
With encrypted mempools:
- Eliminate losses from MEV entirely
- Attract users with “MEV-protected” trading
- Simple opt-in: no need to build custom solutions, just use the shared infrastructure.
For the Treasury:
- Investment: As a referenda, possibly with milestone based payouts and collaboration across team (Ideal Labs & PolyCrypt & participating parachains)
- Returns: The treasury stands to earn revenue by MEV capture and redistrubution from parachains.
- Indirect: increase in DOT value driven by MEV protection (more Parachains and more Polkadot users because of opt-in mempool privacy drives economic growth
- Strategic: Positions Polkadot as “the MEV-protected chain”
Risks and Vulnerabilities
Nothing comes without the potential for risk. For something like this to succeed, the following must be true:
- Parachains will opt-in to use this service.
- The ecosystem will see increased adoption and MEV extraction is significant enough to sustain the system without perpetual treasury funding.
- The PolyCrypt team is successful in their optimizations. The feasibility of the entire BEAST-MEV solution must be proven before any large-scale infrastructure build-out, specifically with a focus on fine-tuning and enabling multithreaded aggregation, with the goal being a significant reduction in aggregation time.
What We Need From You
We would love to hear from parachain builders, validators, and the broader community. This idea only works if you think MEV protection is worth actively pursuing, collectively.
Is this worth building?
- Are you experiencing MEV on your parachain? How much?
- Would you integrate this if it were available?
- Is ~$2M/year in captured value on Hydration alone significant enough to justify this? If not, what threshold would be?
For parachain teams specifically:
- What would prevent you from opting in?
- Do you need this for new features (intents, auctions, fair launches)?
- Would you rather build MEV protection yourself or use shared infrastructure?
Technical feedback:
- Does the two-phase model (fast execution + slow settlement) make sense for Polkadot’s architecture?
- How should redistributed MEV be allocated (parachains keep 100%, or treasury share)?
- What concerns do you have about the threshold encryption approach?
- How can we best construct the economic model to be sustainable?
Next Steps
We’re not requesting treasury funds yet. First, we need to validate this is a real problem worth solving.
If the community sees value, we will return with a formal, well-researched treasury proposal in collaboration with teams that have expressed interest. We estimate we need at least 3-5 active parachains to opt-in in order to reach sustainability.
If not, we pivot.
We believe Polkadot needs this, but we’re here to listen. If your parachain is open to piloting encrypted mempool infrastructure with us, comment below or send a DM and we will coordinate a joint discussion with PolyCrypt.
Thanks for reading! We are excited to hear your feedback on this idea.
Ideal Labs & PolyCrypt