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?

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.


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!


Do you envision SUAVE for the universal sequencing layer for all transactions or only those with high MEV (e.g. DEX trades).

If it’s the first, how to ensure that the cost overhead of SUAVE justifies its benefits?

Another question: in the article, there is the following statement:

make a more abstract statement of what the user wants to achieve and leave the optimal routing to the executors.

Since executors will execute using user funds, what mechanism ensures that they won’t just take user’s money and leave? Is it within SUAVE consensus layer or achieved via smart contract level innovations?

Hi @onjas thanks for the questions!

Do you envision SUAVE for the universal sequencing layer for all transactions or only those with high MEV (e.g. DEX trades).

We believe it will be beneficial to express many kinds of preferences on SUAVE, not only those that independently generate large amounts of MEV. Right now, users have to compete individually to get their preferences executed. With SUAVE, many preferences are aggregated in one place — and as such, users can bargain as a collective and demand better terms, even if their transaction alone is not particularly MEV-rich. One practical example in this vein is how CoW swap “solvers” aggregate trades that have compatible requirements in a coincidence-of-wants style game. SUAVE generalizes this game to all kinds of preferences, and allows any executor to compete to find valuable ways to aggregate and execute them.

SUAVE can also sequence transactions that are not directly submitted to it. Similar to how the Flashbots builders construct blocks from a combination of protected orderflow and mempool transactions, SUAVE can build blocks that include transactions from other mempools. So SUAVE can be a universal sequencing layer for all transactions, even transactions that are not sent to SUAVE.

Since executors will execute using user funds, what mechanism ensures that they won’t just take user’s money and leave? Is it within SUAVE consensus layer or achieved via smart contract level innovations?

Each user and executor will likely have their own tolerance for risk vs efficiency here. We expect the usual flow to be non-custodial — users shouldn’t have to trust executors, and executors are only rewarded after they complete the job. More broadly, the SUAVE blockchain doesn’t enshrine particular rules for how funds on other chains are managed. So it’s up to the parties involved to decide how they want to collaborate.

For instance, a user could require the executor to fulfill the preference with their own capital, which can be exchanged for the user’s locked funds only once certain outcomes are reached. But this approach sacrifices on efficiency and requires the executor to have up-front capital, which means fewer may end up competing for the opportunity. We expect to see a range of approaches depending on the type of preference and the tolerance of the parties involved.


The description you provide for SUAVE

This sounds similar to Anoma’s intent centric design or ZEXE. Has FB evaluated these protocols or given any thought to their applicability wrt SUAVE chain?


@0xShitTrader Good questions, some thoughts

What’s your estimated timeline to launch for each of the milestones? Are they measured in months or in years?

SUAVE as a system will take years to reach its potential. We hope to share incremental releases of particular components along the way, with those releases measured in months.

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?

Most exploits are implementation specific. The most prominent attacks in recent memory (like the AEPIC leak that affected the Secret network) have been hardware related. There’s also a class of exploits that are caused by how the SGX interacts with the host CPU. Manufacturers like Intel will release patches to address these kinds of vulnerabilities, so the main risk lies in how long it takes for white hats and manufacturers to address the bugs and for developers to upgrade their deployments. Developers can also introduce exploits in the way they program the enclave. For instance, covert channel attacks and side channels can be used to leak secrets if the way the code is executed exposes specific memory access patterns.

It’s likely that these vulnerabilities would be exploited at some point if SGX is run on untrusted computers (ie. where the user has direct access to the hardware). So if we want executors to run their own enclaves, we would have to implement mitigation techniques — like rotating keys, TCB recovery plans, compartmentalization, smart software upgrade processes, etc. — which minimize the impact of leaking data and make that risk tolerable. The new generation of SGX is also migrating increasingly to the cloud, so some of these concerns could be mitigated if we decide to trust cloud operators. That said, this may pose a centralization and censorship risk.

Flashbots is indeed exploring alternatives to SGX, including other TEEs, FHE (Fully Homomorphic Encryption), and MPC (Multi-Party Computation), as well as possible combinations of the above. @metachris would be a good person to discuss this further!

What are the high-level incentives in the SUAVE network?

Users can deposit funds on SUAVE and commit to unlock them if their preferences are met. Specifically they can write smart contracts, which we call bonds, on Suave Chain that validate whether the preference was fulfilled and conditionally transfer a payment if so. These bonds create an incentive for executors to participate in the network.

We are currently iterating on the economics and validator set for SUAVE. At a high level we envision that validators would be incentivized by network fees collected from transactions.

How do you use ETH as the native token of the network? Will this use Eigenlayer restaking?

We don’t currently have plans to use Eigenlayer restaking. For now, we will use ETH bridged to SUAVE Chain as the native token (for paying network fees, executor rewards, etc).

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?

I think of SUAVE as having a messaging layer and a settlement layer. The messaging layer (ie. mempool) transmits preferences to be executed, while the settlement layer (ie. chain) processes bonds. Latency in the messaging layer makes a big difference in how optimally a preference can be executed — delays could result in missing a slot on another chain, or mean that SUAVE-based builders have access to less orderflow when constructing blocks (eg. if last-minute submissions aren’t transmitted in time). We are actively exploring ways to improve the performance of the SUAVE mempool such that this cost is as negligible as possible.

That said, it’s less likely that block times on the SUAVE settlement layer will be a bottleneck for most use cases. This chain is primarily used to check the results of execution and settle payments after the fact — ie. it mostly processes transactions to (1) initialize bond contracts (2) submit oracle updates about the state of another domain (3) bridge funds and (4) claim the payment from a bond contract after a preference is fulfilled. The block times on this chain only really matter if you have to do one of those things in the process of executing a preference.

We are still designing the mechanism for block building on SUAVE, but it seems unlikely that builders would need to take actions like those while constructing a block. They’d certainly be reliant on the gossip layer to collect orderflow or collaborate with other builders, but they can likely establish and invoke settlement conditions before and after the slot.

P.S. If these questions around building a performant gossip layer or designing an efficient mechanism for decentralized block building interest you, please reach out! We will share a larger set of design challenges in the new year as well.


What exactly is the output of SUAVE? Do the SUAVE chain nodes agree on a particular set of blocks to send to the respective proposers, or do they generate multiple blocks that compete at the proposer level? If the former, how would one avoid censorship and lowballing the proposer?

What happens if SUAVE creates blocks fulfilling cross-domain preferences, but only some of the domains’ proposers choose the SUAVE block?

Is SUAVE only going to sequence for EVM chains? How would a SUAVE block-builder simulate a WASM bundle, for example? Stepping back to SUAVE with EVM chains - do I run an instance of geth in full mode for every chain?

Are any assumptions made about the state of PBS on the sequenced chains? When are block contents revealed?


In cases where a user’s transaction creates MEV, executors would capture that as well and compete on paying as much as possible of it back to the user.

Does this mean that the executors would find the MEV? So, the executors are the new searchers?

Finally, a decentralized block building network takes the collected preferences, many of which have their execution paths optimized by now, and turns them into blocks across all participating domains.

Optimizing paths - can you elaborate on it a bit more?

Has there been any thought put into how Suave is going to handle executing against multiple environments given that some environments are reorg prone?

ie. searcher submits a cross-chain arb between polygon and ethereum and the polygon side gets reorged. Would the searcher or the executor bear the risk in that scenario?


Where can I find more information on SUAVE as a blockchain? Specifically things like consensus algorithm, gas fees (paying gas on SUAVE seems like a barrier to some adoption) and specific layers (@shea mentioned a settlement layer and a messaging layer.)

1 Like