Fees and CoW bonding for MEVBlocker

[koeppelmann]

https://mevblocker.io/ is a project by Cowswap in collaboration with Gnosis and Beaverbuild.

It provides a simple RPC endpoint for users to connect to. If they connect to this endpoint their transaction will not be sent to the public mem-pool, but instead they will be forwarded to specific block builder that must agree to treat those transactions in a specific way.

There are more details to the exact rules but a core idea is:

a) no frontrunning
b) no other form of deliberate ordering that put the user in a structural disadvantage
c) backruns are allowed by any searcher - but 90% of the value needs to be refunded to the user.

For MEVblocker the following challenge arises:

• to what builder to submit transactions.

Pro:

• submitting to more builders means faster inclusion time for users
• submitting to many builders prevents builder centralization

Con

• every builder poses a risk of misbehaving (either malicious or simply miss-configurations)

It had happened in the past that builders had muss-configured setups that lead to leaking transactions. Unfortunately it is not immediately attributable to one builder. So to detect the faulty builder we had to send individual “honeypot” transactions to different builders. By sending a transaction only to a single builder it is possible to reveal them as the faulty player.

Builder monitoring and curation is effort. Also, if builders misbehave there should be an option to “slash them” (make them pay for their damage - and potentially refund effected users if possible)

Those considerations lead to the conclusion that it makes sense for builders to be “bonded” in a similar way as Cowswap solvers are bonded. Finally, adding a revenue source to MevBlocker would allow the Cowswap team to put in more resources into MevBlocker and make sure it remains a high-quality endpoint that gives its users the desired properties. (max speed, max protection, max refunds).

I am proposing no a simple fee model with the interesting property that it will be neither at the expense of users nor builders, but instead validators.

Here is a statistic about how much MEVblocker transactions daily pay to validators.

Right now it is on average around ~70 ETH per day. We could add a rule that builders are forced to convert 10% of that amount into COW tokens. 50% of those CoW tokens could be burned and 50% could be “staked/ locked” by the builder. Each builder would thus accumulate COW tokens that would be its “bond”. Eventually, those COW tokens belong to the builder but initially, they need to be locked until they reach a specific size.

Note that this rule will not cost builders money. Builders can decide for themselves how much of the total block value they give to the validator. Having access to the MEVBlocker order flow generally is an advantage for builders vs. those who do not have access. So as every builder has to pay the 10% fee - they can simply reduce the amount they bid to the validator.

[netrunner.eth]

This is an interesting proposal and is a good thing for CoWDAO and the wider Ethereum community.

[mikey0x]

1. What led you to decide that 10% is the optimal fee and what alternative percentages did you consider?

2. I get the idea that it technically doesn’t cost builders anything, but adding this fee might reduce the amount they bid, which reduces likelihood of winning the block. The count-point is addressed in point 3.

Let’s say these builders bid 10% less because they want to keep their profit margin the same; there might be some lost blocks because usually, the difference in bid and 2nd highest bid is pretty nominal: average bidding surplus per block is 0.0027 - 0.0036 ETH. In percentage terms, seems like it’s only 2-5%.

For sources, skip to 17:17 and 17:35: https://www.youtube.com/watch?v=9VJFARFofGc&t=1055s&ab_channel=ETHGlobal

3. “Having access to the MEVBlocker order flow generally is an advantage for builders vs. those who do not have access.” Do we have quantitative figures around this? How much of an advantage is this? Could use this data to better optimize the fee rate.

[fleupold]

Let’s say these builders bid 10% less because they want to keep their profit margin the same;

It might be important to note, that the main bid, the one that decides how much the user gets refunded, is coming from searchers who have no incentive to change their bidding strategy if a fee from builders back to MEVBlocker was charged (searcher profit margin is not affected).
It is absolutely expected that builders will pay 10% less to validators for these blocks (ie not subsidise them), however this will in practice likely only have an effect on inclusion times if the block is completely full. Otherwise - unless the tip was chosen extremely low - a builder would still be better off including a transaction that satisfies the base-fee and has a non zero tip even if it only pays 90% of the user specified value. Thanks to EIP1559 most blocks are not full.

I don’t think the optimality of the 10% has been formally studied, but it aligns with the split we already apply for user refunds.

[fleupold]

I wanted to also mention some feedback and an alternative proposal that was raised from the technical team. The proposal as stated leads to the most successful builders accruing the highest bond. However, the damage from leaking private flow is the same for all builders regardless of inclusion rate (as they all have access).
Moreover, creating consensus on which flow was received by us vs. other means may become hard to verify and enforce in practice.

An alternative approach would be to change the way MEVBlocker forwards transactions: Currently the RPC immediately forwards each user transaction as a single-tx bundle to builders, and - as it receives bids from searchers - also sends those tx + backrun bundles to the connected builders (with a refundPercentage of 10% and refundRecipient being the user) for them to merge and chose from.

Instead of sending many individual bundles to builders, MEVBlocker could itself create and update a single mega-bundle with all user transactions that haven’t received any backruns (potentially addtionally limited to the ones it believes to be exclusive flow and that aren’t likely to revert). It would broadcast the latest version of that bundle to all connected builders and demand a refundPercentage of 10% on that single bundle with refundRecipient being itself. This way builders don’t need to do anything to “integrate”, the fee would be completely transparent to them. Transactions with backruns would be broadcasted as currently.

This is less efficient than the original proposal, because it would require another 21k gas native ETH transfer (for the refund) in every block. In the majority of blocks 10% of tips is likely not enough to allow for this transfer. We will try to collect data on the exact efficiency loss in the coming weeks.

[Olga]

I accidentally deleted the previous post, so resharing again.

I would like to share some data insights regarding 2 main proposals.

Proposal 1
The original proposal in the post suggests:

a rule that builders are forced to convert 10% of that amount into COW tokens. 50% of those CoW tokens could be burned and 50% could be “staked/ locked” by the builder. Each builder would thus accumulate COW tokens that would be its “bond”.

On average it should be reaching 300ETH/month.

Proposal 2
Alternative proposal suggests:

Instead of sending many individual bundles to builders, MEVBlocker could itself create and update a single mega-bundle with all user transactions that haven’t received any backruns… It would broadcast the latest version of that bundle to all connected builders and demand a refundPercentage of 10% on that single bundle with refundRecipient being itself.

This is a more costly proposal because it would require an additional 21k gas for the transaction. This way, the monthly estimated value would way lower because for most of the transactions’ tips the gas fee would be higher than 10% of the tip (specifically, around 7% of the blocks would be positive).

As mentioned before, this is a less efficient option but it would still generate additional ETH stream.

The image below represents a monthly revenue stream from the described proposals:

The original source of the data can be found here.

[AndreaC]

After lengthy discussions among MEV blocker’s partners, I’m thrilled to announce that we agreed on a fee mechanism! We will provide all details in a separate thread (in preparation for a new CIP). However, I wanted to give here a high-level explanation of the proposal.

As the discussion here highlighted, the fee mechanism has few objectives. An intuitive notion of fairness dictates that each builder should pay a fraction of 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. Finally, ideally, the fee should be at the expense of the payment to validators rather than at the expense of builders’ profits.

To achieve these objectives, we propose that builders connected to MEV blocker pay a per-block won fee that is recomputed every period (for example, every week). 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 equal to 20% of

M_{t-1} = (Total MEV blocker tx value during period t-1 - Value of MEV blocker tx also in the mempool during period t-1) / # of blocks mined by builders receiving MEV blocker transactions

That is, the average value per block of MEV blocker transactions during the previous period.

The proposed solution is unlikely to create distortions as the fee is based on the past. 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 period delay the average value of MEV transactions they received during the previous week.

Finally, with respect to 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. In 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.

We hope that most builders will connect 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 benefit builders overall, even if only one or a few builders connect (and end up paying the fee out of their profits).

[Yakitori]

Hi @AndreaC, it’s very good news that a fee mechanism is set to be launched, with a common agreement of all of the parties!

I have three questions:

• If a week had a lot of valuable transactions, is there a chance that the subsequent blocks go ignored by the builders, due to the fee being higher than the underlying value? This would create some deadweight loss overall.

• Where are the fees going to be directed? I know it’s a different subject, but it may be worth discussing, especially after our recent debate around liquidity.

• Do we have an estimation of the fees collected this way, using past blocks? If not, and if you have data available, I’d be willing to help with the analysis.

Anyway, congratulations, and Moooo !

[AndreaC]

Hi @Yakitori, thanks for the encouragement and the questions!

WRT the first one: it is theoretically possible but, we think, very, very, very unlikely. The majority of the value of winning a block is MEV (for example, payments from arb bots) and is orders of magnitudes larger than the value of MEV blocker transactions. According to this dashboard, MEV payments are more than USD 2M daily, while according to this dune dashboard the value of MEV blocker transactions is between 10 and 20 ETH per day. So you would really need a period in which the value of MEV blocker transaction spikes to more than 100 times its usual value for then returning to its baseline value for running into the problem you are describing. BTW, note that this just shows that, for builders, the value of being connected to MEV blocker is primarily the increase in the probability of winning the value coming from other sources.

Wrt to the second point: this is under discussion and will be explained in the CIP when ready, but the general orientation is to use these resources to cover the costs of running MEV blocker and also push for its expansion.

Wrt the last point: we’ll provide a more detailed estimate in the CIP, but if the daily value of MEV blocker transaction is 10 to 20 ETH, the fee will collect approximately 3 ETH per day.

[tanglin]

Good morning @AndreaC, how is the CIP coming together? Curious to check out the details

[AndreaC]

Hi @tanglin , great timing! The CIP proposal to introduce a MEV blocker fee was posted a few minutes ago: CIP-Draft: MEV Blocker fees