As outlined in the original MEV-boost architecture proposal, builders construct execution payloads that contain transactions and header parameters provided by validators. Builders may directly set the validator’s feeRecipient address as the coinbase address of the payload, which transfers all gas fees and reward payments directly to the block proposer, or builders may set their own address and include a transaction to the block proposer’s feeRecipient address at the end of the block. While this design has not changed since the initial spec of MEV-boost, builders had not implemented this feature and an industry standard has yet to be defined.
In this article, we outline our preferred solution for builders to make payments to proposers, and provide a release update for payments in the Flashbots reference boost-geth-builder for further testing.
In the Identifier for builder to proposer transaction #220 issue, staking providers and node operators outlined a need for an accounting mechanism for MEV payments. This mechanism unlocks a number of necessary operations, such as proving receipt of MEV rewards, fair distribution of rewards to staking customers, and preventing malicious activities, such as MEV hiding, among others.
To enable these operations, Flashbots proposes a standardized specification for how payments are made from builders to block proposers through the following process:
feeRecipient of the payload header they are constructing.feeRecipient **address at the end of their proposed block.Withdrawals
Validators need to be able to withdraw from the account which receives payment. If payments are made directly to a validator’s recipient account, then the validator would be unable to withdraw anything from that account without adversely affecting the simulated value of that block. The reason is that if the profit of a block is measured by the difference in a validator’s recipient account before and after that block, then a withdraw makes the block look less profitable because it removes assets. To prevent this, validators would need to create a new recipient account for each block they produce.
Out of band bribes
Additional payment methods using transfers to the validator account, or transfers to the validator on L2s, for example, would allow for validator bribery. Further research and input is needed to address this externality.
Gas usage
Adding a transaction that calls a smart contract costs additional gas, and becomes an overhead expense on every block.
We are actively seeking input from node operators and the broader community on implications of this proposed design. We are prepared to move forward with this implementation and continue to iterate as community input is received. Please provide comments, feedback, or suggest alternatives directly on this forum thread: https://collective.flashbots.net/t/block-scoring-for-mev-boost-relays/202/5