Builders on MEV - Analysing the impact of the OFAC sanctions on Block Builders.

Quantifying Censorship

This leads us to the topic of censorship discussions, which were particularly prevalent in December of last year. Not every party in the ecosystem is willing to include every arbitrary transaction in their blocks, but rather filter out transactions that are sanctioned in certain jurisdictions. In the following we will look into the level of censorship of block builders, starting of with the definition of our TC-estimator.

How many Tornados are there?

Looking at all slots since the merge, 1.418% of them contained blocks with OFAC sanctioned transactions. For large enough samples, assuming a binomial distribution, the 1.418% represents a credible estimate of the average number of blocks with sanctioned transactions per builder and validator. By using this approximated OFAC-inclusion rate and comparing it to the inclusion rates of individual builders, we can probabilistically infer their censorship practices.

Regarding the gas price paid for Tornado Cash transactions, the diagram shows that there is no significant difference in the gas prices paid for Tornado Cash transactions compared to the total number of transactions. The diagram suggests that, although users of the Tornado Cash contracts may not necessarily require timely execution, the paid gas prices follow the overall trend.

This is important, because if sanctioned transactions would pay significantle less gas, then, what appears to be censorship, could just be an economically rational builder that doesn't include low-paying transactions in its blocks, no matter if they're on a sanction list or not.

It is worth mentioning that the performance of Tornado Cash's native token, TORN, may already be negatively affected by delays when being traded on a decentralized exchange (DEX), resulting in a poor user experience.

Builder Censorship

It can be challenging to accurately classify builders as censors or non-censors. For small builders, the number of transactions that are subject to censorship is so low that they can claim that either no sanctioned transactions were present in the mempool or that the transaction fees were not high enough to be included in a block. However, for larger builders, we can use probabilistic methods to determine if they are censoring. Block builders rely on relays to forward their payloads to validators and many builders may operate under the policies of their preferred relays. 

The censorship policies of a particular relay can have a cascading effect on builders, who may eventually adjust their own strategies accordingly over time. Furthermore, certain builders may possess superior algorithms or proprietary order flow information, which gives them a competitive edge over their peers. Builders who censor by default lead to censored blocks being sent to non-censoring relays.

In general, builders that are operated by a relay-operator may have certain benefits when it comes to submitting to the builder-owned relay. A greate post by Aestus Relay on that topic can be found here.

But let's diretly get into the numbers:

In Table 1, we see the largest block builders and their (relative) number of blocks that contained OFAC'ed transactions.

It is worth noting that while builders such as beaverbuild or builder0x69 are (partially) non-censoring builders, they are not truly comparable to the Manifold builders. While 18.54% of the blocks produced by the Manifold builders contain at least one OFAC-sanctioned transaction, the numbers are significantly lower for beaverbuild with 3.22% and builder0x69 with 0.82% Tornado Cash transactions in their blocks. 

Without accepting the censorship imposed by the Flashbots relay, beaverbuild and builder0x69 would not be able to compete, as most blocks are delivered via the Flashbots relay. This would result in them losing their leading position in the block building market. Therefore, censoring in times when the majority of validators is connected to a censoring relay, allows them to get most of their blocks on-chain and maintain their competitiveness in the market.

As shown in Table 1, both beaverbuild and builder0x69 fall below the average TC-inclusion rate of 1.418%. However, when comparing the two directly, beaverbuild fares better, producing more blocks than the average TC-inclusion rate. Out of the 31 builders with more than 200 blocks, 9 have a TC-inclusion rate of more than 1.418%. The remaining 22 builders have built less than 1.418% non-censored blocks. Among the largest 30 builders (each with more than 200 blocks), 7 have never built a block with OFAC-sanctioned transactions.

In the above diagram, we display the binomial distribution of the number of TC blocks over 1000 trails (blocks) with a propability p of 1.418%. Notably, we can see that beaverbuild builds significantly more non-censored blocks than expected. The same applies for the BloXroute builders. On the other side, builder0x69 and BuildAI fall clearly below the average TC-inclusion rate p. A possible explanations is that beaverbuild predominantly sends to two different relays, the Flashbots and the BloXroute (mp) relay, while builder0x69 primarily uses the Flashbots relay.

So, what's the reasons for censoring?
It is not entirely clear why certain builders censor specific transactions, aside from legal implications. Furthermore, the censorship practices of each actor within the protocol can have a cascading effect on one another. Therefore, it is beneficial to analyze various scenarios using game theory in order to better understand the problem:

Censoring as a dominant strategy. Builders have the option to construct censored or non-censored blocks, or both. If they opt for censored blocks, there will be no relay that will reject them, resulting in the builder's expected outcome of profits minus costs. However, if builders choose to create non-censored blocks, they must speculate that the current validator is also using a non-censoring relay, otherwise the block will be wasted. Additionally, building two separate blocks incurs additional computational costs or opportunity costs in the forms of not spending 100% of the available time in maximizing the profits captured in a single block. Ultimately, censored blocks are only a subset of all possible valid blocks. Therefore, building censored blocks may be the most economically rational choice for builders.

A possible explanation for the 18.54% of blocks with sanctioned content at Manifold is that these builders only submit their blocks to the non-censoring Manifold relay.

This suggests that the dominant strategy for Manifold builders may be to only construct non-censored blocks (or to focus solely on transaction fees). This could account for the relatively high number of uncensored blocks observed in Table 1. In contrast, other builders such as payload.de or Philon also submit blocks to the Flashbots relay, thus must have some logic in place to differentiate between censored and non-censored blocks.

Validator anticipation. Since validators (future block proposers) have some time to prepare for their slot, builders can theoretically use this information to maximize the number of uncensored blocks built. This would involve the builder querying the relay registrations of the upcoming validator and (1) if the validator is using censoring relay(s) only, building a censored block or (2) if the validator is using at least one non-censoring relay, submitting an uncensored block to that relay. 

However, by following a censored-blocks-only strategy, builders can avoid the need to develop separate logic for handling censored and non-censored blocks. Instead, they can construct “univerally applicable blocks” that every relay, thus every MEV-Boost-using validator, accepts. While missing out on potential profits captured in santioned transactions, such builders can compete with the same block in every single slot auction, regardless of whether the validator is connected to a censoring or non-censoring relay.

Why censoring builders win?

Even if the majority of builders and relays are non-censoring, the outcome of the MEV-Boost auction is determined by the payment made to the validator. Therefore, it's ultimately a builder's profitability that determines whether their blocks get attached to the chain. 

With respect to proprietary order flow, censoring block builders might have a high enough economic advantage over their competition to continuously outbid non-censoring builders. This could result in users, who engage with sanctioned entities, ultimately paying a higher price or waiting for a certain period of time.

Vitalik wrote a comprehensive article on censorship and PBS, including a great example to model the economics behind censoring through proprietary order flows. The following will adapt the scenario outlined in that article to fit the context of this post.

• Let A denote a non-censoring builder and C a censoring builder. 
• bid represents the bid of the respective entities, such that bid(A) is the bid of builder A  . 
• Let m denote the MEV + transaction fees captured by a builder from the public mempool, without including any santioned transactions (so the value that can be caputed by every builder, no matter if censoring or not)  
• Let o denote the value originating from the proprietary order flows (or better algorithms) of an entity, such that o(C) + m(C) = bid(C)  .
• Finally, f are the transaction fees (+ MEV) extractable from a certain set of sanctioned transactions such that f(TC) are the fees paid for a sanctioned Tornado Cash transaction. Following, a non censoring builder bids o(A) + m(A) + f(TC) = bid(A)  .

We assume that 90% of the validators are using MEV-Boost, 100% of relays are non-censoring and that every block is full.

In the case that the proprietary order flow of the censoring builder is higher than the one of the non-censoring builder, even including the fees originating from censored transactions, o(C) > f(TC) + o(A) , while m(A) = m(C) the censoring builder wins every slot with censored blocks and a TC users would have to wait ~ 10 slots (120 seconds) until the TC transaction would be included. For non-censoring builders, to win the bid, the transaction fee for that sanctioned transaction would have to be at least o(C) - f(TC) + o(A)  , allowing the non-censoring builder to then out-compete the censoring one.

Thus, as long as o(C) > f(TC)  , non-censoring builders lose in the block auction to censoring builders who have access to proprietary order flow or use better algorithms.

For a Uniswap transaction, the situation may look different because of the pressure to get the transaction executed in timely manners before the transaction would eventually revert. If Uniswap U were to be sanctioned, the value f(U) would represent a significant share of each block, powered by the large demand for Uniswap trades. Furthermore, f(U) would contain significant amounts of not-yet-extracted MEV which censoring builders could no longer capture.

Thus, having f(U) > o(C) and m(A) = m(C) , there's no chance for the censoring builders to compete with the non-censoring ones. In such a scenario, censoring builders would be forced to give in or stop operating.

In fact, comparing the Manifold builders with those of Flashbots, we can see that the inclusion of sanctioned transaction doesn't lead to a significant increase in block value. In terms of profitability, the censoring Flashbots builders clearly outperform the non-censoring Manifold builders. For the sake of completeness, it's still only 1 out of 5 blocks of the Manifold builders that contains a sanctioned transaction and the total number of sanctioned transactions is way to small to significantly contribute somthing to the blocks value. Thus, the reasons behind the differnece in profitability as shown the above chart are more likely due to proprietary order flow and better transaction-ordering algorithms.

Conclusion

It is not straightforward to determine the reasons why certain builders censor. Furthermore, it's hard to measure the impact that validators and relays have on the censoring practices of builders. Builders may censor because their want to comply with the OFAC sanctions or because it allows them to maximize the blocks they get on-chain. Most validators are connected to the Flashbots relay, forcing competetive builders to censor in order to reach those validators with their blocks. Consequently, builders may just construct “universally applicable blocks” (that work for every relay thus have to be censored) out of convinience and submit them to every possible relay, causing censored blocks to be broadcasted over non-censoring relays. Additionally, the individual performance of a builder and its access to proprietary order flow are important to be considered. Proprietary order flow may enable censoring builders to outbid non-censoring builders, despite the latter having access to the additional transaction fees and MEV caputred in the santioned transations.