Updating Ethereum EL mev-boost rewards attribution methodology to capture additional payment patterns between Builders & Proposers

We recently found that there are two payment patterns between builders and proposers related to mev-boost blocks that we weren't tracking. The effect was that we ended up understating the execution layer rewards received by proposers. This affected ~23,000 blocks which represents ~0.6%% of all blocks since the Merge (September 15, 2022).

Pattern 1: Builder uses a different address to pay the proposer through an end-of-block transaction.

One of the main ways builders pay proposers when proposing mev-boost blocks is through a transfer at the end of the block, which we’ve been tracking, as detailed in our docs. The builder first sets its own address to receive the block’s transaction fees and then uses the same address to pay the proposer. However, we have observed instances where the builder employs a different address to remunerate the proposer in the end-of-block transaction, from the one they used to receive the block’s transaction fees. This pattern was not previously tracked by us.

Example: Block 18048751 | Slot 7236061

Problem

We missed mev-boost blocks where the builder's address that received the block's transaction fees was not the one that sent the payment at the end of the block. 

Solution

We updated our methodology to remove the strict condition that the sender address of the end-of-block transaction must be the same address that received the transaction fees of the block.

Pattern 2: Builder pays the proposer through an end-of-block transaction  initially transferring the amount to an alternate address, which then initiates an internal transaction to send the funds to the proposer.

Similarly, there are also cases wherein while the sender of the end of block transaction is the builder, the receiver is a different address (example: a smart contract). This address then makes the payment to the proposer fee recipient through an internal transaction.

Example: Block 18901160 | Slot 8095796

Problem

We were already tracking internal transactions to proposers before but only if they were also the recipient of the block's transaction fees (i.e. builder pays proposer through a coinbase transfer).

Solution

We've updated our methodology to also account for internal transactions wherein the proposer's fee recipient was the receiver while the builder was the recipient of the block's transaction fees. Additionally, we are implementing an extra verification step to confirm that if a mev-boost relay identifies a block as a mev-boost block, it is also recorded as such in our database.

🚧 Note: We will apply these changes in production and do a refresh of our validator rewards database from September 2022. All API endpoints and fields that refer to rewards from the Ethereum execution layer, including its aggregations, and annual percentage return (APR) values shall be impacted.

Acknowledgements: Rosa Karimi Adl and the Figment team for bringing this to our attention.