Schema Changes: Glamsterdam ePBS Upgrade - Allium Documentation Hub

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.

October 6, 2026

Allium schema. The Gloas tables below (execution_payload_bids, payload_attestations, execution_requests, builder_snapshot, execution_payload_envelopes) are built and validated. They are not yet live on beacon_hoodi or beacon mainnet; schemas may change until the Hoodi cutover.Devnet timeline (Forkcast). Forkcast lists Glamsterdam as Upcoming for 2026 with no public-testnet (Hoodi/Sepolia) or mainnet activation date set yet. The Gloas fork has so far run only on short-lived devnets:

Devnet	Genesis (UTC)	Gloas fork (UTC)	Notes
`epbs-devnet-0` / `epbs-devnet-1`	2026-03-04 / 2026-03-31	—	ePBS-only headliner devnets
`glamsterdam-devnet-0`	2026-04-24	—	First combined devnet (BAL + ePBS)
`glamsterdam-devnet-2` / `-3`	2026-04-30 / 2026-05-06	—	Combined devnets
`glamsterdam-devnet-5` / `-6` / `-7`	2026-06-04 / 2026-06-26 / mid-July (targets)	—	Planned launch targets
`glamsterdam-devnet-8` (Plataberget)	2026-08-13 12:00	2026-08-20 (epoch 1536)	Fork-transition devnet from a large pre-fork state; stays up until the mainnet fork
`glamsterdam-devnet-9`	2026-09-01 15:00	2026-09-02 15:00 (epoch 225)	Clean fork transition and non-finality testing
`glamsterdam-devnet-10`	2026-09-05 01:30	Genesis (epoch 0)	Gloas active from genesis
`glamsterdam-devnet-11`	2026-09-14 12:00	2026-09-16 12:00 (epoch 450)	Happy-path fork-transition devnet for L2s; no new EIPs

Source: Forkcast — Glamsterdam, checked October 6, 2026.

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.builder_snapshot), 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 beacon.raw.execution_payload_envelopes. 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.builder_snapshot`, not a validator index
`builder_payment`	Does not exist	NEW — bid `value` in Gwei paid by builder to proposer
`builder_value`	Does not exist	NEW — bid `value` as committed by the builder
`builder_execution_payment`	Does not exist	NEW — bid `execution_payment`, paid at the execution layer
`builder_payment_type`	Does not exist	NEW — how the builder payment was made

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
`builder_index`	bigint	Index into `beacon.raw.builder_snapshot` — 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
`prev_randao`	varchar	`prev_randao` committed in the bid
`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
`signature`	varchar	Builder’s signature over the bid

This table covers the bid only — block hash, builder, and committed values. Transactions, withdrawals, gas usage and state/receipts roots are only available once the builder reveals the SignedExecutionPayloadEnvelope; use beacon.raw.execution_payload_envelopes for those.

`beacon.raw.payload_attestations`

Provides one row per Payload Timeliness Committee (PTC) attestation included in a block, recording whether the builder revealed the execution payload on time. Unique Key: (slot_number, signature) — a block can carry several payload attestations.

Column	Type	Description
`slot_number`	bigint	Beacon slot of the block that included the attestation
`slot_timestamp`	timestamp	Slot timestamp
`attested_slot`	bigint	Slot being attested
`attested_beacon_block_root`	varchar	Root of the beacon block being attested
`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
`signature`	varchar	Aggregate signature of the attestation

`beacon.raw.builder_snapshot`

Provides a per-slot snapshot of each registered builder, tracking the 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. To get the latest state of a builder, take the row with the highest slot_number for its builder_index. Unique Key: (slot_number, builder_index)

Column	Type	Description
`slot_number`	bigint	Slot the snapshot was taken at
`slot_timestamp`	timestamp	Slot timestamp
`builder_index`	bigint	Index into the builder registry
`status`	varchar	Builder lifecycle status
`pubkey`	varchar	Builder’s BLS public key
`version`	varchar	Builder version byte
`execution_address`	varchar	Execution-layer address for builder payments
`balance`	numeric	Builder balance in Gwei
`deposit_epoch`	bigint	Epoch the builder registered
`withdrawable_epoch`	bigint	Epoch the builder’s balance becomes withdrawable
`execution_optimistic`	boolean	Beacon API `execution_optimistic` flag
`finalized`	boolean	Beacon API `finalized` flag

`beacon.raw.execution_payload_envelopes`

Provides one row per slot containing the ExecutionPayloadEnvelope the builder reveals after the block. This is the replacement source for post-fork execution payload data (transactions, withdrawals, gas usage, roots, and block_access_list from EIP-7928). Unique Key: slot_number

Column	Type	Description
`slot_number`	bigint	Beacon slot number
`slot_timestamp`	timestamp	Slot timestamp
`beacon_block_root`	varchar	Root of the beacon block the envelope belongs to
`parent_beacon_block_root`	varchar	Root of the parent beacon block
`builder_index`	bigint	Index into `beacon.raw.builder_snapshot`
`payload`	variant	Revealed execution payload
`execution_requests`	variant	Current-slot execution requests
`execution_optimistic`	boolean	Beacon API `execution_optimistic` flag
`finalized`	boolean	Beacon API `finalized` flag

`beacon.raw.execution_requests`

Provides one row per slot with the execution requests as separate columns, including the two new Gloas request types. Unique Key: slot_number

Column	Type	Description
`slot_number`	bigint	Beacon slot number
`slot_timestamp`	timestamp	Slot timestamp
`deposits`	variant	Validator deposit requests
`withdrawals`	variant	Validator withdrawal requests
`consolidations`	variant	Validator consolidation requests
`builder_deposits`	variant	NEW — builder deposit requests
`builder_exits`	variant	NEW — builder exit requests

Migration Timeline

Timeline	Estimated Date	Status
Hoodi testnet ePBS activation	~~Early April 2026~~ — no date set; Forkcast lists Glamsterdam as Upcoming (2026). Latest Gloas fork on a devnet: `glamsterdam-devnet-11`, 2026-09-16	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
Use `beacon.raw.execution_payload_envelopes` for revealed transactions/withdrawals	High	Before mainnet activation
Update builder-identity joins to use the new `beacon.raw.builder_snapshot` 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 — it is available inside the payload column of beacon.raw.execution_payload_envelopes.

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: October 6, 2026 — see Devnet Progress Updates for change history.

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

​beacon.raw.execution_payload_envelopes

​beacon.raw.execution_requests

​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.builder_snapshot`

`beacon.raw.execution_payload_envelopes`

`beacon.raw.execution_requests`

Migration Timeline

Action Items

Additional Notes

EIP-7928 (Block-level Access Lists)

Reference Documentation

Support