Big thanks for askyv, ek, 0xsolidq to discuss and feedback!

This article focuses on the centralization of block builders in Ethereum and their individual factors. The purpose is to bring more people to the issue of centralizing block builders and to promote more discussion and development.

Table of Contents

• Background of the Creation of Block Builder

• What is Block Builder Centralization

• Why Block Builders Centralize

• Individual Factors Centralized by Block Builder (POF, Bundle, Integrated bundle)

• Solutions being discussed(SUAVE, MEVM, Execution-node)

• Credible and flexible commitments (PEPC, PEPC-Boost)

Note: I recommend reading the following first to learn the basics and current state of MEV.

• MEV: Maximal Extractable Value Pt. 1 https://www.galaxy.com/research/whitepapers/mev-how-flashboys-became-flashbots/

• MEV: Maximal Extractable Value Pt. 2 https://www.galaxy.com/research/whitepapers/mev-the-rise-of-the-builders/

• Builder Market: Now and the Future https://mirror.xyz/hismrti.eth/qU4f9dAROTaARf_VQaaVXD3xxDwKO1-BgDwGXJs6sqM

0. Background of block builder

PoW Ethereum miners have the authority to build full blocks and needed to maximize block rewards by simulating blocks in a short amount of time.

Since this process requires high resource requirements, it favors mining pools and businesses over individuals, the hurdles for individuals to participate in the block building process are high, and mining pools and businesses where block builders have some capital There was a concern that it would concentrate.

With The Marge changing the consensus algorithm from PoW to PoS, capital strength (the amount of ETH to be staked) is directly related to the construction of full blocks, increasing concerns about promoting more centralization.

On the other hand, Ethereum aims to “separate authority between miners and block builder”, which is called Proposer Builder Separation (Enshrined PBS = ePBS). A company that specializes in building block created by PBS is called a block builder.

However, implementing this PBS within the protocol is technically difficult and is said to take 2-8 years. As an alternative, Flashbots offers software called MEV-boost.

This software allows validator to delegate full block construction to third-party "block builder", allowing even unsophisticated proposer with low resource requirements to build high-value full blocks (by delegating ) can now be constructed.

As a result of pseudo-implementing PBS, which cannot be implemented for several years, with MEV-boost, we succeeded in mitigating centralization to staking pools.

However, the problem of block builder centralization still persists, and this problem has simply moved from validator to block builder. This is the background to the birth of Block Builder.

1. What is Block Builder Centralization

There is a variability in the order flow economic opportunities accessible to block builder In a market that competes in an exclusive order flow that only a few traders can access, the winner-take-all effect works, and small and medium-sized builders are weeded out, leaving only a few excellent traders to survive.

In this way, the concentration of block builders in a few sophisticated traders is called the unification of block builders, and there is concern about the negative externality due to unification.

In the current block builder market, the top 4 builders hold 88%.

The top four builders may impose arbitrary rules due to their competitive advantage, resulting in a closed block building process. This risks ensuring that all fee-paying transactions are not on-chain, potentially undermining Ethereum’s censorship resistance, neutrality and resilience.

• Censorship resistance: it can favor and discriminate against certain users and applications, imposing arbitrary rules, for example, censoring certain tx's, refusing to process them, or charging more fees. Some in the community fear that a secondary market of censorship could form and take more exploitative measures Ethereum needs to be censorship-proof at a high level.

• Neutrality: When censorship resistance and elasticity are compromised by a dominant builder, the neutrality of not allowing certain actors to have too much influence is reduced and forces to centralize validators come into play.

• Resilience: If a single dominant builder goes offline for any reason, all block generation may stop. This results in low elasticity and inclusion delays in the block building process.

This degrades UX such as inclusion delays and increased fees.

It was also noted that if a single block builder grew competitive, there would be a greater risk of integration with other actors. This means that a small number of sophisticated builders may be able to exert a competitive advantage over other vendors by preventing some of the outflow of funds by turning profits earned into staking, and the risk of vertical integration of the entire MEV supply chain is a possible concern.

Negative externalities created by block builder centralization are contrary to Ethereum's values and need to be prevented by changing the rules of the protocol as they could undermine the underlying value of the network.

2. Why Block Builder Centralize

So why is there variability in economic opportunities for block builders?

First, the block builder participates in the MEV-boost auction and wins the right to build the block from the proposer by bidding in this way.

Block builder need to collect high-value order flow to create profitable blocks in order to beat competing builder, but some builder get exclusive order flow that only certain it can access.

Looking at the diagram that quantifies the number of public order flow and exclusive order flow of the top builders and the value transfer, the number of public order flow is large and the number of exclusive order flow is less than 20%. It can be seen that the value of exclusive order flow is close to 80%. This shows that the value of exclusive order flow is great.

Direct payments (coinbase.transfers) from exclusive order flow, which account for 0.45% of all transactions, accounted for 13.5%, indicating that builder have great value in owning searchers and receiving exclusive direct payments. .

The reason for this is that since the searcher and the builder are the same business entity, all of the profits earned by the searcher can be bid to the builder, thereby increasing the profit margin of the contractor.

In other words, exclusive order flow and direct payment are important to win the right to build a block at MEV-Boost, but these characteristics are inaccessible to other builders, resulting in "disparity" in economic opportunities among builders. From the standpoint of inclusion, valuable transactions flow to builders who are more likely to win at auctions, further accelerating the negative spiral of inequality in economic opportunity. This continued bias of economic opportunity toward a few builders prevents small- and mid-sized builders from accessing valuable transactions, and the number of builders who can build highly competitive blocks is skewed toward the few.

This is the main cause of block builder centralization.

3. Individual Factors Centralized by Block Builder

High value order flows are found in exclusive order flows that are not observable in the public mempool, which can be further classified into exclusive order flow and direct payment from the holding searcher.

• Exclusive order flow

  • POF

  • bundle

• Bundle from integrated searcher

Categorizing the factors of builder centralization as above, we look at the dynamics and centralization factors of each.

3.1. Private Order Flow (POF)

It is a private order flow (POF) that provides incentives, such as protecting against front-runs and returning some MEV to users, and collects them privately through a custom RPC endpoint.

For example, there is an RPC endpoint called Flashbots Protect, which is a Flashbots-only RPC endpoint and a Flashbots-only transaction. The user's privacy is protected by being able to change the transaction destination by adding the following to the wallet.

Users can take advantage of various benefits, such as front-run protection, confirmation of high gas prices, and warnings when sending to dangerous addresses.

Since other builders are developing the same thing, POF is also an exclusive order flow that other competing builders cannot access. Also, if a wallet provider such as Metamask considers monetizing order flow, they can consider selling order flow to a single or multiple builders, or the provider itself becoming a block builder.

There is also pointed out that up to 70% of transactions done on Ethereum are via Metamask. , making it easier to build competitive blocks given that single or multiple builders have exclusive access to ~70% of Ethereum transactions.

In addition to wallet providers, Uniswap, Coinbase, and others who place transaction, when users use the front end, are free to move transactions on the back end and may be able to send them to specific endpoints with which they have exclusive contracts. This could result in transactions that are accessible only to specific providers that have exclusive contracts with the front-end operating entity.

Thus, certain providers may have access to valuable transactions or may secure valuable transactions by signing an exclusive contract. In such an environment, builders may be concentrated in a few providers because providers who cannot contract exclusively and do not have access to valuable transactions are eliminated.

3.2. Searcher bundle

Clarifying the factors that drive searchers to choose block builders and send bundle is important for neutral block builders to thrive and to capture the dynamics of challenges.

First, among the 38 active builders, the top four builders received more bundle 87% than the others. holds market share. There is a correlation between the competitiveness of builders and the number of bundle, and searchers tend to send to highly competitive (=high market share) builders.

Also, 88.5% of searchers send bundle to four or more block builders, which means that in terms of inclusion, searchers This indicates that searchers have an advantage in sending bundle to multiple builders from the viewpoint of inclusion.

The reason for this is that there is more than one competitive block builder, so sending to the top four companies has an 88% chance of being captured. However, searchers need to trust that block builders will not steal MEV, so there is a tradeoff between the number of searchers sending and the cost of trust.

However, there is a tradeoff between the number of searchers sending and the cost of trust, since searchers need to trust that block builders will not steal their MEV. Thus, transactions are concentrated among a small number of trustworthy and competitive builders, and a reasonable majority of searchers may make the same choice.

This is the reason for builder centralization in searcher bundle.

These can be summarized as follows.

• Searchers send to several block builders (a few) that are competitive and have a high market share ratio. This is because it speeds up inclusion.

• Basically, searchers follow economic rationality, so most of them make the same choice.

• As a result, order flow is concentrated only on a small number of top builders with high competitiveness.

This rational choice of searcher and the competitive environment of block builder create different economic opportunities for each builder, and the inaccessible builders are weeded out, leaving only a few sophisticated builders.

3.3. Bundle from integrated searcher

5.5% of all searchers send to only one block builder, which means that the builder has its own searcher.

For example, builders such as Beaver and Rsyc have their own searchers, and after integration, more than 25% of all blocks are generated by Beaver and 15% by Rsyc as well.

Although a small percentage of the total, searchers and builders are the same entity, so all of the profits earned by the searchers can be tendered to the builders.

SMG's paper notes that builders who integrate with searchers have superior block top extraction capabilities, and that there is potential for centralization in factors other than exclusive transactions. We dig deeper because of the possibility of centralization due to factors other than

First, the blocks exchanged in MEV-boost auctions refer to full blocks, but the full block space can be divided into two categories: tops and bodies.

• Top of the block: Cex-Dex arbitrage is central. Priority access to on-chain transactions and high-quality execution on Cex are required as a set, and high-quality execution on Cex requires an HFT strategy and transaction fees. builder with integrated searcher have the advantage of top of block extraction capabilities and call them HFT builder.

• Body of Block: Frontrunning, Sandwich, Focus on Dex - Dex arbitrage. Some merchants use RPC endpoints to access exclusive POF, historically accessed through public mempool as they need access to high-value order flows.

According to the same SMG paper, a specific HFT builder usually wins about 30%, but if the price moves 1%, it wins 78%, and 2% move suggests a 96% chance of winning.

This means that HFT builders are more likely to win auctions when prices are volatile.

In MEV-boost, there is no distinction between "top body" and auction is performed in units of full blocks, so if the top of value is high, the value of the body is also relative. The same applies vice versa.

Due to the nature of Cex-Dex arbitrage, at least when price fluctuations are large, HFT builders have an advantage in auctions and can invest more in acquiring POF.

As such, many builders with Cex-Dex arbitrage advantages that are not necessarily related to access to exclusive order flows such as Bundle and POF may end up winning block shares.

For example, HFT builders such as Beaver and Rsyc are positively correlated with block top extraction capacity, while Flashbots and builders69 are negatively correlated.

Builders that own searchers prioritize their own searcher order flows, making it difficult for general searchers to be selected for transactions, further raising the barrier to entry for searchers.

In addition, a builder that owns a searcher and can conduct a Dex - Cex arbitrage strategy needs at least capital.

Since the number of large firms with capital and access to Cex is limited, competitive advantage may eventually flow to only two or three firms. This trend of holding searchers will increase in the future, which will also increase opportunities to acquire exclusive transactions and promote centralization.

Since block builder centralization in the context of integrated order flows has strong centralizing power, it is necessary to use the transparency feature of the chain for visualization and analysis and to change the rules of the protocol. Personally, since vertical integration is a contentious issue in other areas, one important key is to consider it based on examples outside of blockchain, since there are numerous examples in the past.

4. Solutions being discussed

Explain the means that are being developed and discussed as solutions to the centralized block builder.

• Collaborative Block Building: Splitting up block building reduces incentives and opportunities to distort competition.

• Flexible Trusted Commitment: **flexible trusted exchanges beyond full block exchanges through relays by proposers flexibly committing to the block space.

4.1. Decentralized block construction

The solution that is currently undergoing the most development and research is decentralized block construction.

This method decentralizes access to builders' information and allows multiple builders to cooperate across the chain to create a single block.

• Order flow Access: sending exclusive order flows to a joint pool rather than to a single builder may reduce inequality of economic opportunity.

• Sorting Algorithms: Builders possess sophisticated algorithms to find the most profitable combinations of transactions and bundle. In collaborative block construction, multiple builders could run the algorithm and combine different transactions or bundle to build a more profitable block than a single builder.

• Cross-chain execution: participants in joint block building will need a way to coordinate with other participants to supplement the MEV of multiple chain.

• Privacy: While we trust a single builder to execute without stealing MEV when sending transactions or bundle to a single builder, in the case of joint block building, multiple builders participate in the block building process, so another way to ensure privacy is needed, and the following design ideas have been discussed The following design proposals have been discussed.

  • Searcher-Aggregator model with TEE/TPM

  • Searcher-Aggregator model with Threshold Encryption and ZK-SNARK

  • Slot Auction model via chaotic iterative search

  • Sequential Slot Auction with proposer commitment

Democratize access to economic opportunities to avoid reliance on large builders. As a result, cooperative, decentralized block building may be more profitable, and practical use of collaborative block building will require economic incentives to join the network and network effects such as the aggregation of many transactions in the same space.

SUAVE

SUAVE is a typical example of decentralized block construction, with the following objectives.

• Neutralization of exclusive order flow: Transactions should be granted privacy, and some MEV resulting from user-created transactions should be entitled to acquire. Also their transactions should be private and available to all block builders.

• Neutralization of cross-domain MEV: Blockbuilders across chains need to integrate with each other, but in an open and permissionless manner, as there are examples of searchers and miners integrating before Mev-geth.

• Decentralized network: the first two elements, the transaction system that gives users privacy and mev-rights and the block building system that gives builders economic opportunity rights, need to be decentralized.

Exclusive order flow can be solved if the sender sends order flow to builders other than the monopoly builder, and SUAVE creates incentives for this through auctions. It is more profitable to share transactions in an open manner than to sell them or hold them exclusively for oneself, and transactions sent to SUAVE can be accessed permissionlessly by any block builder, neutralizing exclusive order flow.

SUAVE's collaborative block building is accomplished through three roles.

• Preference environment is an environment optimized for preference representation and settlement. For example, "I have an asset called X, want Y, and am willing to pay Z" or "Preferences for transaction order". Specifically, it is a message that the user signs to declare his or her goal, and the declaration is released when the goal is achieved. Importantly, cross-domain MEV preferences can be expressed, which allows the builder to recognize and capture cross-domain MEV.

• An execution market is a network that competes by providing the best execution for a preference; preferences are passed through SUAVE's Mempool to a network of actors, called executor, who compete by providing the best execution: OFA, builder, RPC provider, and solver are examples of executor, which is important for democratizing MEV in many domains. The reason is that the execution market is an open and neutral space, where exclusive trading is neutralized because anyone can obtain the best execution of a preference without authorization.

• Decentralized building is a network of builders that take the output from the preference environment and execution market and collaborate to build a full block. It is a way to decentralize Flashbots builder and decentralize the role of a single builder, so that anyone can be a builder building part of a block. The key is that it is private and permissionless. Specifically, anyone can join the network, and once they join, they must have access to encrypted preferences.

These three roles are accomplished by the SUAVE Chain (MEVM). This chain is compatible with EVM and provides a scaffold for these elements to interact and decentralize over time.

Discussions and development are currently being led by Flashbots in an open manner, and the SUAVE Devnet will be launched in Q4 2023.

This completes the release of Centauri and provides an early version of the MEVM; the initial architecture of Centauri includes key elements such as the "MEVM Chain", "Confidential data store" and "Excution Node".

Users send private data they want to include in the block to a mempool on the MEVM and approve the contract, such as "is it safe to execute the transaction at auction?" and the executor performs the back-run and arbitrage. The end result is a decentralized block that is included in a chain such as Ethereum.

MEVM Chain (Suave Chain)

The MEVM Chain is an improved version of EVM with pre-processing for MEV use cases and serves the purpose of SUAVE. For example, the hurdles to building new MEV infrastructure will be lowered, competition will be maximized, and block construction and order flow auction (OFA) mechanisms may become more prevalent on SUAVE.

Applications such as access to off-chain data that cannot be built on Ethereum, block building that is too expensive on-chain, and auctions that require personal information can be developed using EVM and its tools (solidity, foundry, etc.).

This will lower the development hurdle, and centralized infrastructures such as OFA and block building can be rebuilt.

The MEVM also provides privacy and efficiency as well by moving the computation of sensitive data to nodes that run off-chain; privacy is important in the context of MEV because data cannot be shared due to the risk of front-running or MEV theft.

Initially, Flashbots or another third party will run the nodes in a trusted manner, but in the future, making the nodes SGX will reduce trust in centralized actors.

Execution Node

Part of the preprocessing on the MEVM calls the Execution Node. This is an off-chain node. For example, it simulates or combines transactions, or adds new transactions during block construction. It is used to perform reliable and private computations off-chain that you do not want to perform on the chain, so that only the output and results of the computation are visible on the chain.

A Confidential data store is used to store users' private data that they do not want to store on the chain accessible by the executing node.

It is important to note that the execution of the MEVM is done by the executing node, which is defined by the developer in a smart contract, which simulates the transaction at the time of block creation and directs that it be processed according to its algorithm.

The actual block construction algorithm written in MEVM uses getState(), simulateBundle(), and exportBlock() to simulate getting the latest state of Ethereum and adding new transactions to a bundle or pending block, and proposing to the proposer.

This is an edge that cannot be used on Ethereum provided by MEVM, and it is the MEVM execution node that does the processing. It is also an efficient way to obtain private computation since it is known that code is processed with some privacy and integrity in trusted execution environments such as SGX, and will be incorporated in the next release.

However, these are just examples, and as mentioned above, there are others that can be built. For example, UniswapX and CowSwap in MEVM, and building new algorithms.

The barriers to deploying proprietary types of infrastructure on the MEVM are low, so a variety of contracts are created. Different applications are configured with the MEVM, creating a market environment where they can compete fairly in an open market rather than a single Flashbots Builder. SUAVE is also a collaborative block building project, but it is also a distributed platform that allows centralized infrastructure (builder, OFA, RFQ routing, etc.) to be built as smart contract on the MEVM.

4.2. Credible and flexible commitments

The vendors with superior top of block extraction capabilities have less incentive to participate in SUAVE in terms of inequality of economic opportunity because they have their own searchers, and the characteristics of HFT builders with superior top extraction capabilities make it more likely that in volatile situations, HFT blocks will be auctioned than co-built blocks. It is possible that HFT blocks may have a higher winning rate in auctions than co-built blocks in volatile situations.

Reliable Commitment is a solution to the problem of the auction being "designed to sell out the entire right to create blocks" and to individualize the auction opportunity by providing flexibility in the way proposers commit (exchange and enforce blocks).

PEPC（Protocol-Enforced Proposer Commitments）

PEPC is a protocol tool that allows proposers to make binding commitments to the blocks they build. This was proposed in the post "Unbundling PBS", published in October 2022.

Currently Mev-boost auctions enforce a single type of exchange between block builders and proposers. The exchange enforcement is provided by a trusted third party called a relay. ePBS is the Ethereum protocol providing the relay role.

The PEPC was born out of the question of whether proposers could have more flexible and programmable exchange agreements with block builders. and can commit to multiple exchange types, including;

• Full block auctions: delegation of full block construction to a single builder

• Partial block auctions: partial block construction to multiple builders

• Transaction inclusion lists: specification of tx to include

• Future block production rights: pre-determine commitment to use (partial) blocks of a particular builder

• parallel block auction: divide block space and auction off portions to individual block builders

• Slot vs block auctions: Can pre-commit to block content by committing to use only blocks from builders with specific hashes

• Other candidates that can be customized

PEPC is intended as a generalized infrastructure that does not rely on a single mechanism where a proposer delegates to a specific block builder and can make reliable commitments to the task of building blocks.

While extra-protocol mechanisms such as Eigenlayer already exist today, and validators can make commitments through external contracts, there are several considerations to be made.

First is the Principal-Agent Problem. Specifically, PoS delegates security to validators, but if a validator is cut out of the protocol by Eigenlayer, there will be a mismatch between the validator's incentives and the protocol's recognition.

In other words, the protocol may not know that the validator is committed to Eigenlayer, and when the validator does something dishonest with Eigenlayer, the protocol cannot recognize it, resulting in a gap in incentives.

The solution is to get everyone on the same page about what is happening outside the protocol and what the proposer is doing. Specifically, reduce the protocol balances based on performance outside of the protocol. This synchronizes the actual balances of the validators with the protocol's view. This is called the in-protocol Eigen Layer (IP-Eigenlayer).

The next thing to consider is that Eigenlayer commitments can only be enforced at the execution layer. If a commitment is not enforced, it is enforced after the fact by thrashing. This is called optimistic verification.

The enforcement of commitments made by PEPC is part of the fork choice rule and implies a stronger one. The proposer's commitment is moved from optimistic verification (the proposer can break the commitment, but is financially penalized for doing so) to pessimistic verification (the protocol does not allow the proposer to break the commitment and will void the block if the commitment is not met)

Since it is thus important to determine whether the commitment was entered into and properly fulfilled, the protocol must first distinguish several outcomes.

1. the proposer made the commitment and an external third party processed it

2. the proposer made the commitment and the outside third party did not process it

3. the proposer did not make the commitment

4. the proposer made a commitment and then committed an act that violated it For example, he stole goods from a third party for his own benefit

As a result 1 and 2 are valid, 3 has no commitment, and 4 is invalid, the protocol wants to secure only 1 and 2. As a result, it is important to identify 1 and 2, and equally important to ensure that the commitment is irrevocable.

The optimistic validation approach is for the attester to slashing the proposer if he creates an invalid block, but the incentives are misaligned. This is because if the value of the restaked validator is X, thrashing is not an optimal disincentive if the opportunity exists for the validator to benefit more than X.

So we need to consider a pessimistic approach. That is, instead of using Eigenlayer to access additional thrashing conditions, allow the proposer to create validity conditions for the block, and the attester will evaluate the validity of the block based on whether these conditions are met. This is called pessimistic validation.

In this way, PEPC enforces flexible commitments in the protocol, allowing for optimal delegation of block construction for each proposer.

PEPC-Boost

In PBS, there were two alternatives: in-protocol ePBS and out-of-protocol MEV-boost. So is in-protocol PEPC and its associated out-of-protocol alternatives possible in PEPC?

PEPC's FAQ proposes a proposed specification for PEPC-Boost that does not require changes to MEV-Boost. This implementation generates a block auction that splits the block between the top and the body. A new relay called PEPC-Boost is opened for this purpose, which has two endpoints;

• TOB endpoint (block top): a single transaction is accepted along with the bid

• ROB endpoint (rest of the block): accepts a list of transactions along with bids

The PEPC-Boost relay builds the block with the bids received from the TOB endpoint. A header signed by the relay is sent to the proposer with the TOB bid + ROB bid bids. However, the "single transaction" received by TOB can be abused by searchers, such as inflating the TOB bid price by stuffing multiple preferences into a single meta-transaction.

However, PEPC-boost allows for flexibility in the proposer's commitment, allowing the proposer to flexibly optimize the delegation, for example, delegating the block top to a single HFT builder and committing the body to SUAVE.

Separating the Cex - Dex arbitrage, which is the edge of the HFT builder, from the block body separates the auction by two competitive advantages: access to transactions and Cex - Dex arbitrage. This would increase the competitiveness of the system and reduce concentration on builders with some advantages.

Alternatively, Cex - Dex arbitrage applications and resources could be deployed in the MEVM; SUAVE's execution layer approach and PEPC's consensus layer approach are complementary and maximize user and proposer utility, limit the negative externalities of builder centralization.

There is a very large design space for the type of commitment and the use of external protocols such as Eigenlayer Mev-boost + / ++, PEPC-Boost, PEPC-DVT and others will likely be tested in the short term.

Conclusion

This article summarizes builder centralization. Below is a brief summary.

1. the top 4 builders currently hold 87% of the block builder market and 94% if up to 7 builders are included The top four builders compete with each other, and the top four builders are the only ones that can compete with each other. The top four builders have the potential to impose arbitrary rules due to their competitive advantage, resulting in a closed block building process. This means that there is a risk that not all fee-paying transactions will be reliably included in the chain, which could undermine Ethereum's censorship resistance, neutrality, and resilience.

2. Exclusive transactions and direct payments are important to win the right to build a block on MEV-Boost, but these are characteristics that are inaccessible to other vendors, creating "variation" in economic opportunity among vendors. The continued concentration of economic opportunities in the hands of a few builders will weed out small- and medium-sized builders and centralize block builders. 3.

3. There is also the risk of centralization of builders due to Dex-Cex arbitrage, which is a factor other than exclusive transactions and direct payments. It is suggested that block top construction is superior to builders that integrate with searchers. Builders such as beaver and rsyc, which have superior block top extraction capabilities, may increase their win rate during times of high volatility and ultimately gain block share.

4. SUAVE can solve exclusive trades if the trade sender sends the trade to builders other than the exclusive builder, and SUAVE creates an incentive to do so through auctions. It is more profitable to share transactions in an open manner than to sell them or hold them exclusively for oneself, and it neutralizes exclusive transactions because transactions sent to SUAVE can be accessed permissionlessly by any block builder. 5.

5. the PEPC is intended as a generalized infrastructure that does not rely on a single mechanism for proposers to delegate to a specific block builder, but allows sophisticated proposers to regain agency (freedom to act) and make credible commitments to the block building task. the SUAVE and PEPC's complementary relationship may curb the negative externalities of builder centralization.

Reference