Discussion about proposer authorizations (`SignedRequestAuth`)

[JasonVranek]

The modified Builder API spec for ePBS introduces SignedRequestAuth, a per-builder BLS signature the proposer must generate for each GET /execution_payload_bid request. The spec justifies this on two grounds: DoS protection and bid privacy. We argue that neither justification holds, and the mechanism creates a distinct technical problem for sidecars. We've written a full analysis here; this issue summarizes the core points. We'd like to open discussion about removing proposer authorizations from the modified Builder API entirely. (related to this discussion)

DoS protection
Builder URLs will be public. Builders operating RPC endpoints will receive unsolicited traffic regardless of authentication. Adding BLS signature verification to every bid request doesn't meaningfully close that surface, and introduces non-trivial computation on the critical path. Standard infrastructure-level mitigations (rate limiting, IP filtering, connection management) are sufficient and don't require cryptographic authentication. Since RPC builders are expected to be sophisticated anyways, they should have this DoS mitigation in place.

Bid privacy enshrines a first-price sealed bid auction
By preventing builders from seeing each other's bids, proposer authorizations enforce sealed bidding at the protocol level, even though the ePBS spec never prescribes an auction format. In a sealed-bid auction, new builders cannot observe competitor bids, making the subsidy strategies they rely on for market entry harder to execute. Meanwhile existing builders continue to have structural advantages that sealed bidding does not eliminate. While the status quo of open bidding also doesn't solve these structural problems, it does keep the door open for newer or smaller builders to participate.

Sidecar compatibility
SignedRequestAuth must be generated with the proposer's validator keys, which live in the validator client. Even though it makes sense to enshrine sidecar functionality, it is very likely users will still want optional sidecars. Optional sidecar usage then relies on access to validator keys, which is a security risk that doesn't exist today with MEV-Boost. We explored workarounds for this, but it feels like treating a symptom rather than the root cause and is more development work and complexity.

Summary
Removing proposer authorizations leaves the spec flexible. If the market later decides it wants sealed-bid mechanics, sidecars can implement authorization headers independently, coordinating with builders who agree to enforce them without a spec change.

Full writeup: https://hackmd.io/0TBOKInYTw6axHBaORwUZg

[realbigsean]

+1 to remove proposer authorizations. I don't see the benefit, and I don't think the spec should be opinionated about auction structure, that seems to be the only tangible impact of proposer auths (other than adding signature overhead).

[potuz]

1.Removing this authorization indeed makes our life easier. However
2. It is NOT being opinionated about the auction, the signature per builder is so that the builder knows that this request is to that particular builder and is actually coming from the proposer. This is not about DOS but rather about obtaining information for free. Without this, anyone can get what the status of the bid from the builder is.
3. This does not add any latency to the hot path as mandatory: a builder that does not want to check the signature simply doesn't need to check it, returning to the status that this feature would provide. On the other hand, signing does not need to be on the hot path since these request can be presigned.

So what I challenge is the two points laid out in the linked comment as the motivation for this feature, it's not about being outbid nor about preventing DOS, it is about giving the option to the builder to know that the request is actually from the proposer. Builders can ignore this if they don't want to use this feature.

NOT adding this feature would be actually opinionated about the auction structure as it removes an option for builders, which again, is just optional.

[tbenr]

+1 to remove proposer authorizations. I don't see the benefit, and I don't think the spec should be opinionated about auction structure, that seems to be the only tangible impact of proposer auths (other than adding signature overhead).

After thinking\reading about the topic I believe that removing the SignedRequestAuth IS an opinionated move.

With a bit of AI this is what i believe:

1. Removing it forces a Public Auction: If anyone can poll APIs to scrape bids, the market flattens into a pure "latency war". Top-tier builders with massive infrastructure can simply copy smaller builders' bids and outbid them by 1 wei at the last millisecond, centralizing the market.

2. Keeping it enables Sealed-Bid Auctions: Builders can verify the legitimate proposer and hide their bids from competitors, protecting their margins and algorithmic IP.

Proposed Solution

We can fix this by adjusting the spec to state that a builder MAY validate SignedRequestAuth based on their preference.

This opens the door to a healthier, heterogeneous market:

• Small/Mid Builders will likely strictly validate signatures to protect themselves from latency games (sealed-bid).
• Top-tier Builders might choose not to validate, keeping their bids public as a signaling/intimidation tactic (open auction).

Since both open and sealed auctions have pros and cons, letting builders choose their economic armor creates a much richer dynamic than forcing everyone into a latency-dominated public auction.

[JasonVranek]

Thanks for the feedback! I have some pushbacks, a big todo, and some questions.

This is not about DOS but rather about obtaining information for free.

Can't builders filter out other builders using known things like IP filtering? Since this is RPC and not p2p bidding we expect a level of sophistication.

This does not add any latency to the hot path as mandatory: a builder that does not want to check the signature simply doesn't need to check it

This is fair, then I guess it's worth talking to the Builders about what they'll probably do (this is a big TODO).

Top-tier builders with massive infrastructure can simply copy smaller builders' bids and outbid them by 1 wei at the last millisecond, centralizing the market.

I’m not sure it would be so straightforward. There's nothing preventing the proposer from requesting multiple bids from the same builder right? So Builders have no idea what bids other builders actually sent to the proposer nor do they know when the proposer has concluded their self-hosted auction. I think if bids are pushed to relays like they are today this is more of an issue but not when the proposer pulls them. Also, I think a lot of the old latency argument was around builder-relay colocation, but builder-proposer colocation is a lot less reasonable (or maybe an advantage for smaller builders that locate in less common geographies could have latency advantages for a subset of proposers).

Builders can verify the legitimate proposer and hide their bids from competitors, protecting their margins and algorithmic IP.

I don’t understand the algorithmic IP part but the argument is that hiding bids from competitors helps the bigger builders since they can truthfully bid higher due to compounding advantages. If a smaller builder can see others’ bids they can subsidize their bids to win which is a market entry vehicle.

We can fix this by adjusting the spec to state that a builder MAY validate SignedRequestAuth based on their preference.

I think this is a happy middleground. A question I’ve had though is isn’t the proposer incentivized to leak all bids they receive to force builders to outbid each other, regardless of the builder’s privacy preference?

[dataalways]

It's worth noting that the PBS market has moved away from header requests because they're extremely inefficient; with some relays going as far as to filter by IP and reject requests from builders. If an open auction remains post-ePBS, it will likely be run via bid streams not headers.

The effect of removing auth is that it will force all builders to implement IP filtering--because it makes sense to handle single requests from the proposer differently than thousands from builders. afaiu, filtering is trivial today because relays match the IP to the latest registration, but if the registration system is changing this could incentivize games.

[bharath-123]

The effect of removing auth is that it will force all builders to implement IP filtering--because it makes sense to handle single requests from the proposer differently than thousands from builders. afaiu, filtering is trivial today because relays match the IP to the latest registration, but if the registration system is changing this could incentivize games.

I am yet to completely spec this out. But in the new builder-api, we can rely on ProposerPreferences to gain information on the proposer's fee recipient, gas limit etc.
We would still want to communicate the preference of the max_trusted_bid to the builder via a registration like construct. I think proposers can send that to builders based on the proposer lookahead i.e send it if they will propose in the upcoming slot.

[mostlyblocks]

Do agree that proposer authorizations risk making the builder and landscape less competitive.

Let's say established builders have two types of edge, latency and exclusive flow.
Exclusive flow is much harder to bootstrap. An easy way of gaining a latency edge is just to increase coverage by locating in a rare geolocation.

Sealed bids risk exacerbating the edge exclusive flow gives.
New builders will have to subsidize more defensively to win blocks, while incurring higher variance as they naturally win less often.
For a new entrant, winning blocks will be more costly and more uncertain.

This is an opinionated change because it changes the way the auction is conducted. Once proposer authorizations are an option, builders will require them to keep their edge. The choice is illusory because nobody will unilaterally give up information.

Therefore, I agree that removing proposer authorizations for now is prudent.

[vladimir-ea]

"It is NOT being opinionated about the auction"

Disagree. If a single builder hides their bids then an open auction is no longer possible (a single builder observing all bids and hiding their own has an overwhelming advantage - this is evident isn't it?). The possibility of a single builder hiding their bids makes an open auction of builder blocks almost impossible.

[DigiDr]

+1 for the change.
While the auction structure may ultimately collapse to first-price sealed bids, i don't think the BuilderAPI should effectively pre-empt this outcome. It should be trivial for builders & relays to implement IP based filtering.

[quasarwin]

👍 to removing proposer authorizations. We are living through attempting to help decentralize the builder space. @JasonVranek explanation is spot on. The compounding advantages of exclusive flow are such a centralizing force that they need to be taken very seriously. At least 90% of order flow is gated behind OFAs etc that require minimum percent building as an entry vehicle to acquire flow. Think mevblocker, consensys (metamask), etc. So winning blocks with at best 10% of the value of the biggest builders means building < 1% of blocks, locking new builders out from the start. Price discovery is the only way smaller builders will be able to judge price and participate.

With a bit of AI this is what i believe:

Removing it forces a Public Auction: If anyone can poll APIs to scrape bids, the market flattens into a pure "latency war". Top-tier builders with massive infrastructure can simply copy smaller builders' bids and outbid them by 1 wei at the last millisecond, centralizing the market.

Keeping it enables Sealed-Bid Auctions: Builders can verify the legitimate proposer and hide their bids from competitors, protecting their margins and algorithmic IP.

This, unfortunately is why you need to be careful of AI hallucinations. I can tell you as someone working on this every day, not just speculating by asking an AI, the above is the opposite of how it works. I can outbid Titan by 1 wei, and do so on a regular basis, despite being smaller, but can only do that because it's an open auction.

[bharath-123]

Great discussions! It seems to me tho that builders will hide their bids either with auth or without(by IP filtering or so).

Regardless of whether we implement auth or not, it appears that builders will hide their bids one way or the other. So bid subsidization will become capital in-efficient regardless. Won't not having auth make the advantage more asymmetric across builders? I guess it depends on how hard it is to filter for bids.

I can imagine a bigger builder could snoop smaller builders who don't have a better filtering system.

[DigiDr]

Regardless of whether we implement auth or not, it appears that builders will hide their bids one way or the other

We don't know what will happen, and there have been many surprises in the evolution of the market since the merge. For example, proposers have a strong incentive to ensure that competition amongst builders remains healthy and this may play a part in dictating how builders behave.

Adding proposer auth later should be straightforward if a first price sealed bids structure dominates. But pre-empting this outcome now only makes the protocol less flexible and increases the risk that others might attempt to bypass it entirely if the incentives are to move in a direction we did not anticipate.

[potuz]

The proposer is sending a direct intended message to a single entity, it is not meant to be replayed. As with any other signed messages in the protocol, we want to protect of replaying etc. The only reason this message is not even encrypted to the BLS key of the intended builder is because of latency reasons. If the proposer wanted their messages to be replayed to other entities it could send it itself directly. This hits the middle ground in which the proposer at least makes sure that the counter-party can be certain that the message was sent to them if they don't want to ignore it. The entire field can be marked as optional. Removing it as this proposal wants is just an opinionated move towards preventing proposers from signaling their preference and preventing small unsophisticated builders from telling if the message was for them or not.