# Exploring Relay payouts with Parallel Block Auctions

In the Ethereum Ecosystem, PBS is currently achieved using MEV relays. Block builders construct entire blocks and send them to MEV relays. Here, a one-to-one mapping exists between a builder and the block, i.e., a block built only by one builder.

In parallel block building, multiple builders build a single block. The builders building the blocks are ideally unaware of the transactions contributed by the other builders. Parallel block building improves the decentralization and censorship resistance of the builder market, where multiple builders can participate in building a block.

Blocks are built for every slot and are sent to the MEV relay. The MEV relay sends the highest value block to the proposers. The value of a block is determined by the payout tx included at the end of the block. This payout tx is a simple ETH transfer from the builder's coinbase address to the proposer fee recipient address. The ETH paid out is usually a portion of the MEV and priority fees, which the builder extracts from the transactions of the submitted block. The MEV and priority fees extracted by the block builders are usually the difference in the balance of the builder fee recipient before and after executing the transactions in the block. The builder can also choose to pay from their pocket to artificially increase the value of their block and improve the inclusion rate of their txs.

In out-of-protocol parallel block building, payouts become tricky. When multiple actors propose partial blocks to build a single block and are unaware of the transactions proposed by each other, the transactions not included at the top of the block can potentially revert due to the state changes because of the transactions that execute before them. These unexpected reversions can reduce the MEV and priority fees extracted by actors building the partial blocks.

The key idea is that we can truly know the real value(MEV + priority fees) extracted by a block only when we combine all the partial blocks into a full block and execute the full block. This means we will have to re-think validator payouts for parallel block building.

In this article, we discuss payouts in the context of parallel block auctions. Initially, we considered only one type of parallel block auction where the top-of-block(ToB) and rest-of-block(RoB) are built separately in this discussion. In this type of parallel block auction, the top-of-block is made by a separate builder/searcher who includes a payout tx to the proposer to have their txs on the top. Similarly, a builder/searcher builds the RoB with txs they want to include in the rest of the block. This follows up with our work on [PEPC-Boost](https://hackmd.io/@bchain/BJkarrEWp).

At the end, we also discuss a potential payout mechanism for a system where we have a partial block auction with multiple actors.

## 1. Restrict the state on the top-of-block
We previously discussed that one of the main reasons why payouts in parallel block building become tricky is because of unexpected reversion of transactions due to transactions included by another actor. These unexpected reversions can reduce the expected MEV amount, which can invalidate the payouts submitted by each actor as there may not be enough ETH to payout post-tx reversion.

To avoid such a scenario, we can restrict the type of txs each actor can include in the partial block. Let us take the example of the parallel block auction, where the top-of-block and the rest-of-block are built separately. In this case, we could restrict the top-of-block to include only certain types of transactions. By limiting the type of txs we allow in the top-of-block, we can minimize the state conflicts with the rest-of-block, reducing the number of tx reversions.

For example, we could restrict the ToB to only certain CEX-DEX arb swaps like WETH/USDC, WBTC/USDC, etc.

Further, The builder who builds the RoB block can be aware of the kind of restrictions in the ToB and build their block aware of this.

The total value of the combined block is the sum of the value of the ToB bundle(the payout tx included by the searcher/builder) and partial RoB(the payout tx included by the searcher/builder).

Let us explore the Pros and Cons of this:

**Pros:**
1. The existing payout system remains the same, which makes the system easy to reason about technically and economically.
2. Does not increase any trust assumption on the relay.

**Cons:**
1. Restricting the ToB to specific types of txs is tricky as it can be easy to bypass these checks by wrapping the tx in a smart contract. We would have to rely on more expensive tracing to check if the ToB conforms to the restrictions placed on the top.
2. Restricting the ToB might get significantly more complicated with ERC-4337
3. It is not very scalable. We can start with restricting the ToB with certain CEX-DEX arb swaps, but it will make a decent effort to scale it up to more swaps or different types of txs.
4. It may be more challenging for RoB builders to exclude certain types of TXs as it may take much computation to filter out TXs based on their contents. Even with best-effort filtering, there might be some reversions in the RoB.

## 2. Allow builders to quote relative payout values

As discussed previously, we only get to know the actual amount of MEV extracted in a block built by multiple actors when executing the combined block. The exact payable amount can be determined when the block is assembled with the txs from all actors.

If we take the case of the ToB and RoB parallel block building, the amount of ETH the RoB can pay can only be determined when the ToB bundle and RoB block are combined. Note that the payout of the ToB remains unaffected since the ToB faces no reversion issues.

How do we determine the payout amount for the RoB builder, given that we first need to combine the ToB and RoB relay to extract the actual value of the block?

One way we can approach this is to allow the builder to signal a relative value of the MEV they gain. For example, the RoB builder can pass in a % percentage of MEV extracted that they want for themselves in the [BidTrace](https://github.com/attestantio/go-builder-client/blob/master/api/v1/bidtrace.go#L20) structure along with an EOA where they would like to receive the MEV rewards. The remaining MEV rewards go to the proposer.

When assembling the ToB bundle with the RoB block, the relay must set its address as the fee recipient. The MEV extracted from the txs will go to the fee recipient address. The relay is responsible for computing the percentage of the MEV rewards, which will go to the builder. The MEV rewards for the proposer will be the remaining rewards post-builder payment. The relayer is responsible for appending two ETH transfer txs, which transfer MEV rewards from the relay fee recipient to a builder EOA and the proposer fee recipient.


**Pros:**
1. There is no need to worry about reversions because the RoB payout will always be determined by the relayer, who will know the correct MEV value after combining the block, which makes this solution more accurate. With this mechanism, we could also restrict the type of txs that can be placed on the ToB. It is compatible with this mechanism.

**Cons:**
1. Increases trust assumptions on the relay. The builder will have to trust the relay to pay them their actual extracted MEV, which is a significant trust assumption. We could also reason that it doesn't increase any trust assumption since relays already have access to the tx of the builder's block.
2. Adds more latency to the system since we need to assemble the block to determine the final payout.
3. Technically more complicated to implement.

# Payouts when multiple actors build a block

We can build on the relative payout method to discuss payouts in parallel block auctions where multiple actors create different partial blocks of a block. E.g., three builders build parts of a block in parallel. This article will not cover how the particular partial blocks could be selected to construct a full block. E.g., in decreasing order of the value they provide, i.e. the partial block that generates the highest value can be included at the top, the 2nd highest can be included subsequently and so forth. Another way could be to select the partial blocks to increase censorship resistance randomly but at the cost of potentially producing blocks with low values. These are discussions for a separate article.

In these types of partial block auctions where multiple actors are building a block, we again know the actual value of the block only after combining all the partial blocks into a full block. How do we determine each builder/searcher's payout and the validator's payout in such a situation?

When assembling the block, we can know the actual value generated by each partial block. This is considering the state reversions based on the previous partial blocks. We can apply the relative payout method discussed above to each partial block.

When a builder/searcher sends a bid for a partial block to the relay, they include a percentage of the value(MEV + priority fees) of their partial block, which they want for themselves and the remaining to go to the validator. They also include the address where they wish to receive the rewards.

When we assemble the block, we can compute each partial block's actual value(MEV + priority fees). The relayer can compute the percentage paid for the builder/searcher and the validator based on the percentage quoted by the builder/searcher in their bid. The relay can append the payout txs at the end of the block. We can perform this step for each partial block.

In the end, we should have a block with the tx of each partial block and two payout tx for each partial block. One payout is to pay the builder the right amount, and another is to pay the validator.


The Pros and Cons are similar to the ones we have discussed for relative payouts for a block with a ToB RoB split.

# Conclusion

In partial block auctions, partial blocks outside of the top-of-block partial block face the risk of tx reversions because of state changes caused by the previous partial blocks, which requires us to re-think how we can design payouts in partial blocks. This article explored the design space of payouts in the context of out-of-protocol partial block auctions.