> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rated.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Baseline MEV computation

Post-Merge, validators earn rewards from maximal extractable value (MEV) as well as from transaction fees on Ethereum’s execution layer when they are elected to propose blocks.

MEV extracted from the perspective of the validator is difficult to accurately estimate. Some of it is embedded in priority fees, some is disbursed in direct payments to the validator fee recipient, some of it might be disbursed in a different payment pattern between a relayer, a builder and a proposer, and some might not ever print on-chain.

The emergence of out-of-protocol proposer-builder separation (PBS) with mev-boost has introduced a menu of different patterns that make it a non-trivial task to estimate how much MEV was extracted by a validator in a given block.

In this page, we are proposing a case based approach in separating MEV from priority fees on a block by block basis (and then on aggregate) based on information aggregated on-chain and from the various MEV relay APIs.

<Warning>
  We are approaching crafting this methodology with an iterative mindset, and have yet to enshrine this to the front-end and API. We want to hear from the community on which approach is the most realistic, representative and fair.
</Warning>

## Useful definitions

| 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.                           |

## MEV value transfer patterns in the wild

There are three main on-chain patterns in which we have observed value transfers between a block builder and a validator; (a) one that involves the `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.

### **Case A: Known MEV Relay blocks**

#### **Case A.1**

This class of cases describe patterns where the builder has set their own address as the `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     |

If the `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:

<Frame className="text-grey-800 dark:text-white text-sm overflow-x-auto lg:justify-start justify-center">
  $$
  \text{baseline\_mev} = \text{winning\_bid} - \text{priority\_fees}
  $$
</Frame>

This is the most straightforward case as the components for computing the `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:

```js theme={null}
baseline_mev cannot be determined
```

In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the `winning_bid` they received as the `priority_fees` that went to said validator.

#### **Case A.2**

This class of cases describe patterns where the builder has set the  \*\*\*\*proposer account as the `fee_recipient` (e.g. Manifold relay).

| Variable        | Value    |
| :-------------- | :------- |
| `relay`         | KNOWN    |
| `winning_bid`   | KNOWN    |
| `end_tx`        | n/a      |
| `fee_recipient` | Proposer |
| `internal_tx`   | n/a      |

In this case we revert to:

```js theme={null}
baseline_mev cannot be determined
```

Which implies we book everything that went to validator via priority fees.

<Note>
  While initially looking at this from the `winning_bid - priority_fees` lens appears rational, cases like the [Manifold bug](https://twitter.com/jon_charb/status/1581396552815632384?s=20\&t=zb6HlKh1pIsaXQMle7ka0A) have shown that bids can be misconfigured to not show exactly how much a validator receives in the end.
</Note>

#### **Case A.3**

This class of cases describe patterns where the builder has set an alternate receiver address (say a smart contract) in the `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   |

If the `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:

<Frame className="text-grey-800 dark:text-white text-sm overflow-x-auto lg:justify-start justify-center">
  $$
  \text{baseline\_mev} = \text{winning\_bid} - \text{priority\_fees}
  $$
</Frame>

If the `winning_bid` is **less than** the sum of `priority_fees`, for the transactions in the block, we calculate:

```js theme={null}
baseline_mev cannot be determined
```

In the absence of tools to recreate what the block value would have looked like if the proposer made a block by spec, we classify the `winning_bid` they received as the `priority_fees` that went to said validator.

The calculation is identical to [Case A.1](#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`.

### **Case B: Unknown but likely MEV Relay**

This class of cases describe patterns where we do not know the relay the block came from, but given the presence of an `end_tx` this is most likely a relay block.

| Variable      | Value   |
| :------------ | :------ |
| `relay`       | UNKNOWN |
| `winning_bid` | UNKNOWN |
| `end_tx`      | KNOWN   |

In the absence of data from relays, but with an `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:

<Frame className="text-grey-800 dark:text-white text-sm overflow-x-auto lg:justify-start justify-center">
  $$
  \text{baseline\_mev} = \text{end\_tx} - \text{priority\_fees}
  $$
</Frame>

Conversely, if the `end_tx` is **less than** the sum of `priority_fees` for transactions in the block, we calculate baseline MEV as:

```js theme={null}
baseline_mev cannot be determined
```

We then consider `baseline_mev` undetermined and book all the value that went to the proposer as `priority_fees`.

### **Case** C: Vanilla block

| Variable      | Value   |
| :------------ | :------ |
| `relay`       | UNKNOWN |
| `winning_bid` | UNKNOWN |
| `end_tx`      | UNKNOWN |

If all of the parameters we are segregating for are UNKNOWN then we revert to :

```js theme={null}
baseline_mev cannot be determined
```

Qualitatively, if this type of state is observed, it could mean a few things: (1) this is a vanilla block, (2) the bid payment was made out of band (e.g. mev-hiding), or (3) the validator is doing their own block building and MEV extraction.

We believe that these cases in their majority are vanilla blocks, but hold out for emerging patterns as the landscape evolves towards maturity.