Skip to main content
The 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’s builder_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_reward is 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, total proposer_mev_reward across 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_rewards is 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.
Known limitations of MEV payout detectionhas_mev_reward is inferred from on-chain heuristics, not from MEV-boost relay bid-trace data — the authoritative record of what a builder actually paid a proposer. Allium does not currently ingest relay bid-trace data, so some edge cases can still be missed:
  • A builder’s separate payout wallet is only trusted once it has an established track record of paying known validator withdrawal addresses. A wallet’s first several payouts, before that track record accumulates, may not yet be recognized as an MEV payout.
  • Detection can improve as more payout history accumulates over time, so a given historical block’s classification is not guaranteed to be stable until any pending backfill has completed.
  • A payout that is not the block’s last transaction, or that is split across multiple transactions, is not recognized as an MEV payout by any of the three detection rules above.
  • Detection only adds newly-recognized MEV payouts as heuristics improve — it does not remove a payout that was already correctly detected.
We treat MEV detection as an evolving heuristic rather than a finished one, and expect to keep refining it — including a longer-term plan to ingest relay bid-trace data directly.
Block-level ETH rewards on Ethereum can be separated into various types:
  • 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.
    • Transaction priority fee
    • Direct transfers from transaction senders to block builder
  • 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