Block Rewards - Allium Documentation Hub

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.

Table Details

Property	Value
Table Name	`ethereum.raw.block_rewards`
Table Status	Production-Ready
Unique Key	`block_timestamp::date`, `block_number`
Clustering Key(s)	`block_timestamp::date`
Search Optimization	`builder_address`, `proposer_index`

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.

Update: 2026-11-04 — MEV reward for multi-party block construction (MPBC) blocks

For blocks that the relays flag as merged, has_mev_reward is now true and proposer_mev_reward is the full proposer value of the merged block: the base block’s value plus the value the extra builders added. Previously, proposer_mev_reward held only the base block’s value, so the added value was dropped.
Why this happened: in an MPBC block the proposer’s fee recipient is usually a settlement contract that pays validators in later blocks. The last transaction to that contract carries only the base block’s value, and block_rewards read the reward from that transaction.
Scope: MPBC blocks from August 28, 2026 onward, for blocks that Ultrasound, Titan and Aestus report as merged. Through October 29, 2026, 8,966 of 9,893 merged blocks increase and 1 decreases (block 26,287,020, by 0.000718 ETH). Each block changes by less than 0.001 ETH, and the correction is below 0.02% of any week’s total proposer MEV. MPBC blocks are a growing share of blocks, from 0.2% to 2.8% in two months. Blocks before August 28, 2026 are not affected.
proposer_fee_recipient and proposer_payout_transaction are unchanged. No columns were added, removed or renamed.
The change is live for new blocks from November 4, 2026. Blocks from August 28 to October 29, 2026 will be refreshed on November 10, 2026. Until then, the previous values stay in place. Downstream, beacon.validator.income execution income for validators that proposed those blocks changes by the same amounts.

Known limitations of MEV payout detection has_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 first three detection rules above. Blocks the relays flag as merged are handled by the fourth rule, even when the payout is split across transactions.
Detection only adds newly-recognized MEV payouts as heuristics improve — it does not remove a payout that was already correctly detected. Execution/MEV income is not a protocol-native field: unlike consensus income, which is derived directly from beacon-chain state, Ethereum has no single protocol-level field for execution/MEV income. Reconstructing it requires combining on-chain payout patterns with off-chain relay data, and both sources have gaps:
No relay is a universal source of truth. The relay market is split across several independent relays, each seeing only the auctions it ran; none has full market coverage, and coverage/latency vary by relay.
Non-PBS (self-built) blocks never touch a relay at all, so there is no off-chain record to check on-chain detection against for that share of blocks.
Even where relay bid-trace data exists, the bid a builder promised does not always equal the realized on-chain payout — payout paths and wallet usage vary, so bid data and on-chain outcomes can disagree even in well-covered cases. We treat MEV detection as an evolving heuristic rather than a finished one. Planned work to close the gap includes ingesting relay bid-trace data directly and auditing on-chain detection against it. Execution income remains a best-effort reconstruction until then.

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.
  - If the relays’ merged-blocks data flags the block as merged (multi-party block construction), the block has an MEV reward and proposer_mev_reward is the merged block’s proposer value, which includes the value added by the extra builders. This rule takes precedence over the other rules. It covers blocks reported by Ultrasound, Titan and Aestus.
- Example: https://etherscan.io/block/19900222#mevinfo

Sample Query

Examine block-level rewards by reward type on Ethereum over time.

select
    date_trunc('week', block_timestamp) as date,
    sum(block_reward) as block_reward,
    sum(uncles_reward) as uncles_reward,
    sum(builder_priority_fee_reward) as builder_priority_fee_reward,
    sum(builder_direct_reward) as builder_direct_reward,
    sum(proposer_mev_reward) as proposer_mev_reward
from ethereum.raw.block_rewards
group by all

Table Columns

Column Name	Data Type	Description
block_number	NUMBER(38,0)	The block number.
block_timestamp	TIMESTAMP_NTZ(9)	The unix timestamp for when the block was collated.
has_block_reward	BOOLEAN	Boolean flag indicating that there is a block reward pre-merge.
block_reward	VARCHAR(16777216)	Amount of block rewards to the miner in ETH.
has_uncle_reward	BOOLEAN	Boolean flag indicating that there is a uncle reward pre-merge.
uncles_reward	VARCHAR(16777216)	Amount of block uncle rewards in ETH. Note that it is possible to have more than one uncles rewards recipient.
uncles_reward_transactions	VARIANT	The trace level transfers to the uncles reward recipient wrapped in JSON.
base_fee_burnt	VARCHAR(16777216)	ETH burnt from base fee gas amount.
builder_priority_fee_reward	VARCHAR(16777216)	Priority fee (tips) to the block builder (miner) recipient address.
builder_direct_reward	VARCHAR(16777216)	Direct ETH transfers rewarded to the block builder (miner) in the block.
builder_address	VARCHAR(42)	Block builder (miner) address.
builder_direct_transactions	VARIANT	Array of direct ETH transactions to the block producer in the block, assumed to be builder’s direct rewards.
has_mev_reward	BOOLEAN	Boolean flag indicating whether there is an MEV reward, sent from the block builder (or a wallet acting on its behalf) to the block proposer fee recipient in the last transaction of the block. See “MEV rewards are identified using the following logic” above.
proposer_mev_reward	VARCHAR(16777216)	Proposer’s MEV reward sent from the block builder.
proposer_fee_recipient	VARCHAR(42)	Block proposer fee recipient address.
proposer_payout_transaction	VARCHAR(66)	Proposer’s MEV reward payout transaction.
l1_gas_used	VARCHAR(16777216)	L1 gas used.
l1_gas_limit	VARCHAR(16777216)	L1 gas limit of the block.
l1_extra_data	VARCHAR(16777216)	L1 extra data.
l1_block_hash	VARCHAR(66)	L1 block hash.
slot_number	NUMBER(38,0)	Beacon Chain slot number.
epoch	NUMBER(38,0)	Beacon Chain epoch number.
proposer_index	NUMBER(38,0)	Validator Index of the block proposer on Beacon Chain.
pubkey	VARCHAR(16777216)	Pubkey of the validator proposing this block.
graffiti	VARCHAR(16777216)	32-byte field of arbitrary data included by the block proposer.
_created_at	TIMESTAMP_NTZ(9)	Timestamp of when the entry was created in the database.
_updated_at	TIMESTAMP_NTZ(9)	Timestamp of when the entry was last updated in the database.
_changed_since_full_refresh	BOOLEAN	Indicates if the record has changed since the last full data refresh.

EVM

​Table Details

​Sample Query

​Table Columns

Table Details

Sample Query

Table Columns