This post explores the new builder gas fee refunds mechanism we have implemented from a searchers perspective. The idea is to get the core ideas of the mechanism across and to elicit feedback for potential future features.
The current PBS market structure MEV-Boost broadly sees searchers compete in a “first-price”, sealed-bid auction while builders compete in an ~open outcry auction (where bids are public and bidders have time to respond to other bids) downstream of that. This structure allows builders to make faster and more informed bidding decisions in the block-auction than searchers do in the bundle-auction. Consequently, we have seen several searchers leverage the builder’s position in the market to gain a leg up over their competitors. Some searchers have done this by running their own builders (consistently or when needed) while others have managed to outsource their bidding via “refund deals” with a partner builder. In either case, this entanglement can be thought of as the searcher bundle paying a large amount forward to the partner builder (establishing an upper bound willingness-to-pay), the builder trying to optimise bidding to get the searcher on chain for as little as possible, and then refunding the searcher so that their net payment approximates the minimum required payment.
In order to successfully launch a decentralised block builder into the market, we must find a way to provide a programmatic, permissionless way of offering order flow originators similar functionality and allowing searchers to focus on their strategies without having to stand up infrastructure like block builders. The refund rule is how we are doing this.
The Refund Flow
The idea is simple. Searchers send bundles uniquely to the refund builder. If an estimation system detects that there is a reasonable chance that the refund builder will not win the block, the bundles are multiplexed to other builders in a way that is specified by the bundle. This multiplexing is done to maximise chances of inclusion.[1] When bundles are multiplexed refunds are unlikely since the refund builder probably won’t win and if it does, it will be with stiff competition.
If the refund builder is in a position to win and the multiplex mechanism is not triggered, the refund builder competes and likely wins the block auction. The builder profit is paid back to searchers proportional to the value they contributed to the block - i.e. the difference in block value the refund builder could build with and without their flow.
This mechanism also comes with a refunds API and **dashboard** which allows searchers to see details about the rule including the contribution of each landed bundle. This should be useful to inform bidding.
Here is a more precise explanation of the refund rule.
B(T) is the the most profitable block produced from bundles in T.
v(T) is the value of B(T)
b_i(T) is the payment of all bundles sent by identity i if block B(T) is realized.
\mu_i(T) = \min\{b_i(T),v(T)-v(T\setminus i)\} is the marginal contribution of all bundles sent by identity i if B(T) is realized. We bound the marginal contribution so that the net payment can’t be negative.
c is the amount the builder pays to the proposer to win the block.
\phi_i is the refund to i where,
So the net payment per identity (assuming it’s included) is p_i(T) = b_i(T)-\phi_i(T,c)
For a full description, see the docs.
Simplified example: The refund builder receives two mutually exclusive arbs at 5 & 6 ETH and two mutually exclusive liquidations at 1 & 4 ETH. Assuming no interaction between the arb and the liquidation, the total block value is 4 + 6 = 10, the biggest arb contributes 5 - 6 = 1 ETH and the biggest liquidation bundle contributes 4 - 1 = 3 ETH. If in the block auction, the builder has to pay c = 6 or less, everyone is refunded their full contribution. If the builder pays c = 8, everyone is refunded half their contribution.
Why this rule?
You can think of this rule as interpolating between a “first” and second price auction. If the builder makes enough revenue, then simply bidding your true value is a pretty good strategy since the builder will charge you only the minimum amount you had to bid to beat out competition.
The rule has the nice property that, although you may not always want to bid your true value, you are never incentivised to inflate your bid to be greater than how much you value the opportunity. Overstating your value would only help you to win in cases in which your net payment is greater than the value of the opportunity - i.e. you incur a loss. Other refund rules we considered don’t have the same property and may counterproductively make bidding more, not less complex.
Who should participate in this rule?
If you are regularly leaving money on the table because you are bidding more than your competitor or you are often missing opportunities because you tried to optimise your bids too much, then this is for you. If you are very good at estimating the bids of your competitors and seldom overbid then the refunded amounts will accumulate more slowly. Across the board, the rule should reduce the impact of having optimised bidding logic, freeing you to spend more time on core functionality.
“You aren’t discriminating unique flow”
It is true that the refund rule cannot distinguish between a bundle sent only to the refund builder and one that is sent to many builders and therefore cannot attribute more value to unique flow. However, the incentives of the system are set up so that bundle originators are incentivised to send bundles uniquely to the refund builder instead of multiplexing themselves to other builders. This incentive grows as the contribution grows.
This can be seen by considering two points:
-
The incentive for sending your flow to multiple builders is low as long as the smart multiplexing mechanism performs well. Our most recent tests have put error (i.e. we didn’t multiplex but we should have) at ~1%.
-
Especially if your flow has high contribution value (i.e. you can take a big margin over your competitors), you are incentivized to send uniquely to the refund builder as this both increases the % of your refund that you will receive and the likelihood of receiving this refund (since the refund builder is more likely to win).
- An example: block 20843717
In this block, transaction 0x7b pays 38 ETH to one of the Flashbots builders. Flashbots is the only builder with access to this opportunity so the FB builder wins the block and takes a large block profit. According to the refund rule this bundle should get a 34 ETH refund.[2]
If the bundle was accessible to all builders, the refund builder would not be able to take this margin. Even if the Flashbots builder won in this case, the refund would be negligible in comparison.
“Truthful bidding is going to kill my margins by escalating bids”
Some searchers express concern that a refund rule will shift bidding dynamics unfavourably against them, sending more value to the proposer. The particular scenario would be one in which two searchers are competing for the same opportunity in today’s first price auction. Both searchers know that although they could raise their bids and win with higher probability, this would only trigger a response, escalating bids and compressing margins. Hence, both parties resist the short term incentive in order to preserve long-term margins. The concern is that a 2nd-price-like bidding rule would push people to bidding their true value, instantly killing margins for common-value opportunities.
While its always hard to predict markets, this doesn’t strike us as necessarily the case. Just like under the status quo, searchers in this position can shade their bids to preserve long term margins, even if bidding higher is the rational thing to do in a single-shot analysis.
Potential Improvements
These are some potential upgrades in the future about which we are gauging interest.
First Price Bundles
Right now, searchers can express which builders they want their bundles to be multiplexed to if the multiplex mechanism is triggered. We could make this more expressive by allowing searchers to define different bundles for the multiplexing case. This would allow for a refinement of bids: one bundle is a bid for a ~2nd price refund scenario, and the other multiplex bundle is for the first price scenario. In such a case, after multiplexing, the refund builder would only build blocks with 1st price bundles.
In this case, a reasonable starting bidding strategy would be to keep first price bids the same and then for refund bundles you can:
- take x as what you would bid in a first price auction
- take y as either your true value or the value at which you are very confident your bid will win, whichever is lower.
- bid x + a(y-x) where a is the expected refund percentage
Adjusting Multiplexing Aggressiveness
If it would make it easier to bid, the multiplexing mechanism could be made more or less conservative such that multiplexing is only triggered if the estimated block profit margin exceeds X%.
What do you think of this? What is not clear? What are your concerns? Which upgrades are appealing? Do you have other improvements to suggest?
Currently, this mechanism doesn’t multiplex when the refund builder ends up not building the block only ~1% of the time, which is a pretty good error rate. ↩︎
Unfortunately for this bundle, in a niche case it was actually sent through the mempool, disqualifying it for refunds. The math still serves to illustrate our example though. ↩︎