Feature request: winning bid endpoint

[thegostep]

With the current sealed bid auction, it can be difficult for searchers to determine what their bid should be for a given opportunity.

A potential way to improve this UX issue would be to provide a way for searchers to obtain the value of the winning bid and have the opportunity to respond to it.

This will significantly change the auction behavior and searcher bidding strategy therefore needs to be considered carefully.

[abog854]

With bundle merging, they wouldn't be any single winning opportunity, so that seems hard to do in practice. How do you see that work?
FWIW bundle merging seems like a much more important feature to me.

[wjmelements]

It would return an array, the best merged bundles

[sequence-dev-1]

As a searcher I honestly prefer the sealed bid auction.

[sequence-dev-1]

Sealed bid equilibrium is 0-profit for any competitive context.

I fail to see how this is the case in practice. But I do see how having a privileged middle man running the relay is a problem.

[wjmelements]

https://etherscan.io/tx/0x8b3e494b437bd9cdd20b08926ae88ce10664417c2559d8d428ba5f12d70916de

[thegostep]

I tend to agree with @sequence-dev-1, giving access to the winning bid would reduce the amount of trust searcher place in the relay, but would likely generate bidding wars which accelerate the path to 0 profit for searchers

[wjmelements]

Bidding wars also happen in the "closed" paradigm.

[thegostep]

But across multiple blocks instead of a single one

[gwei-god]

My two cents as a searcher - I prefer the sealed bid auction. An open auction will turn into what the mempool previously was - a race to zero margins [albeit with no expensive txn failure cost now].

Opening the auction benefits miners, but hurts searchers, who are already in a dis-advantaged position.

[jasalper]

That was an example to show how first price and sealed bid auctions have different behaviors in certain conditions. I’m not claiming to know the exact conditions of Flashbots bundle submissions, but my point that the results are not equal in non-perfect competition environment still holds. And Flashbots is most certainly not perfectly competitive.

You need to check your “perfect competition” assumption.

[wjmelements]

Your economic expertise swoons me. I will switch to uniform-random bidding immediately.

[jasalper]

You didn’t even try to understand my point. The uniform distribution bundle profit example was an example to show how sealed bid and open bid auctions can have different results in the absence of perfect competition. The example holds for other non uniform distributions, although the optimal NE bid stops being 1/2 of the profit generated.

The burden of proof is on you to show that your assumption of “perfect competition” holds in flashbots if you want to claim that searchers will maintain the same profit.

[wjmelements]

https://etherscan.io/tx/0x8b3e494b437bd9cdd20b08926ae88ce10664417c2559d8d428ba5f12d70916de

[jasalper]

Whats your point? One transaction where the bid is almost as high as the profit proves what? What makes you think this would be any better if the top bid were public? Do you know what the second bid was?

There are transactions where the searcher keeps the majority of the profit. If I link those does that suddenly prove my point?

[wjmelements]

Without knowing the best competing bundle, we are all overpaying.

[gwei-god]

A second price auction makes a ton of sense to me [instead of exposure of the first price]. Simply seeing the second-highest coinbase payment, and no other details of the bundles involved, etc. seems like a nice addition, and will greatly reduce overpayment.

[wjmelements]

The open auction is second-price. The closed auction is first-price.

[gwei-god]

The open auction is second-price. The closed auction is first-price.

Great, that's how I understood it. This would have my support.

[jasalper]

I would only be in support of this if the second price is rounded or somehow anonymized. Otherwise its very easy to implement a check "if second price == own price: bid higher".

[jasalper]

Even so, I fundamentally like the dynamic of no rebids. (I know you can re-bid now, but you don't have any more information as to other's bids when you do).

[jasalper]

(I'm talking from the perspective of a searcher -- miners already get bribes and will eventually get more and more of them as competition increases)

I see a confused react under my rounded/anonymization comment so I'll explain what I mean --

The winning bid endpoint is useful because it tells you if you're overpaying, or if your mev tx is not competitive in the current block and should just be submitted to the txpool. At the same time, its a pain in the ass because it allows and encourages auctions, which leads to bribe increases as searchers outbid each other.

Is there a way to get the first benefit without exposing ourselves to bidding wars? i.e. is it possible to tell searchers what a "fair" bid is, without telling searchers whether their bid is the top bid?

My (possibly incorrect) guess is that the best way to do this is by introducing some noise into the system. A searcher won't know what the required bid is to win the auction, but they'll know more or less what the current bundles are going for to prevent bidding 95% of the profit when its not needed. At the same time, because the winning bid is noisy, two searchers with similar bids will have no way of knowing whether they are ahead or not. So if they each have a ~50% chance of winning the bid, the EV of keeping their current bid and winning half of the time will hopefully be larger than entering a bidding war.

What type of noise and how to implement this is still TBD, but happy to think and talk about it more.

[pyggie]

This seems vulnerable to sybil attack. If I have a 50% chance against a single competitor when I submit one bundle, I'll have a 2/3 chance if I submit two at the same price, and if there isn't a cost to bidding then I'll submit a hundred. You could add a bidding fee, but the fee would have to be pretty significant, as in the case of your and your competitor both having submitted K bids, your EV for adding a K+1th bid is ~ MEV / (2 K). And since different MEV opportunities cover a wide range of values, it would be hard to set the fee.

If we could solve the sybil issue, an alternative to noise could be:

• coarsely quantized bid amounts (e.g., 10% bins in log space)
• randomly choose a winner from all equal highest bids

[jasalper]

I don't mean the bid price is noisy -- just the queried value from the endpoint is. The true value is known, and the higher bid wins (so the sybil attack wouldn't do much).

The quantized bid amounts + randomly choosing a winner among those might be a tough sell to miners, but I'm not sure.