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.