MEV-Share: programmably private orderflow to share MEV with users

really cool design!

two more theoretical questions:

  1. how do you foresee governance of the language of {privacy preferences, validity conditions, hints} working? Esp. as it pertains to SUAVE

this seems like the first case where language defining predicates of EVM-level stuff needs to exist at the ‘protocol level.’ I.e. tokens_traded in privacy preferences is a quite subjective ‘application-level’ concept.

If there are differing opinions about what predicates to expose in the language between these various entities, I could imagine governance of what’s canonical/enshrined being quite contentious.

  1. is there a way for builders (or searchers) to re-submit privately-matched bundles for more tx addition?

slightly less thought out, but I’m wondering if there’s a way to recursively continue building private bundles.

reason being that the existence and properties of a ‘privately inserted bundle’ is information that could probably be used by builders (or even searchers) to re-bid for additional private tx insertion.

the fun, less useful exercise I’m also curious about as an extension - what would it look like to recursively build a bundle ‘from 0.’ i.e. could a capitalized enough searcher with no information about other txes recognize that there’s some value in affecting bundle formation at a specific time and act on that


This is a mirror from my hackmd page. It may be a stupid idea, but just some thoughts that hopefully inspire more open discussion around this topic

based MEV-Share

If you have “smart searchers” they could read the different Mempools and match orders. Then match the orders, bundle them and send them to a builder. So basically MEV-Share for all rollup mempools. In this way you would not need a sequencer for ordering, though a local fallback is always helpful.

This idea on the surface appears similar to the idea put forth by a couple of Jedis here. Perhaps this lends some credence to the technical feasibality of the following discussion.

Disc-V5 supports topics and is used on both CL and EL, so we could create separate p2p channels at any granularity we want (e.g. shared_sequenced_chain1_chain2_slot5 , see e.g. how EIP-4844 blobs are each on separate topics. ~ @gakonst

I would caution the reader that the following proposal is reductionist and may be technically infeasible and/or too left curve. Feel free to correct any misconceptions or comment.

4337, Private Mempools & Match-Making

MEV-Share inserts an intermediate role between searchers and Builders. The Match maker plays a similar role to that of a solver in the Anoma framework. Can you match make userOperations for all rollups?

Since all transactions are 4337 compliant they need aggregation anyway. So rather than send rollup transactions to a sequencer you send to a private mempool and communicate with the Bundler who is the MEV-Matchmaker. They then bundle all transactions and send to the builder who aggregates the block. The rollup reads the state from the L1 after the block is produced and derives current state of the chain. One issue with this approach is it would kill rollup soft confirmations which is why you would need them on L1.

I think this could be super valuable for economic security as MEV flows to the base layer. One downside is then the rollup captures less value and so funding public goods with MEV becomes less feasible. I think this can be implemented in stages. For example maybe at first you only get this level of cross composability with rollups sharing Liquidity in dAMM contract. Then other stuff, like aggregation across yield farming, borrow/lend operations, NFT mints, attestations, payments, etc. It could be possible for the Match-Maker to take all un-matched AMM orders and send them through an L1 aggregator, similar to Cowswap.

In this scheme rollups could still have a sequencer. As a user you would be alble to opt-in to an MEV auction similar to how you use private mempools today. The other alternative would be the based rollup critical path, outlined by Justin Drake.

Censorship resistant

The design is more censorship resistant If the matchmaker can be trust minmized. But maybe its less bad if the user has multiple mempools to choose from. The Match-Maker itself could potentially have multiple instances asigned to different rollups should the need exist. Smart Wallets could come with built in logic that suggests to the user which mempool to use. However, I personally think this is unlikely and we will see only a handful of winning rollups in a winner take most competition. But as you can see there is clearly a path to open and permissionless Match-Making.

This is all well and good but there are many unanswered questions, like how would this new matching framework comply with 4844?

Also, the logic required to run a multi-rollup match maker may be costly initially and take time to mature. In this case you could start with one rollup and then add additional rollups as the stack matures and demand arises. Reth is around the corner as well which will make simulation faster.

The Match-Maker role could be more decentralized than the builder role as it would not require the composition of entire blocks, only bundles that match userOperations . The Builder in this scenario could order bundles based on fees or FIFO if desired. The Builder could also reserve space at the top of the block for this 4337 Auction and then leave space for L1 public mempool transactions. Many such combinations and scenarios.

Builder pre-confirmations

One extra builder service that would be desirable here is pre-confirmations. The concept is well understood so i won’t outline the specifics, but to recap the builder could guarantee inclusion of transactions pay a specified gas fee. In this way the builder would collect these pre-confirmed chunks and aggregate them and then send to the relay. This may also help builders reason better about how much to pay for an MEV opportunity.

Also, if pre-confirmations are ~ 1s then you can get lower latency with respect to price updates on DEXes, as they would not remain ‘stale’ until the next oracle update. So the notion of “stale pries” goes away mostly. The pre-confirmation would need to be globally visible for searchers and users to reason about the current source of truth. Lower latency would allow for better price discovery and perhaps less adverse selection for LPs. There are better researchers who can make this argument wrt Latency and price discovery. Don’t take my word for it.

Its also unclear if a Matchmaker would be able to provide pre-confirmations and if a cross rollup mempool order flow auction introduces too much latency.


The combination of 4337 with MEV-Share, builder pre-confirmations, and based rollups could lead to cros-rollup + L1 composability while filling in the ordering function for rollup sequencers who seperate ordering from inclusion.


I see there are two mechanisms protecting users from exploitative MEV: validity conditions and privacy.

How can one reason when to use which?

I think this question comes down to asking if validity conditions/competition among searchers are good enough, or if privacy is additionally required to give the best execution for users.
I believe MEV-share/SUAVE is assuming privacy is required. Appreciate it if you could point me to someone I can learn more about the reasoning!

1 Like

You’re right in saying that MEV-share is predicated on the idea that some degree of privacy is beneficial for execution quality. Of course, the nature of what the user is trying to do impacts what kind and degree of privacy is useful.

I think one simple way of understanding why privacy is necessary on top of validity conditions is that there is a lot of indistinguishable cases. Slippage limits capture the classic one: did someone trade ahead of me because they knew I was going to do a trade or was it coincidence?

Happy to discuss more if that doesn’t cover it


if a trust builder, replace the bundle without giving money back to user, and send it to other relays, what can you do?