## Trustless Payments in Current ePBS Spec Discussion Summary

There seems to be lots of confusion regarding how trusted payments would work with the current epbs spec. Discussions took place on [Eth R&D discord](https://discord.com/channels/595666850260713488/745077610685661265/1423326524873900238) to try to get everyone on the same page. Alternative ideas of how trusted payments could work were highlighted, which are worth reading, but I want to focus this article on how the current spec already plays nicely with trusted payments as to keep things simple. I'm hoping this will help client teams during implementation and perhaps put some node operators at ease, so I will summarize some of the main take aways from the chat.

TLDR:
- epbs enables trustless payments but doesn't force them. With trustless payments, builders pay proposers via on chain mechanisms such as pending payments and withdrawals via staked builders.
- Trusted payments don't need to be enshrined into consensus. Off-protocol payments can be managed via client config and builder api spec updates as opposed to consensus spec changes like new consensus fields. This preserves optionality.
- No blind signing (mev-boost) as we know it. Under epbs, the builder unconditionally signs the payload commitment, not the validator. Off-protocol payments can still work, but without mev-boost style blind signing.
- It's important for builders to be staked as to be able to penalize misbehavior (i.e. exercising free option), but they can still pay the validator for their bid off-protocol.

## How Off Protocol Payments Without Mev-Boost Could Work
As mentioned, trusted payments don't require mev-boost or new consensus fields. Clients can let node operators whitelist particular builders and "boost" their bids in selection logic. Consensus doesn't tell the proposer how to rank bids. It just checks that the bid you did include is valid. Therefore, the client is free to use any local policy to pick a bid, including strategies that use a trusted off-protocol amount received from the builder api or alternatively to "boost" the in-protocol bid value received from the builder. Maximum optionality for bid selection is preserved as even more extravegent approaches can be imagined.

### Two Approaches For Selecting Bids from Trusted Builders (At Minimum)
1. Client Config
- Node operator runs vanilla client, and they could set a policy like "prefer a trusted bid if it beats all others by > X". This would effectively be achieved if the config set a multiplier for the bids received by the whitelisted builders, in the simplest case.
2. Builder Api
- The builder api response could include an optional field like `off_protocol_bid`, and node operator's could choose to prioritize these trusted bids in a configurable way.

In summary, the builder always signs, and the validator chooses amongst the trustless and trusted bids based off the node operator's config. If a trusted builder's bid is selected, the node operator expects to be paid off-protocol. Consensus just enforces the on-chain values and that rules from the [consensus specs](https://github.com/ethereum/consensus-specs/blob/4f743484b404c42988194a7160f2f532d69cc2d0/specs/gloas/builder.md) are followed.

### Examples From the Discussion
a. Node operator runs a vanilla client, and they whitelist a trusted builder and is willing to risk money getting bids from them without guaranteed payment. They accept a bid for 0 (1 Gwei, whatever) and publish a consensus block with a bid signed by the trusted builder. The operator gets the payment off-protocol. Clients should (but not necessarily are forced to nor need to be standardized) offer options to say "I prefer a trustless payment unless the trusted one offers me at least 1ETH", or whatever analog of all the mev boost flags that we have now, "boost", "min_bid", "min_diff", etc.

b. Node operator runs a client and want to trust an unstaked builder that is not a `0x03` validator on the spec. This operator cannot take payloads from this builder with vanilla client code and will have to fork the client.

c. If trusted routes fail or are blacklisted, ePBS’s trustless path remains: take a regular on-protocol bid from a staked builder and get paid via pending-payments/withdrawals. That’s exactly the “keep options open” argument for not removing trustless payments from the spec.