# MEV Blocker rules for Builders

MEV Blocker was created to allow anyone to safely use Ethereum, guaranteeing fast inclusion time, protection from attacks, and rebates whenever there are profitable backrunning opportunities. Achieving this ambitious objective requires a source of revenue to support the technical maintenance of the product and to drive continuous growth in users’ adoption. Furthermore, MEV Blocker wants to be an open, shared infrastructure. As part of this effort, it is important to have clear and transparent rules determining which builders can receive its flow.

The purpose of this document is to spell out clearly the rules that builders should follow. One of these rules is that builders should pay a fee. This document also explains the new fee mechanism and its rationale.

We expect these new rules and the fee to come into force starting April 8th 2024.

## Rules

The basic technical requirements to start receiving flow are:
* Build at least 1% of the blocks each week of the previous month.
* Send all blocks to Agnostic relay (not exclusively) so that, in the future, we can perform statistical analysis and build interesting metrics.

*We reserve the right to disconnect a builder who drops significantly below the 1% threshold while connected to MEV blocker. Also, the fee will always be calculated as if the builder won at least 1% of blocks (see the discussion about the fee adjustment below).

Furthermore, some builders may decide to support refund bundles and replacementUuid(or uuid) for updatable bundles. These builders will receive MEV Blocker transactions and bundles immediately and must maximize the refunds received by MEV blocker’s users. In particular, they should, for each transaction, always include the highest-paying bundles plus other bundles that do not fail (in the combination that maximizes the refund). If they comply with this rule, they can perform additional blind, end-of-block backrunning.

Builders who do not support refund bundles will receive transactions with a delay. The purpose is to give time for searchers connected to MEV Blocker to create bundles. These builders are not allowed to perform any backrunning of any sort (internal, blind, whatever).

Independent of their support for bundles, all builders connected to MEV Blocker are required to:
* Refrain from unethical activities that may hurt MEV Blocker users. This includes but is not limited to:
* No frontrunning, no sandwiching
* No state or transaction sharing/leaking in any form
* Provide good service: timely inclusion of a transaction (or a bundle) if its effective gas price is larger than the lowest-paying transaction included in the block.
* Keep at least 10 ETH in a bonding pool. These funds will be used to cover late fees and penalties.

We reserve the right to disconnect builders suspected of violating these rules. If wrongdoing was established, we reserve the right to charge the violating builder any damage caused and require a re-subscription fee of 10 ETH. For example, suppose it is possible to include two bundles for the same transaction, but the builder only includes one, hence failing to maximize the refund. Such a builder may be asked to pay as damage the reward from the missing bundle (plus 10 ETH reconnection fee).

# The Fee

All builders connected to MEV Blocker will pay a per-block won fee recomputed every period (for example, every month). In practice, at the beginning of period t a builder decides whether to receive flow from MEV blocker. If it decides to do so, for every block won during period t it will pay a per-block fee calculated as a percentage of the the average per-block value of exclusive MEV Blocker transactions during the previous period. Mathematically, the per-block fee is a percentage of


Where
* At-1 = Total MEV Blocker transaction value during period t-1, excluding kickbacks
* Bt-1 = total value of MEV blocker transactions also in the mempool during period t-1.
* Ct-1 = number of blocks mined by builders receiving MEV blocker transactions during period t-1

Initially, the fee will be 20% of the above value, and the length of the period t will be 1 month. We may adjust both variables later on. Note that the fact that the fee is *per block* does not mean that it will be paid with each block: we will keep track of it off-chain and settle it weekly via a payment to a dedicated Safe*. We’ll compute the value of the per-block won fee using publicly available data, in a format that is easy to verify (for example, as a Dune query). We’ll then post its value on chain for easy access by builders. Similarly, we’ll use publicly available data and easy-to-verify scripts to keep track of the total fee each builder should pay and the flow of payments.

Finally, for builders who won fewer than 1% of blocks during a given week, the fee will be adjusted so that these builders pay as if they won exactly 1% of blocks during the week. In practice, at the end of each week, these builders pay

1% (total blocks mint during the previous week) * 20% Mt-1

*Hence, the settlement period for the payment (one week) differs from the frequency at which the per-block won fee is computed (one month).

## Why this fee mechanism?

An intuitive notion of fairness dictates that each builder should pay for the value of MEV Blocker transactions it uses. At the same time, an important objective of the mechanism is to be as non-distortionary as possible: it should not affect the decision to include or not include a transaction by a builder. A fee constructed simply as a fraction of the tip of each MEV Blocker transaction risks creating distortion. Furthermore, on the implementation side, it would require a new API.

The proposed solution instead does not require any new API and is unlikely to create distortions. It is also built to be correct *on average*: if builders do not disconnect and win more or less the same fraction of blocks between periods, they end up paying with a month delay the average value of MEV transactions they received during the previous month.

It is also important to stress that this is the first iteration of the fee mechanism. For example, in the future, we may compute the fee as a fraction of the MEV Blocker tx value included by non-winning builders for the same slot. Intuitively, that would be a proxy for the value from MEV Blocker available to the winning builder, independent of this builder’s decision to include this or that transaction. This mechanism cannot be implemented now because Agnostic relay does not store any data regarding blocks built by non-winning builders, but this could change later.

## Who pays the fee?

To understand who pays the fee incidence, we need to consider two cases. If a single builder receives MEV Blocker flow, then introducing the fee is at the expense of this builder’s profits: if this builder wins, it wins less (by an amount equal to the fee) and is less likely to win because it will bid lower. If, for simplicity, we ignore this second effect, on average, the builder pays 20% of the value of MEV transactions as a fee while keeping the remaining 80% as profits.

At the other extreme, suppose that all builders are connected to MEV Blocker, and hence, after the fee is introduced, they all have to pay it. Now, for all builders, winning a block is less valuable by an amount equal to the fee. If we think of the auction as a second-price auction**, this should lead all builders to decrease their bids by an equal amount. But because the winning builder earns the difference between its bid and the second highest bid, the winning builder’s profits are unchanged. The only difference is that all bids are lower, and hence, payments to validators are lower. In equilibrium, the fee is paid indirectly by the validator.

Our hope is that the majority of builders will stay connected to MEV Blocker and that the fee will reduce the payments to validators (i.e., MEV). At the same time, we expect the mechanism to be overall beneficial to builders, including in the case where only one or a few builders connect (and end up paying the fee out of their profits).

**In reality, the auction is an ascending, English auction, with a last part that, because of latency, is similar to a sealed bid auction. Modulo some considerations around information leakage (that aren't too relevant for builders) ascending auctions are very similar to second price auctions because the winning bidder only needs to outbid the second-higest bid by a small amount. Furthermore, the auction is in private value because once a builder creates a block, its value is independent of the value of the other builders’ blocks. The revenue equivalence theorem then says that, even if the auction is not a second price auction, when deriving the builders’ expected payoffs we can thing of it as if it was a second-price auction.