Schema Changes: Glamsterdam ePBS Upgrade

Breaking Schema ChangesEthereum’s Glamsterdam upgrade introduces EIP-7732: Enshrined Proposer-Builder Separation (ePBS), which fundamentally changes how beacon blocks are structured.Action Required: Queries using execution_payload, blob_kzg_commitments, or execution_requests fields in beacon.raw.blocks and beacon_hoodi.raw.blocks will return NULL values for all slots after the Glamsterdam activation.

Devnet Progress Updates

We track the state of the Glamsterdam devnet here on each check-in, most recent first, so you can see what changed between updates rather than just the current status. Source: Forkcast — Glamsterdam.

September 9, 2026

Pending — no verified update yet. The last confirmed status is the July 10, 2026 entry below; check back or see Forkcast for the latest devnet number and client readiness before relying on this page for current status.

July 10, 2026

Glamsterdam remains in Devnet. No change to the schema plan below — actively monitoring and will implement schema changes once ePBS is live on Hoodi testnet.

What Is Changing

The Glamsterdam upgrade restructures how beacon blocks are produced by enshrining the proposer-builder separation protocol directly into the consensus layer.

Key Change: Block Body Structure

Before Glamsterdam, a beacon block body contains the full execution payload with transaction data:

{
  "body": {
    "execution_payload": {
      "block_hash": "0xabc...",
      "block_number": "21000000",
      "timestamp": "1700000000",
      "fee_recipient": "0xdef...",
      "transactions": [...],
      "withdrawals": [...]
    },
    "blob_kzg_commitments": [...],
    "execution_requests": {...}
  }
}

After Glamsterdam, the proposer commits only a bid from the builder — the execution payload is revealed separately:

{
  "body": {
    "signed_execution_payload_bid": {
      "message": {
        "slot": "...",
        "block_hash": "0xabc...",
        "parent_block_hash": "0x...",
        "parent_block_root": "0x...",
        "builder_index": "12345",
        "fee_recipient": "0xdef...",
        "gas_limit": "30000000",
        "value": "1500000000",
        "execution_payment": "1500000000",
        "blob_kzg_commitments": [...],
        "execution_requests_root": "0x..."
      },
      "signature": "0x..."
    },
    "payload_attestations": [
      {
        "aggregation_bits": "0x...",
        "data": {
          "beacon_block_root": "0x...",
          "slot": "...",
          "payload_present": true,
          "blob_data_available": true
        },
        "signature": "0x..."
      }
    ],
    "parent_execution_requests": {...}
  }
}

The execution_payload and blob_kzg_commitments fields are absent from the block body for all slots after the fork — blob_kzg_commitments moves into the bid itself rather than the revealed payload. execution_requests is also gone from its old position, though the body retains a parent_execution_requests field (the previous slot’s requests, kept for verification) — it isn’t a clean removal.

builder_index is an index into a new, separate builder registry (beacon.raw.builders), not a validator index. Builders register and exit independently of the validator set via BuilderDepositRequest / BuilderExitRequest, and hold their own balance, deposit_epoch, and withdrawable_epoch. Do not join builder_index against beacon.raw.validators.

Why This MattersePBS separates the roles of block proposers and block builders at the protocol level. Proposers commit to a builder’s bid without seeing the full payload contents, which is then attested by a Payload Timeliness Committee (PTC). This reduces MEV centralization risks and improves censorship resistance.

Impact to Allium Tables

`beacon.raw.blocks` — Breaking Changes

The following columns will be affected for all slots after Glamsterdam activation:

Column	Current Behavior	Post-Glamsterdam Behavior
`execution_payload`	Always present (object)	NULL or missing
`eth1_block_hash`	Execution block hash	Unchanged — populated via internal join (bid commits `block_hash` upfront)
`eth1_block_number`	Execution block number	Unchanged — backfilled via internal join to execution-layer data
`eth1_block_timestamp`	Execution block timestamp	Unchanged — backfilled via internal join to execution-layer data
`transaction_count`	Integer ≥ 0	0 (no payload in block body)
`withdrawal_count`	Integer ≥ 0	0 (no payload in block body)
`withdrawals`	Array of withdrawal objects	NULL
`blob_kzg_commitments`	Array (if blobs present)	NULL (moves into the bid)
`execution_requests`	Object (post-Pectra)	NULL (see note below)
`signed_execution_payload_bid`	Does not exist	NEW — builder’s signed bid
`payload_attestations`	Does not exist	NEW — PTC attestation array

execution_requests isn’t a clean removal: the block body retains a parent_execution_requests field carrying the previous slot’s requests for verification. The current-slot requests move to the ExecutionPayloadEnvelope, gossiped separately by the builder — see the payload-envelope gap noted under New Tables. The ExecutionRequests schema also grows two new request types in Gloas, builder_deposits and builder_exits, alongside the existing deposits/withdrawals/consolidations.

Migration Path: eth1_block_hash, eth1_block_number, and eth1_block_timestamp stay populated — Allium resolves these internally via a join to execution-layer data rather than reading them off the beacon block body, so no query changes are needed for those three columns. Use the new beacon.raw.execution_payload_bids table (see below) for builder and bid-specific information (builder identity, bid value, gas limit) that has no other source post-fork.

`beacon.raw.block_rewards` — Additive Changes

New columns will be added to provide explicit builder payment tracking:

Column	Current Behavior	Post-Glamsterdam Behavior
`total`	Consensus proposer reward	Unchanged
`attestations`	Component breakdown	Unchanged
`sync_aggregate`	Component breakdown	Unchanged
`proposer_slashings`	Component breakdown	Unchanged
`attester_slashings`	Component breakdown	Unchanged
`builder_index`	Does not exist	NEW — index into `beacon.raw.builders`, not a validator index
`builder_payment`	Does not exist	NEW — bid `value` in Gwei paid by builder to proposer

No Breaking Changes: All existing columns remain available. The new builder_payment field maps to the bid’s value field (consensus-layer payment to the proposer) — it is distinct from execution_payment, the amount the builder pays at the execution layer to fee_recipient (see beacon.raw.execution_payload_bids below). builder_payment provides explicit execution reward attribution, replacing the current fee-recipient inference method for post-fork slots.

`beacon.validator.consensus_income` — No Changes

This view aggregates consensus-layer rewards only (attestations, sync committee, block proposals). No structural changes are expected.

New Tables

`beacon.raw.execution_payload_bids`

Provides one row per slot containing the builder’s committed bid from the beacon block body. Use this table to look up execution block hashes and builder information for post-Glamsterdam slots. Unique Key: slot_number

Column	Type	Description
`slot_number`	bigint	Beacon slot number
`slot_timestamp`	timestamp	Slot timestamp
`proposer_index`	bigint	Validator index of the proposer
`builder_index`	bigint	Index into `beacon.raw.builders` — not a validator index
`value`	numeric	Bid value in Gwei paid by the builder to the proposer (consensus layer)
`execution_payment`	numeric	Amount in Gwei paid by the builder to `fee_recipient` (execution layer)
`parent_block_hash`	varchar	Parent execution block hash
`parent_block_root`	varchar	Parent beacon block root
`block_hash`	varchar	Committed execution block hash
`gas_limit`	bigint	Proposed gas limit
`fee_recipient`	varchar	Fee recipient address
`blob_kzg_commitments`	array	Blob KZG commitments, committed upfront in the bid
`execution_requests_root`	varchar	Root of the execution requests, revealed later in the payload envelope

Gap: this table covers the bid only — block hash, builder, and committed values. It does not carry the actual transactions, withdrawals, gas usage, or state/receipts roots, since those are only available once the builder reveals the SignedExecutionPayloadEnvelope after the block. Allium does not yet have a planned table for the revealed payload (tentatively beacon.raw.execution_payload_envelopes); until one ships, post-fork transaction/withdrawal data has no replacement source in Allium tables.

`beacon.raw.payload_attestations`

Provides one row per Payload Timeliness Committee (PTC) attestation, recording whether the builder revealed the execution payload on time. Unique Key: slot_number

Column	Type	Description
`slot_number`	bigint	Beacon slot being attested
`slot_timestamp`	timestamp	Slot timestamp
`payload_present`	boolean	Whether the PTC attested the payload was revealed on time
`blob_data_available`	boolean	Whether the PTC attested the blob data was available
`aggregation_bits`	varchar	Bitfield of PTC members who signed this attestation
`beacon_block_root`	varchar	Root of the beacon block being attested

`beacon.raw.builders`

Provides one row per registered builder, tracking the new builder lifecycle introduced in Gloas. Builders register and exit independently of the validator set via BuilderDepositRequest / BuilderExitRequest, and hold their own balance separate from any validator. Unique Key: builder_index

Column	Type	Description
`builder_index`	bigint	Index into the builder registry
`pubkey`	varchar	Builder’s BLS public key
`execution_address`	varchar	Execution-layer address for builder payments
`balance`	numeric	Current builder balance in Gwei
`deposit_epoch`	bigint	Epoch the builder registered
`withdrawable_epoch`	bigint	Epoch the builder’s balance becomes withdrawable

Migration Timeline

Timeline	Estimated Date	Status
Hoodi testnet ePBS activation	~~Early April 2026~~ — slipped, still in Devnet as of September 2026	Delayed, see Devnet Progress Updates
Allium Hoodi schema update live	~1 week after testnet activation	Pending
Glamsterdam mainnet activation	~~May–June 2026~~ — TBD, tracking Devnet progress	Pending
Allium mainnet schema cutover	Pre-emptively supported	Pending

Additive-First StrategyAllium follows an additive-first migration approach: New columns and tables appear before old columns are deprecated. Deprecated fields return NULL for post-fork slots — columns are not dropped. All changes are live on beacon_hoodi testnet ≥4 weeks before mainnet. Historical data (pre-fork slots) remains unchanged.

Action Items

Action	Priority	Deadline
Identify all queries referencing affected fields in `beacon.raw.blocks` and `beacon_hoodi.raw.blocks`	High	Before Hoodi testnet ePBS activation
Update queries to use `beacon.raw.execution_payload_bids` for block hash lookups	High	Before mainnet activation
Update execution reward reconciliation to use `builder_payment` in `beacon.raw.block_rewards`	High	Before mainnet activation
Test updated queries against Hoodi testnet data	High	During Hoodi testnet window (activation → mainnet)
Optionally consume `beacon.raw.payload_attestations` to detect builder withholding events	Low	Post-mainnet
Decide on and scope a `beacon.raw.execution_payload_envelopes` table for revealed transactions/withdrawals	High	Before mainnet activation
Update builder-identity joins to use the new `beacon.raw.builders` table instead of `beacon.raw.validators`	High	Before mainnet activation

Deadlines are keyed to devnet/testnet/mainnet milestones rather than fixed calendar dates — see Devnet Progress Updates for the current schedule, since Glamsterdam has slipped past its original April/May 2026 estimates.

Additional Notes

EIP-7928 (Block-level Access Lists)

EIP-7928 is included in the Glamsterdam upgrade. The Gloas ExecutionPayload container itself gains a block_access_list field (plus a slot_number field), so this is not purely an execution-layer-internal change — once Allium models the revealed payload (see the execution_payload_envelopes gap above), block_access_list should be included as a column.

Reference Documentation

Support

If you have questions about migrating your queries or need assistance testing against Hoodi testnet data, please contact the Allium support team.

Last checked: September 9, 2026 — see Devnet Progress Updates for change history.

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Devnet Progress Updates

What Is Changing

Key Change: Block Body Structure

Impact to Allium Tables

`beacon.raw.blocks` — Breaking Changes

`beacon.raw.block_rewards` — Additive Changes

`beacon.validator.consensus_income` — No Changes

New Tables

`beacon.raw.execution_payload_bids`

`beacon.raw.payload_attestations`

`beacon.raw.builders`

Migration Timeline

Action Items

Additional Notes

EIP-7928 (Block-level Access Lists)

Reference Documentation

Support

​Devnet Progress Updates

​What Is Changing

​Key Change: Block Body Structure

​Impact to Allium Tables

​beacon.raw.blocks — Breaking Changes

​beacon.raw.block_rewards — Additive Changes

​beacon.validator.consensus_income — No Changes

​New Tables

​beacon.raw.execution_payload_bids

​beacon.raw.payload_attestations

​beacon.raw.builders

​Migration Timeline

​Action Items

​Additional Notes

​EIP-7928 (Block-level Access Lists)

​Reference Documentation

​Support

Devnet Progress Updates

What Is Changing

Key Change: Block Body Structure

Impact to Allium Tables

`beacon.raw.blocks` — Breaking Changes

`beacon.raw.block_rewards` — Additive Changes

`beacon.validator.consensus_income` — No Changes

New Tables

`beacon.raw.execution_payload_bids`

`beacon.raw.payload_attestations`

`beacon.raw.builders`

Migration Timeline

Action Items

Additional Notes

EIP-7928 (Block-level Access Lists)

Reference Documentation

Support