ethereum.raw.block_rewards model provides enriched block-level data of the various types of protocol-level rewards to the miners (block builder) and block proposers (validator), pre and most-merge.
Update: 2024-05-20 — Pre-merge backfill and reward precision
- This table is updated to include pre-merge block-level rewards.
- All columns with ETH values (rewards) in this table are kept in string format to retain precision.
Update: 2026-07-28 — MEV payout detection correction
- Added a third detection signal for
has_mev_reward/proposer_mev_reward: MEV payouts that a builder routes through a separate payout wallet (distinct from the block’sbuilder_address) are now recognized. Previously, these blocks were misclassified as non-PBS, and the model attributed the builder’s full gross capture (priority fees + direct transfers) to the proposer instead of the actual, smaller MEV payout. - Why this happened:
has_mev_rewardis inferred from on-chain heuristics rather than an authoritative source. The original logic recognized a payout only when it was sent directly from the block’s builder address, or directly to the validator’s beacon withdrawal address. Some builders route the payout through a separate wallet that is neither address, so those blocks fell through both checks. - Scope: across the post-Merge period, roughly 4% of validator-days have a changed
proposer_mev_reward/has_mev_reward, affecting about 15% of validators that have ever proposed a block. In aggregate, totalproposer_mev_rewardacross the period is reduced by roughly 1.2%. For most affected validator-days the change is a few thousandths of an ETH; a smaller number of validator-days, concentrated among a handful of large builders, were overstated by tens to hundreds of ETH. - Historical
block_rewardsis being backfilled for all post-Merge blocks (September 15, 2022 onward). This table is incremental, so historical values will only update once the backfill runs — not on the next regular refresh.
- Miner (block builder)
- Pre-merge
- Block rewards from protocol emissions.
- For each block, the miner is rewarded with a finite amount of Ether on top of the fees paid.
- Uncle rewards
- Uncles reward is valid but rejected as it is not on the longest chain which is the working mechanism of the blockchain.
- Block rewards from protocol emissions.
- Transaction priority fee
- Direct transfers from transaction senders to block builder
- Pre-merge
- Proposer (MEV post-merge)
- Amount of MEV reward received by the block proposer, and the corresponding index of the validator that proposed the block
- MEV rewards are identified using the following logic:
- If the last transaction of the block is sent from the block builder (miner), this is assumed to be an MEV payout
- If the last transaction of the block is sent to the withdrawal address of the validator that proposed the block, this is also captured as an MEV payout
- If the last transaction of the block is a direct ETH transfer to a different, non-self address, and the sender is a wallet with an established history of paying MEV payouts to known validator withdrawal addresses on behalf of that same builder (a “payout wallet”), this is also captured as an MEV payout. This catches builders that route the proposer payout through a wallet other than their own block fee-recipient address — the sender differs from
builder_address, and the recipient differs from the beacon withdrawal address, so neither of the first two rules applies.
- Example: https://etherscan.io/block/19900222#mevinfo
Sample Query
Examine block-level rewards by reward type on Ethereum over time.Table Columns
Unique key:block_number