# Bid cancellation in ePBS. There are two topics that often come up when discussing ePBS. Those are bypassability and bid cancellation. Both come up often together perhaps since https://ethresear.ch/t/relays-in-a-post-epbs-world/16278 which advanced the point that relays offer a service to builders and that builders may want to continue using these services even after enshrinement of PBS. So *bid cancellation* is one of these services and *bypassability* is the outcome of builders (and proposers) opting to not use the protocol. I think the whole line of thought is clearly flawed, but today, in just a few lines, I'll restrict to simply talking about bid cancellation, and how it does not even makes sense in an ePBS world. ## What are bid cancellations after all? So why do builders want to cancel bids? to understand that we need to understand how is the mechanism by which blocks in Ethereum are "chosen". Proposers do not contact directly the builders to ask for their best block. Proposers simply request the relay, at their time of convenience: "Hey, please give me the best bid you have right now for me". Builders on the other hand, have no way of knowing when this call from the proposer will be, so they continuously update their blocks, and submit new bids over time. This auction can take several seconds. The relay keeps tracks of bids that has received from all builders and serves the best *last* bid to the proposer when requested. But as the proposer takes its time to request the payload from the relay, price variations may turn what seemed like a profitable arbitrage, into a loosing one. A builder that had bid accordingly, and sent this bid to the relay, will rush to cancel their last bid, update their block, remove the bad arbitrage and submit a new bid. This is what is known as *bid cancellation*. Notice something from all the discussion above? :::info There is no canceling once the bid has been served to the proposer. ::: Indeed, the cancellation is only of bids that have not been actually requested, they aren't in the hands of the proposer, they are just in the hands of the trusted relay. If the cancellation comes after the relay has served the bid, the proposer will not care about this, they will sign the block with the bid they have already received and they will serve that block back to the relay. The relay is trusted to broadcast and reveal the corresponding payload, no matter if the builder had submitted a late cancellation. Now this whole mechanism is there because of the push nature of the auction. The relay is not requesting bids from builders, the builders are constantly updating their last bid by *pushing* them into the relay. What you need to imagine is the following two scenarios: What would happen if the builder magically knew when exactly the proposer will ask for the header? If instead of pushing bids into the relay the communication went the other way: the relay requests the bids from the builders when it needs it and serves it back to the proposer, what would happen in this case? Both cases lead to the same outcome: the builder will simply not send useless bids to the relay, they will wait for the appropriate time and send their bids accordingly either before the proposer requests or when they are asked by the relay. ## How does it change on ePBS? In no way at all! just as above, in the exact same way: :::info There is no canceling once the bid has been served to the proposer ::: And guess what, the builder knows exactly when the proposer will ask for a bid, **because the proposer directly requests it**. So the scenario is exactly as in the pull case for the relay above, without of course the extra unnecessary roundtrip to the trusted relay. How is the builder's dynamic? **exactly the same as with the relay** they build their block, they keep an amount they are willing to bid for it, if suddenly their trades become bad, they don't need to bother, they haven't served anything to the proposer, so there is no point in canceling, just change the block, drop the bad arb and adjust the bid down. ## FAQ ### But bids over P2P can't be canceled Sure, but really? who cares about those? ### And if the proposer asks multiple times? That's the same as today, the proposer can ask multiple times the relay, if the relay decides to give two different headers, neither can be canceled, the proposer can sign either of them. The relay can decide not to serve twice. Same in ePBS. If the proposer asks twice, the builder may decide not to serve a second time. ### Can we prevent the builder from being tricked into serving a bid? Yes, bids can be signed by the proposer. ## Bids over P2P ### Why do we care about them? Now that I've exceeded myself more than what I wanted to write on the subject. Let's consider the case of bids over P2P. We don't even need them in fact. Validators can simply self build for liveness. So what do those bids achieve? well, they set a minimum bid, builders are centralized actors, and they only need to outbid themselves, this can quickly devolve into a cartel. By having bids over P2P we allow **any validator in the network** to set the floor price for the auction. ### Who will really use them? There are different actors that may want to use bids over P2P. - Home stakers that care about censor resistance and decentralization. They don't care about making their EL work a little more and may want to submit bids every block to at least set the floor. These stakers don't care about arbitrage so they don't care about bid cancellation, they aren't even including their own transactions. - Application writers that want to internalize MEV however they want. Do you have your own front end for some APP? are you running an NFT mint and you are the only one holding the transactions? well, you don't need to set up the infra to become a big builder with an HTTP endpoint nor do you need to deal with intermediary trusted players nor other builders, just build your block accordingly and submit your bid over P2P. Same as above, these app runners don't care about bid cancellation, they are the only ones holding the transactions minting the NFT. ## Caveats: timing games Of course the picture above is just part of it, proposers request headers later to get better bids. The relay does not really reply immediately and they wait the maximum they can before returning to try to get a better bid, etc... On ePBS these games may actually get worse on some aspects and better in others. Proposers are still enticed to request late, but now they don't have much time and validators **actively count every vote for the parent towards reorging late blocks**. The new timing game in town: builders delaying their block reveals. That one is still too early to judge how it will affect the dynamics of block validation.