builder-escrow-proposer separation === **TLDR**: We suggest a form of builder-proposer separation where block builders and block proposers are intermediated by a permissionless market of semi-trusted "block escrows". The goal is to enable builders and proposers to coordinate the on-chain inclusion of MEV-rich blocks without a) consensus-level support, or b) builders trusting proposers via whitelists. (Whitelisting does not scale to the thousands of beacon chain proposers and is open to opportunistic abuse by small stakers.) **construction** During a slot with proposer `P` an honest block escrow: * listens for blocks from builders (possibly built from searcher bundles) * selects the block `B` which maximises the reward `R` for the proposer `P` * sends to the proposer `P`: * the header `H` of block `B` * a signed Merkle path for the post-execution balance of proposer `P` * broadcasts `B` if and when `H` is returned signed by the proposer `P` **notes** * The reward `R` is composed of ETH tips plus transfers to the coinbase address. * If the block `B` is valid the Merkle path proves the reward `R`. If the block `B` is invalid the signed Merkle path can serve as a fraud proof or a block withholding proof. * Proposers can listen to several escrows and select the header with the largest reward. * Builders trust escrows to not leak MEV and proposers trust escrows to not withhold block bodies. As such, proposers and builders must share a trusted escrow to collaborate. * In practice builders produce EVM execution payloads, not beacon blocks. Escrows send execution payload roots to proposers which return signed beacon blocks minus the execution payloads. * For the purpose of DoS-protection escrows can whitelist builders and accept only one block per builder. **benefits** * **consensus minimalism**—The scheme requires no consensus-level support. This makes it compatible with a fast minimum viable merge. It also allows for builder-proposer infrastructure to be developed and tested on the mainnet PoW chain (pre-merge). * **trustless proposers**—The scheme does not require builders (or escrows) to trust proposers. Proposers cannot steal MEV or withhold block bodies. * **MEV democratisation**—Every proposer has the opportunity to financially benefit from MEV-rich blocks. This contrasts Flashbots whitelisting which would favour pools over solo staking. * **open escrow market**—The escrow market is open and permissionless to mitigate liveness and censorship concerns a central coordinator such as Flashbots may introduce. The openness allows individual and companies with existing reputation (e.g. Etherscan, Infura, Metamask, Ledger, etc.) to help decentralise the block market. * **technically simple escrows**—Escrows are technically simple: they receive and relay small messages (block bodies and headers) and execute blocks. Escrows do not need to search for MEV or handle validator private keys. * **proposer DoS protection**—Proposers receive at most one block header per escrow they trust. In particular, proposers do not download or execute blocks, and cannot be flooded by block headers. * **medium-term stepping stone**—The design shares aspects of the long-term [enshrined proposer-builder separation](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) and can serve as a medium-term technical stepping stone. * Proposers can easily find escrows they can trust -- the only thing they need to verify is that most of their blocks have been published, since not publishing the execution payload is the only way in which an escrow can harm a proposer. Proposers can even automatically blacklist an escrow if a few of their blocks weren't published, which means the system can react very quickly when an escrow tries to abuse their position. **downsides** * **manual escrow selection**—Validators have to manually select a set of escrows they trust and clients have to provide infrastructure to select such escrows. (A misbehaving escrow, i.e. one that withholds or lies about the validity of a block, can be automatically blacklisted by the proposer.) * **policing of MEV theft**—Similar to the Flashbots status quo where searchers have to police potential MEV theft from Flashbots, builders have to police for and blacklist malicious escrows stealing their MEV. * **proposer-escrow channels**—The communication channels between proposers and escrows is additional networking infrastructure clients have to support.