Encrypted Mempools: Turning Polkadot's MEV Leak into Treasury Revenue

Tech Talk
1

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:

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:

  1. User attrition: Users who are continually front-run or sandwiched will take their business elsewhere.
  2. Centralization Pressure: Economically powerful actors have more opportunity to extract MEV, making them more economically powerful, which is especially concerning in a PoS network.
  3. 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:

  1. Parachains will opt-in to use this service.
  2. The ecosystem will see increased adoption and MEV extraction is significant enough to sustain the system without perpetual treasury funding.
  3. 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

1 Like
2

I’ve no looked at this yet, but overall my thoughts on encrypted memepools:

They’re conceptially simple if you’ve timelock IBE ala drand. Anonymous payments ala zcash matter too, or else you accept some metadata leakage.

They’re pretty expensive though. I’ve never done the benchmarks to see if batching helps, but very likely. Also there are nice optimistic decryption tricks for some flavors.

Some on-chain games would benefit, probably some other sane protocols, and yet smart contract benefit. You’d likely integrate the IBE directly for game, mostly due to the optimistic decryption, but you’d still want some pallet for the drand bridge part so that’s probably the same for everyone.

I think encrypted memepools maybe overkill for DeFi, but some nuances here:

There is obviously no reason a uniswap-ish DeFi protocol should be vulnerable to sandwiching within one block, or yield different results when you rearange tx within one block. Only a moron or thief would ship a uniswap-ish DeFi protocol in which single-block sandwiching occurs.

As collator sets are small, you’ll still have multi-block sandwiching sometimes, although maybe cryptographic shuffles help ala Whisk. Anyways, you’ll always have single-block sandwiching for smart contracts, but this merely says you should never have smart contracts on DeFi chains or visa versa.

All this said, yes you could patch badly designed DeFI protocols using encrypted memepool. It could yield stronger results than replacing the stupidly designed DeFi protocol too.

2 Likes
3

That’s right, e.g. on Hydration single block sandwiches are not possible by design. But the very design prevents potentially useful/interesting features like flash loans. IMO flash loans are a mind blowing advantage over TradFi… probably it can be implemented in a safe way.

4

An additional benefit of encrypted mempools is also censorship resistance which is probably important to many applications in Polkadot. Though I am not sure at what scale censorship currently happens on Polkadot.

Could you explain why flashloans are prevented when we use encrypted mempools?

Anyway, I think encrypted mempools is just an additional option that users can opt-in when needed, e.g., to prevent frontruning or protecting their privacy. Similar to users paying an additional fee for their transactions to be included faster.

1 Like
5

Definetly a lot of value in encrypted mempools,

Got some questions:

1 - Are you planning on making the encrypted mempool optional or turned on by default? Bittensor is currently working on an optional pallet call that will provide this(Encrypted Mempool V1 · Issue #2169 · opentensor/subtensor · GitHub)

2 - How practically are you going to build this? Will you build a pallet that hooks into the runtime and by default does some magic to enable all tx’s in the mempool to be encrypted?

6

Hi @driemworks,

I previously worked with Mangata and am familiar with the Themis protocol.

Tbh, I think the timing is not right for this solution. There is not yet enough economic activity in the ecosystem that the damage would be large enough. And when we get to that point, I find it plausible that intents might have become so dominant that the problem could become obsolete. (or more generally, my intuition is that auction-based mechanisms either on the smart contract or STF level could provide a more pragmatic approach to internalize MEV)

A few practical questions:

  • would the mechanism be executed by collators/during parablock production or somehow else?
  • how large would a colluding set have to be to circumvent the protection your mechanism offers?
  • how do you prevent the sequencer from censoring the transaction? is it included in one block and then executed in the next one?
  • does your mechanism prevent reordering?

I think this is incorrect. OP even shows a sandwich from Hydration.

7

Yes, you’re right :sweat_smile:

But in this specific case I guess that is not an intentional sandwich, it’s a very well known arbitrage bot (with high volume) in Hydration. Probably what you see there is the sell orders of the bot to arbitrage cex/dex (that are always done in batches) + a tx dragged from another block due async, and by chance the unfortunate user swapping got in the middle… so, this specific case will happen anyway with the mempool encrypted :grinning_face_with_smiling_eyes:

Checking the example block provided by OP is not even a sandwich of any kind, because (1) the asset pair of the “frontrun” is a different asset from the “victim’s” trade, is to sell KSM to USDT in fact driving down the price of KSM, (2) the “victim” was selling ASTR for asset id 10 that is USDT (3) USDT price cannot be moved up with the size of this trade, (4) the “back run” is in the same direction, selling ASTR for USDT, and (5) the “victim” and the “attacker” are trading in different stables pools, one in 2-pool and the other in 4-pool :joy:

8

If you have a blockchain dedicated to multiple single uniswap pairs, then you can easily stop sandwiching:

We have a prices vector p_{n-1} from the previous block, so then the current block B_n declares the prices vector p’ for all pairs active within B_n, and then on_finalize computes the new prices vector p_n after B_n finishes, and checks that if p’ is say the mean, or geometric mean, or whatever, of p_{n-1} and p_n.

All tx execute at p’ of course, so that every tx pays exactly the same price given in p’, and sandwiching cannot occur within B_n. All tx declare their allowed price ranges, so B_n is only valid if all tx in B_n accept p’.

You might require some integer linear program to construct B_n here, because including or excluding a tx does change p’, and so might exclude other txs. Integer linear programs are NP-complete, but approximation algorithms should yield good results here.

A conventional smart contract platform cannot do this, but if you’ve a dedicate chain then you can enforce p’ being correctly constructed in post-tx logic like on_finalize.

Afaik it’s dubious that non-pairwise high dimensional uniswaps ever make sense anyways, like maybe they’ll always just hemorrhage funds. If however you do believe in high dimensional uniswaps like hydration, then afaik you could still do this provided your approximation algorithm can benefit from the higher degress of freedom.

I’ve never tried to work this out since I’ve never believed in high dimensional uniswaps anyways, so maybe other higher dimensional cyclic-sandwitching attacks exists here or who knows what, but like I said I’d expect shut like that breaks the underlying high dimensional uniswap.

Anyways this is what I meant by my comment above.

p.s. I mostly just hate seeing polkadot projects reduced to being smart-contract-like because developers cannot get their minds out of that dumb ETH rut.

1 Like
9

With a dampened liquidity pool sourced from multiple pairs you have high barrier to price moves, i.e. you will need a very big volume relative to the pool aggregated liquidity to move the price. Even if doesn’t theoretically prevent a real sandwich within a block boundary (none happened to the date), it makes the possibility extremely unlikely because a big move will be usually done in batches and very few actors can profit of a one-shot big trade potential sandwich scenario in an omnipool, particularly if the trade has no tip. In practical terms, and current play field, the approach is solid.

1 Like
10

It doesn’t seem trivial to me:

  • There could be multiple solutions of txs to be included with a given set of inputs.
  • If you assume pairwise swaps, you will also definitely have routes, which introduces dependencies and further increases the solution complexity

Also to note: If you treat the pairs independently and solve the block as a whole, there will be no back-running at the end of the block, so the prices of pools in relation to each other will not be in equlibrium. The protocol could perform the backrun and take the arbitrage though.

I can’t follow this thought. Hydration only from the outside looks like it has one pool with many tokens, but underneath it has one pair for each associated token and they route through one liquidity token. In my understanding this is more capital efficient, because you reduce the number of hops on a route to virtually 1 (and actually 2) and thus the total set of pairs is minimized and you have less pools that you actively need to keep in equilibrium aka non-informed flow can cancel each other out more easily.

11

Who cares? It’s definitely NP-hard to find the “best” block from the block producer’s perspective, but we easily find blocks that satisfy the constraints.

An approximation scheme would first solve the LP relaxation of the 0-1 integer linear program. For us, the LP relaxation represents some pre-block in which trades executes only partially. It’s not 0-1 anymore so we’ve good algorithms for this.

We might’ve total unimodularity depending upon how our uniswap works, including choosing the arithmetic mean for p’, in which case our LP relaxation basically works. If not, then we’ll need something more complex here, but this depends upon the economic considerations.

We could even try staying closer to the LP relaxation itself by allowing transactions to only partially execute in the final block, so then we place the unexecuted remainder into some on-chain “unfinished orderbook”.

We could maybe demonstrate the LP relaxation in the block and fully execute all the tx above some threshold, which in essence imposes something like total unimodularity to override the economic considerations. In particular, the block size constrains would always exhibit total unimodularity, so we could cut down to a sanely sized block, even if we only partiall execute some trades.

All these techniques could be mixed together of course. I’m really not sure what’s best here.

There is not necessarily some requirement to solve these problems though, no?

At a high level, we’re not too worried about extra degrees of freedom, since we know approximation algorithms that could ignore most tx immediately, and we do not care if we do not get the best block only that we get a reasonably full block.

I’ve never looked closely at hydration, maybe its fine, or maybe not, really not sure myself.

1 Like