Unrealized Value in MEV-Boost

[boz1]

Hi all,

I’ve been monitoring the ProposerPayloadsDelivered and BuilderBlocksReceived endpoints of the relay api for some time now and I have come across many cases where the proposed payload had a value smaller than another block submitted to a different relay or even the same relay. After some discussion on the Flashbots discord, I’ve decided that I want to quantify this “unrealized” amount and made a hack over the mevboost.org repo.

I fetched the highest value block submitted to each relay for each slot (using the BuilderBlocksReceived endpoint). Then, for each delivered payload, I checked whether it is the highest value block proposed to any relay (including the relay that delivered the payload) for that specific slot. If it is not the case, then I labeled the value difference between the “largest value block” and the delivered payload as “unrealized value”.

My syncing process just ended and here are the first results:

Happy to hear any feedback!

PS: In slot 4849684, the block which was delivered as the payload (0x2dcc0c3e5d30a714342e9ebdaf425db57188ca371e021f6d38d098a8c9033f6e) was submitted 1 sec before the first 465 ETH block

[metachris]

I don’t think the data fully supports the conclusions about unrealized value. In particular, block builders continue submitting blocks even after the proposer asked for the header, often until they are notified of a new payload, which can be quite a few seconds after the bid was delivered to the proposer.

But practically the proposer has to ask for the bid at some point early enough to still have enough time to receive the bid and do the getPayload dance, or fall back to a local EL block.

[boz1]

I see your point. In that case, one option could be to classify the unrealized value data based on the availability of a higher value block when the proposer was selecting a payload. We can label this type of unrealized value as “realizable unrealized value”.