Term | Definition |
---|---|
builder | An agent that constructs a block, drawing from transactions or bundles of transactions sourced from public and/or private mempools. |
relay | An entity that gathers blocks and bids from builders. The source of the block that is proposed by a validator who wants to get MEV rewards. |
vanilla_block | A block that has not been procured from a MEV relay, and is most likely a build by default spec block. |
mev_boost_block | A block that has been procured from a MEV relay. |
avg_bid | The average value of bids logged on all relays, in any given block height. |
max_bid | The maximum bid observed, from the population of bids received by relays, in any given block height. |
winning_bid | The bid that represents the block that made it to the canonical chain as procured from an MEV relay. |
fee_recipient | The specified address that receives the priority_fees in the block constructed by the builder. Depending on the case, the fee recipient could be the address of the builder or the proposer. |
priority_fees | Also called block rewards; transaction fees paid to the fee_recipient by end-users for their transactions to be included in the block. |
end_tx | A transaction that takes place at the end of the block and involves the builder that crafted the block and the block proposer. |
proposer_account | Address specified by the validator/proposer where they want to be paid the rewards from the block by the builder |
baseline_mev | The minimum MEV rewards calculated in the block, outside of any priority_fees |
secondary_builder_address | A second address associated with the builder that is used to pay the proposer_account . |
internal_tx | An internal transaction that takes place within the the end of the block that involves the value transfer from any of the builder’s addresses to the block proposer. |
end_tx
as parametrized in the table above, (b) one in which the value transfer happens exclusively via the fee_recipient,
and (c) one that involves an an end_tx
and an internal_tx
.
The following case based approach is based on modulating these three parameters, as well as whether the relay where the block was procured from is known or not.
fee_recipient
and pays the proposer via an end_tx
(e.g. Flashbots relay). A builder may choose to use the same address they set as the fee_recipient
to pay the proposer or a different one (secondary_builder_address
). What is consistent here is that regardless of the address used by the builder, the proposer is paid through an end_tx
.
Variable | Value |
---|---|
relay | KNOWN |
winning_bid | KNOWN |
end_tx | KNOWN |
fee_recipient | Builder |
internal_tx | n/a |
winning_bid
is greater than or equal to the sum of priority_fees
for the transactions in the block, and , we calculate baseline MEV as:
baseline_mev
are known. The winning_bid
is captured from the relay and the priority_fees
are computed from the transaction fees in the block.
If the winning_bid
is less than the sum of priority_fees
, for the transactions in the block, we calculate:
winning_bid
they received as the priority_fees
that went to said validator.
fee_recipient
(e.g. Manifold relay).
Variable | Value |
---|---|
relay | KNOWN |
winning_bid | KNOWN |
end_tx | n/a |
fee_recipient | Proposer |
internal_tx | n/a |
winning_bid - priority_fees
lens appears rational, cases like the Manifold bug have shown that bids can be misconfigured to not show exactly how much a validator receives in the end.end_tx
which then initiates an internal_tx
to send the funds to the validator.
Variable | Value |
---|---|
relay | KNOWN |
winning_bid | KNOWN |
end_tx | KNOWN |
fee_recipient | Builder |
internal_tx | KNOWN |
winning_bid
is greater than or equal to the sum of priority_fees
for the transactions in the block, and , we calculate baseline MEV as:
winning_bid
is less than the sum of priority_fees
, for the transactions in the block, we calculate:
winning_bid
they received as the priority_fees
that went to said validator.
The calculation is identical to Case A.1, it is just that here, the winning bid would equate to the value of the internal_tx
instead of the end_tx
.
end_tx
this is most likely a relay block.
Variable | Value |
---|---|
relay | UNKNOWN |
winning_bid | UNKNOWN |
end_tx | KNOWN |
end_tx
still observed, if the end_tx
is greater than or equal to the sum of priority_fees
for transactions in the block, we calculate baseline MEV as:
end_tx
is less than the sum of priority_fees
for transactions in the block, we calculate baseline MEV as:
baseline_mev
undetermined and book all the value that went to the proposer as priority_fees
.
Variable | Value |
---|---|
relay | UNKNOWN |
winning_bid | UNKNOWN |
end_tx | UNKNOWN |