The Future of MEV is SUAVE

MEV is the Millennium Prize Problem of crypto. We are deeply convinced that the value to be unlocked through coopetition in MEV is monumental. We believe that the sum is greater than its parts and that we can align the best possible execution with the most decentralized infrastructure. We commit to preserving the decentralization and respecting the preferences of every user and every domain that MEV touches.

We ask you to watch our actions and to keep us to account. We ask you to join us on this journey, so we can keep you to account as well. Check out our new post on!


  • After successfully isolating the centralizing effects of MEV to the block builder role, we turn ourselves toward a new challenge: to decentralize block building itself. Exclusive orderflow and cross-domain MEV present emerging centralization threats to all cryptocurrencies, so we must make sure to keep MEV decentralized, or the decentralization of crypto will be lost.
  • To hold ourselves to our decentralization commitments, we are building SUAVE - the Single Unifying Auction for Value Expression.
  • SUAVE unbundles the mempool and block builder role from existing blockchains and offers a highly specialized and decentralized plug-and-play alternative. Sharing the same sequencing layer allows crypto to stay decentralized, block builders to capture cross-domain MEV, validators to maximize their revenue, and users to transact with the best execution, while reducing the economic centralization pressure on each domain.
  • We are building SUAVE in the open and invite all interested parties — users, wallets, searchers, builders, researchers, and blockchain developers — to work with us.

Hey all, some questions on Suave:

Question 1)

We are now looking at two possible paths: either we find a way to shift MEV structure a third time, and do so in a way that sustainably eliminates the centralizing forces in block building. In this case, the promise of crypto may be realized. Or we concede block building to a small number of centralized entities, and the decentralization of crypto will be lost.

With respect, to me, this seems like a mostly false dichotomy in terms of the strength of the statement “the decentralization of crypto will be lost”.

Today’s mev-boost, plus enshrined PBS/crLists/etc, plus the realities of competitive pressures from MEV strategies being published onchain, as well as MEV-resistant app protocol research, suggest to me that extracted MEV’s current trajectory is most likely to remain small as a percentage of overall economic activity, and to be increasingly paid to users and validators, instead of searchers. For those reasons, I’m not sure it’s fair to say that “decentralization will be lost if we don’t embrace Suave”.

To me, it seems likelier that the downside case is that highly centralized block building acts as a significant toll on validators & users as a percentage of economic activity, and that L1 communities, like Eth’s, will readily fall back to naive-er block building in the case of sufficient censorship or other attacks because of the community’s long-term incentive to protect the valuation of their L1 native token. What do you think?

Question 2) Flashbots states that a goal of Suave is to not compete with Ethereum (and presumably, to minimize its own MEV footprint) by “not being a general-purpose smart contract platform”. Yet, flashbots then says it’s evm compatible, which sounds general-purpose to me. What’s the deal there?

Question 2b) If Suave is evm compatible and ends up being highly successful, might it naturally grow its scope to allow general-purpose transactions on Suave for which the MEV is handled by Suave itself? And if the MEV might be handled by Suave itself for its own general-purpose transactions, is it possible that’s a hint that it might be built into Ethereum, so that Ethereum could do for itself what Suave expects to do for Ethereum?

Question 3) Given that Suave is a standalone L1 that builds blocks on a cross-L1/L2 basis, to what extent might the efficacy, correctness, or integrity of this process be reliant on cross-chain bridges or oracles from the client chains into Suave? Would that mean that Suave’s ability to do its job is dependent on cross-chain bridges? If so, is that risky?

Question 4) What kinds of Eth protocol changes are required to support Suave? Would Eth enshrine any sort of exclusive dependency on Suave, or could Suave act as an ordinary/permissionless client (and, as a technical example, there could exist multiple completing Suave L1s)?

Btw, some of these questions have been asked and answered in brief in Bert’s Q&A twitter thread, but I’d welcome more detail.


First a general point:

I think SUAVE paper is slightly misleading.

Initially, the auction assumes trust in Flashbots but is private for users and searchers.

Followed by

SGX-based orderflow auction to remove trust in Flashbots and make the auction for efficient for searchers SGX-based centralized block building to enable open but private orderflow for centralized builders

If centralized builders are selected, this generally means an entity is doing the approving and thus still a function of Flashbots selection.

Which then concludes as

We do not expect you to trust us as we walk down this road.

I think FB team needs to come to terms that it is asking for trust, as it is building centralized infra first. Much like how IOTA liked to claim they were not asking for trust but had a coordinator, FB is positioning itself as the coordinator for the first two phases of SUAVE, and there is always a possibility that coordinator role lasts far longer than intended.

Flashbots is asking not just for collaboration, but to lend FB as an entity power for the majority of the road to SUAVE. Why start on footing of misrepresenting that trade off?

Now some questions:

  1. From my read of the paper, censorship resistance remains not a goal. Seems still focused on democratizing extraction and distributing benefits ignoring quality of service. While FB team has demonstrated it does not view coordinated denial of service to be a problem, if the community it seeks to collaborate with does view this behavior as problematic, would Flashbots be open to incorporating measures to reduce coordinated censorship into SUAVE?

  2. Given the scope SUAVE seeks to bring under its umbrella and early trust assumptions required to get to the end goal, is the US the best place to for the organization which is central to this working to be registered? Have there been any consideration given to more neutrally registered organization being formed for the purpose of facilitating Centauri auctions?

  3. One of the most powerful checks to centralized participants is the ability to fork. What sort of licensing is SUAVE looking to utilize? Will these licenses protect the right of participants to fork away from Flashbots if such actions are desired by the community for whatever reason? (i.e. including aspects which are not decentralized such as early auctions run exclusively by FB but are necessary components to run a forked network)


Hi team, you’ve presented a really impressive vision here. In particular, returning user-generated MEV back to users (rather than going to validators) and implementing a chain-agnostic decentralized sequencer solve huge crypto infra/incentive problems.

I have some questions–the devil is really in the details.

  1. What’s your estimated timeline to launch for each of the milestones? Are they measured in months or in years?
  2. I’m not so familiar with SGX. How secure are SGX enclaves in practice? Are recent exploits due to implementation-specific problems or due to fundamental issues with the tech? Is Flashbots exploring alternatives to SGX?
  3. What are the high-level incentives in the SUAVE network?
  4. How do you use ETH as the native token of the network (source)? Will this use Eigenlayer restaking?
  5. What are the expected block times for the SUAVE chain? Will other chains that use SUAVE for block building be constrained by SUAVE’s throughput and block times?
1 Like

Thanks for the thoughtful questions @ryanb!

Q1: I believe where our thinking might differ from yours is that we don’t expect the current market structure to hold because of two key centralization risks: cross-domain MEV and exclusive orderflow. While crLists, enshrined PBS, etc can address some of the degenerate cases of the MEV market structure today, it doesn’t address these risks. Cross-domain MEV in particular touches the actual validator set instead of just the builder market, and exclusive orderflow is a threat even with local block building. These issues need to be addressed head on, unfortunately, and they are existential threats to the decentralization of crypto.

Q2a: We want SUAVE to be maximally ETH aligned. A part of that is using the EVM as the way that preferences are expressed in SUAVE, which has the added benefit of being a “language” that searchers/builder/validators already have experience with, and which there is a lot of tooling around already.

Another thing to be mindful of is that we want SUAVE to provide an environment for preferences that is universal, which is to say that you should be able to express any preference and have it executed for you. As a part of that you need a very expressive language and computing environment for preference expression, which was another reason we’ve used the EVM.

In case you’re interested, there are folks inside of Flashbots on the research side who are arguing that we need to limit the expressivity of the language that can be used for preferences. The argument is that this is needed to minimize MEV. Personally I think it’s too early to make product decisions on this research, but it is interesting, and possible that we end up with something like “EVM–”, which is to say using a more restricted version of the EVM.

Finally, while SUAVE Chain is an EVM fork we have no intention or desire for SUAVE Chain to rival any smart contract platform. We want it to be exclusively used as a chain for sequencing and preference expression/execution. I don’t think this can be “enforced” given the goal of also being a universal environment for preferences, but if there is a way to enforce then I think we’d be open to it.

Q2b: MEV on SUAVE is an open area for research, and using SUAVE to handle SUAVE MEV is very difficult to reason about (at least personally). But, SUAVE Chain is optimized for MEV in a way that Ethereum is not. In practice this means that there is a new transaction type (it looks and acts a lot like bundles do) and its fees are much lower than Ethereum’s. The new transaction type is necessary to decentralize our builder by providing a decentralized way to pass preferences (think bundles), and the lower fees are necessary for the economics to make sense. We’re exploring other optimizations too. Moreover, a lot of what SUAVE (including and greater than the chain) does would be out of protocol for ETH, e.g. running an auction for orderflow.

Q3: It’s a little nuanced. For some parts of SUAVE the answer is “not at all dependent on oracles or bridges.” If you want to use SUAVE Chain for preference expression and settlement though, oracles are important, and you do need to bridge some funds. We’re very aware of the risk this introduces and are exploring ways of mitigating that, e.g. how we can trustlessly get data from ETH L1 onto SUAVE.

Q4: There aren’t any protocol level changes required to support SUAVE. SUAVE would work with Ethereum as it is today; and there would be no enshrined dependencies on SUAVE. There can be multiple competing SUAVEs or SUAVE like systems.

1 Like

On the contrary we’re not positioning ourselves in the coordinator role you’re talking about. The idea behind using SGX is, in part, to allow anyone to run these systems permissionlessly with guarantees of privacy and remove the need for Flashbots to maintain an allowlist.

I’m surprised by your reading and disagree with your characterization, but we’re always open to suggestions and PRs.

I think it’d be unreasonable to expect everyone working on SUAVE to not touch the US in anyway or for our US domiciled mates to uproot their lives, which is what you’re asking for in practice. And I don’t think it achieves that much.

Open to suggestions for organizational structure too, we’ve spent countless hours thinking about how to structure Flashbots to achieve the goals we have.

I’d expect MIT/AGPL similar licenses - as our other codebases have been - but we haven’t made any decisions yet (the thing needs to get built! Not yet clear where we need to use other software which could affect our licensing choices). These preserve the rights to fork that you’re highlighting.

Thanks for the responses!

1 Like