Skip to main content

Illuminating Trust Reliance in Ethereum's Transaction Supply Chain

· 15 min read


One of the most valuable properties of many blockchain applications is trustlessness: the ability of the application to continue operating in an expected way without needing to rely on a specific actor to behave in a specific way even when their interests might change and push them to act in some different unexpected way in the future. Blockchain applications are never fully trustless, but some applications are much closer to being trustless than others.

-- Vitalik


Let's follow a trade through CowSwap:

  • The trader completes the order form, signs it, and sends it to CowSwap's backend, trusting that CowSwap will act honestly and not engage in malicious activities like collusion or censorship.
  • CowSwap matches the trade, forwards it to a builder, who also has the potential to exploit or censor the trade.
  • The builder then includes the trade in the block sent to a relay; yet another trusted party that could misuse the trade.
  • Relay finally passes the block to a validator, who finally includes it on the chain. Here, relay doesn't need to trust the validator, although the validator needs to trust the relay.

In less than 12 seconds, the trade passes through three trusted intermediaries, each with the potential to abuse it.

In reality, the misuse of the trade is very unlikely to occur, mainly because these intermediaries aim to preserve trust and customer loyalty. CowSwap relies on traders choosing it over other platforms; the builder relies on receiving valuable private transactions, and the relay relies on high-value blocks.

For each of them, taking advantage of the trade could kill their business. Therefore, traders have to assume that the value these entities place on continuing the business is higher than the value they can extract from the trade. This might have been the case so far, but no one can guarantee it will be for all future trades.

As the example suggests, the transaction supply chain currently depends significantly on trusted entities and their reputations. Transactions pass through multiple intermediaries from their initiation to final block inclusion. For some actors, the only deterrent against profitably deviating from user expectations and abuse is their reputation, leading to centralisation, potential exploitation risks, and impeding innovation.

We'll shortly investigate two key parts of the transaction lifecycle that depend on these trusted actors: block building and order flow auctions. We'll explore the reasons why these trusted actors were initially introduced and whether their presence now poses a risk to the ecosystem.

Proposer-Builder Separation

Proposer-Builder Separation (PBS) was introduced to address the centralizing spiral in block production on Ethereum.

Why is PBS needed?


Let's take a quick trip back in time:

Before Ethereum's transition from Proof of Work (POW) to Proof of Stake (POS), miners had sole control over block creation, leading to practices like transaction reordering for MEV¹ extraction and prioritizing their own transactions.

This favoured larger mining pools, who were, due to their size and reputation, in a better position to form trusted relationships with trading firms. Without any credible mechanism to form these deals, they were mostly done under the table. This was explored in the Flashboys 2.0 paper and publicised with a tweet by Wintermute's Igor Igamberdiev in 2020, highlighting searcher-miner collusion that was taking place. In response, Flashbots created MEV-Geth, increasing the transparency of these deals and making them accessible to more miners.

After The Merge, block production power shifted from miners to validators. Similar to their predecessors, validators now had two roles by default - block creator and block proposer. The need to separate these two roles arose due to a concern over centralization of validators as a result of economies of scale involved in MEV extraction.

Enter PBS:

PBS aimed to address the concern by allowing validators to outsource the block creator role to a specialized external party called block builders. MEV-Boost is an implementation of PBS by Flashbots, introducing two new actors to the ecosystem: builder and relay. The builder takes over the validator's role of creating a block, and the relay serves as a trusted intermediary between them, receiving blocks submitted by builders and submitting the most profitable to the validator. Thus, the relay serves as an essential actor in the current block building landscape under PBS, one that helps prevent builders from making empty promises to validators and validators from stealing builders' blocks. Now, with MEV-Boost, even a solo validator has the same opportunity to get as much MEV for their blocks as the biggest validator pool. So it is no surprise that according to, at the time of writing, around 90% of the validators used MEV-Boost and effectively participated in the PBS system,

For MEV-Boost to democratize access to MEV among validators, it needs to rely on trusted actors. We'll explain why that is the case.

Why does PBS Need Trusted Actors?


Searchers seeking profitable transaction ordering must place their trust in builders to not only avoid theft but also to refrain from exploitation or misuse of their strategies. Likewise, builders must trust that the relays to which they send blocks will act honestly, neither stealing the blocks nor favouring one builder over the other. Similarly, validators responsible for proposing blocks are reliant on relays to supply them with the most profitable blocks.

The following aspects are some of the requirements making trustless PBS participation a difficult task:

  1. User Privacy Needs: Block builders and relays handle sensitive data, which, if exposed, could lead to MEV strategy leaks, making the data prone to theft or attacks. To put it in perspective, this post explores how a bug in the MEV-Boost caused a validator to attack and unbundle searchers' bundles, causing more than $20 million loss. PBS without privacy would offer blocks to validators without giving builders a chance to be compensated for their work, further highlighting the need for strict data confidentiality.

  2. Computational Challenges: Constructing an optimal block is equivalent to solving the NP-hard knapsack problem. While deriving a greedy solution from given transactions is not considered to be computationally intensive, finding the optimal solution among interfering transactions and conditional bundles is. The process is too intricate and resource-intensive to be feasibly executed in any trust-minimizing environment as we know it today.

  3. Coordination Within Block Time: Timeliness is crucial in block construction. Blocks need to be built with constantly arriving transactions, sent to relays, then to validators, all within Ethereum's 12 second block time. This is especially true for traders who trade with respect to off-chain markets where latency is key to staying competitive. These lucrative strategies push PBS actors toward lower latencies. For further reading on this: Eth Research post, Frontier post, Blocknative post, SMG visualisation, live chart.

  4. Access to Off-Chain Resources: Builders require access to off-chain sources, including relays and external data like beacon chain information.

Given these factors, it becomes clear why removing reliance on any of the trusted parties from PBS is a difficult challenge. The combination of privacy concerns, computational complexity, time-sensitive coordination, and reliance on off-chain components creates a scenario where trustlessness, a core of blockchain philosophy, is difficult to maintain without compromising on these essential attributes.

But is it so wrong to rely on trusted actors in this case? Let's explore.

What are the detrimental effects of PBS trusted actors on the ecosystem?


Sourcing profitable order flow (OF) is a key factor in block builder competition. OF encompasses both transactions and trade intentions expressed through cryptographic commitments.

The sources of OF, known as order flow originators, want to secure the voyage of their flow and protect it from exploitation. Searchers, in particular, are worried about strategy theft and the risks associated with unbundling non-atomic strategies. This unbundling concern extends also to transaction-based order flow auctions, and any kind of trade faces frontrunning risks.

This is why it is necessary for order flow originators not to send order flow to just any builder, but only to those with the most to lose if they cheat their source of flow.


Thus the biggest and most reputable builders tend to receive a majority of the OF further increasing their dominance and leading to a centralization spiral.

The existing dominant builders, with their vast resources and access to valuable order flow, have a significant competitive advantage. New players wanting to innovate need to compete, not just with these established entities, but also overcome the challenge of securing a reliable order flow, which is crucial for success in the ecosystem. This presents a high barrier of entry for new builders and could in turn suppress the innovation.

With more building power concentrated in the hands of a few, these entities might engage in censorship due to various factors, including government regulations or self-interest. Such censorship can degrade user experience and cause financial losses, as transactions may be delayed or blocked until a willing builder is found.


In essence, PBS was designed to decentralize effective block production and shift the economies of scale away from consensus actors to the block builder role. Now, the imbalance in the distribution of building power, and the reliance on a few trusted actors, hampers the fundamental ethos of blockchain technology, which is built on decentralization and equal opportunity.

Order Flow Auctions

Order flow auctions (OFA) act as a marketplace, allowing users to sell their OF to the highest bidder. The value that would've been captured by MEV bots and sent to the validator now flows to the OF originator.

Why are OFAs needed?

In a significant AMM² trade, relative to the pool liquidity, you may cause the pool to rebalance just enough to create an arbitrage opportunity between the used pool and another non-rebalanced one. If your transaction is public, it creates a scenario where certain MEV parties value the chance to trade right after you and are willing to pay for this privilege. They must incentivize the block builder to strategically place their trade within the block to achieve this. However, since you're the one creating the transaction, you could choose to privately sell it for a certain price instead. Various auction types can assist in discovering this price and the parties involved.

This is essentially the mechanism behind platforms like MEV-Share and MEV-Blocker:

  • Users submit their transactions to the platform,
  • the platform offers the place under the transactions to the highest bidder,
  • part of the bid is used to repay the user.

One might wonder if it's necessary first to create an arbitrage opportunity with your trade and then claim the value back. In reality, no.

Rather than trading directly through a single pool, an aggregator could distribute your trade across different ones. However, using an aggregator still requires trusting a single entity to find you the best trade path. Having multiple parties search for the best path for you could yield better results - imagine an aggregator of aggregators.

One way to achieve this alternative could be through an auction that states your desire to swap X for Y and makes parties compete with each other to find the best execution path for a fee. This method, already in use by platforms like UniswapX, 1inchFusion, and CowSwap, essentially utilizes an intent-based order flow auction.


Flashbots' Orderflow dataset reveals that in November 2023, nearly 30% of Ethereum's order flow was managed by one of the top three intent-based OFA protocols - CowSwap, 1inchFusion, and UniswapX. Similarly, during the same period, around 20% of Ethereum orders went through one of the transaction-based OFA protocols - MEV-Share and MEV-Blocker.

Why Do OFAs Need Trusted Actors?

At the time of the writing, most, if not all, implemented OFAs use trusted, centralized solutions for their operation. While a trustless OFA is feasible today, it faces limitations due to the need for:

  • Cheap and performant computation: Order matching, bid validation, and checks for malicious activities are crucial for complex OFAs. High computation costs lead to higher auction costs, which in turn make them less competitive and, therefore, less attractive for trading.
  • Private storage and computation: Certain auction types require bids to remain private. Public auctions can leak trade intent, potentially causing financial loss for the seller.
  • Quick coordination: OFA needs to form consensus over submitted bids, and the shorter the coordination time, the less time participants are locked in an auction and exposed to the involved assets. Certain auction types, like Dutch auctions, are particularly sensitive to this factor as it affects the granularity of the price change. All trustless solutions we know today are bounded by their block time.

What are the Detrimental Effects of OFA Trusted Actors on the Ecosystem?

There's a market need for OFA, and their current centralized, trust-reliant nature is understandable. However, there's room for improvement as their current implementations have several drawbacks for the ecosystem and its participants.


The present OFA ecosystem heavily relies on a trusted central authority of intermediaries. Centralized entities can censor based on their own criteria or external pressure and their lack of transparency also increases the risk of manipulation and preferential treatment.

Consequently, participants are cautious about which OFA to use, often opting for the most reputable. While reputation is a safeguard, it's not infallible and can hinder innovation by raising the entry barrier and giving existing players a competitive edge. This introduces a risk that a few entities will hold most of the OF, which could lead to higher costs, censorship, lower quality and fewer options available.

OFA solutions, each with their own trust model, create overlapping trust issues, making it challenging to build upon or connect with them without explicit consent, further impeding innovation.

Imagine you want to build a cross-platform intent system to search for coincidence of wants (CoW) across 1inchFusion, CowSwap, and UniswapX. Right now, you would need to convince all of these platforms to trust your system. The users that interact with only one of them would need to trust all three platforms, plus your system as an intermediary, making such a system difficult to create.

If all the entities (1inchFusion, CowSwap, UniswapX, and your system) had the same trust assumptions (or not have them at all), the user wouldn't need to worry about trusting one over the other, and the idea of your CoW cross-platform system would be much more feasible.

Additionally, the detrimental ecosystem effects could include scalability issues, as centralized OFAs may face challenges in handling increased demand and adapting to market changes, leading to potential bottlenecks. There are also concerns about fragility, where such systems are more susceptible to failures and attacks due to single points of failure and concentrated security threats.


Both PBS and OFA play a crucial role in the blockchain landscape as we know it today. PBS keeps the system from the centralization of consensus actors, while OFA offers users a chance of a better trade than the alternatives. That said, these mechanisms are not without their flaws, primarily stemming from their reliance on trusted actors to act according to users' expectations.

To operate effectively, both systems require cheap, performant and private computation as well as storage, quick coordination and access to off-chain resources, all of which are difficult to maintain with any trustless system as we know today.

These trust dependencies in both PBS and OFA present significant drawbacks. Reliance on a few entities raises the risk of centralization and censorship, and goes against the blockchain ethos of decentralization, lacks robustness and creates barriers to entry that suppress innovation.

Next Steps

This compels us to question: can we do better? Is there a feasible model that retains the benefits of PBS and OFA while minimising trust?

Such a model would need to offer cheap and performant computation, private storage and computation, quick coordination, and access to off-chain resources, all while aiming to minimise trust.

In the next blog post, we will explore SUAVE, one of the solutions that aims to do just that.

Special thanks to Can Kisagun, Lily, Turan Vural, Quintus, Dmarz, L.V. and Eden Network team members for feedback and suggestions.


MEV¹: Miner extractable value in POW. Maximal extractable value in POS. It refers to the maximum value that can be extracted from block production in excess of the standard block reward and gas fees. This value is often associated with strategies such as arbitrage, liquidations, sandwiching, just-in-time liquidity, ICO sniping and others.
AMM²: An Automated Market Maker (AMM) represents a distinct type of exchange, eliminating the need for active market makers to continuously update prices. In this system, liquidity providers contribute in a passive manner, with price discovery primarily driven by arbitrage activities. Prices within an AMM are set by a predefined formula, which governs the relationship between trading pairs. Owing to its cost-effective operational model, which is significantly less expensive than traditional order book systems, AMMs have emerged as a popular option for markets operating on blockchain platforms.