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 the 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.

Timeline update (October 24, 2026): Glamsterdam is delayed. The Hoodi testnet activation originally scheduled for October 26, 2026 has been postponed while Ethereum core developers review how the proposed gas-accounting changes (EIP-8037) interact with existing smart contracts. No replacement date has been announced. The schema changes described on this page will take effect later than previously expected. Nothing changes in your data or queries today. We are monitoring the situation and will update this page as the timeline firms up. See the Ethereum Foundation announcement for details.

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 24, 2026

Hoodi activation postponed. The October 26, 2026 Hoodi activation was removed from the schedule on October 22, along with the Amsterdam (execution layer) and Gloas (consensus layer) activations on Hoodi. Core developers are assessing the interaction between the new gas-accounting rules and already-deployed contracts before setting a new date. No replacement Hoodi or mainnet date has been announced.What this means for Allium. The beacon_hoodi and beacon schema changes below are deferred until the fork is rescheduled. Existing columns continue to be populated as they are today, and the Gloas tables remain not yet live. We will confirm the new Allium rollout timing once a Hoodi date is set, and will continue to give at least four weeks of notice on beacon_hoodi before mainnet. Source: Ethereum Foundation blog — Glamsterdam Hoodi delay.

October 15, 2026

Allium schema: new block fields are columns on raw.blocks. The three new Gloas block-body fields (signed_execution_payload_bid, payload_attestations, parent_execution_requests) are stored as columns on raw.blocks, alongside the other body fields such as attestations and deposits. There will be no separately ingested tables for data that comes from the beacon block.

raw.execution_payload_bids and raw.payload_attestations keep their names but are now views over those raw.blocks columns, like raw.attestations and raw.deposits.
raw.execution_requests is a view: pre-Gloas rows come from raw.blocks.execution_requests, Gloas rows from raw.execution_payload_envelopes.
Only data that does not come from the beacon block is ingested into its own table: raw.execution_payload_envelopes (a separate Beacon API endpoint, and can be missing) and raw.builders (beacon state, once per epoch).
builder_snapshot is renamed raw.builders: one row per builder per epoch, with balance in ETH and raw_balance in Gwei, as in raw.balances.
raw.block_rewards gets no new columns. Builder payments are in raw.execution_payload_bids (value, execution_payment).
raw.blocks.eth1_*, transaction_count, withdrawal_count and withdrawals stay populated after the fork, read from the revealed execution payload. raw.blocks.blob_kzg_commitments is NULL after the fork: the commitments move into the bid (raw.execution_payload_bids), where they are promised rather than guaranteed published.

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.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 change for all slots after Glamsterdam activation:

Column	Current Behavior	Post-Glamsterdam Behavior
`execution_payload`	Always present (object)	NULL (the payload is no longer in the block body)
`execution_requests`	Object (post-Pectra)	NULL (see note below)
`eth1_block_hash`	Execution block hash	Unchanged — read from the revealed execution payload
`eth1_block_number`	Execution block number	Unchanged — read from the revealed execution payload
`eth1_block_timestamp`	Execution block timestamp	Unchanged — read from the revealed execution payload
`transaction_count`	Integer ≥ 0	Unchanged — counted from the revealed execution payload
`withdrawal_count`	Integer ≥ 0	Unchanged — counted from the revealed execution payload
`withdrawals`	Array of withdrawal objects	Unchanged — read from the revealed execution payload
`blob_kzg_commitments`	Array (if blobs present)	NULL (moves into the bid; see note below)
`signed_execution_payload_bid`	Does not exist	NEW — the builder’s signed bid (variant); NULL before the fork
`payload_attestations`	Does not exist	NEW — PTC attestation array (variant); NULL before the fork
`parent_execution_requests`	Does not exist	NEW — the previous slot’s execution requests (variant); NULL before the fork

When a builder does not reveal its payload, the slot still has a beacon block but no execution payload: eth1_* and withdrawals are NULL and transaction_count and withdrawal_count are 0 for that slot.

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 and beacon.raw.execution_requests. The ExecutionRequests schema also grows two new request types in Gloas, builder_deposits and builder_exits, alongside the existing deposits/withdrawals/consolidations.

blob_kzg_commitments moves into the builder’s bid, where it is a commitment, not proof that the blobs were published: the builder may never reveal the payload, the PTC may vote the blob data unavailable, or the next block may not build on it. Before Gloas, a block was only valid if its blobs were available, so raw.blocks.blob_kzg_commitments meant “blobs that landed”. To keep that meaning, the column is NULL after the fork rather than filled from the bid. The bid’s commitments are in beacon.raw.execution_payload_bids.blob_kzg_commitments; to count blobs that landed, join to beacon.raw.payload_attestations or beacon.raw.execution_payload_envelopes.

Migration Path: eth1_*, transaction_count, withdrawal_count and withdrawals stay populated, so no query changes are needed for those columns. Read blob commitments from beacon.raw.execution_payload_bids instead of raw.blocks. For builder and bid information (builder identity, bid value, gas limit), use beacon.raw.execution_payload_bids, a view over the new signed_execution_payload_bid column.

`beacon.raw.block_rewards` — No Changes

block_rewards comes from the Beacon API rewards endpoint, which has no Gloas fields, and gets no new columns. total remains the proposer’s consensus-layer reward. The builder’s payment to the proposer is in beacon.raw.execution_payload_bids: value (paid through the beacon chain) and execution_payment (paid at the execution layer). At most one of the two is non-zero; both are 0 when the proposer built the payload itself (builder_index 18446744073709551615). Join on slot_number.

`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 and Views

Tables built from fields of the beacon block are views over raw.blocks, like raw.attestations and raw.deposits. Only data from other Beacon API endpoints is ingested into its own table.

Name	Kind	Source
`beacon.raw.execution_payload_bids`	View	`raw.blocks.signed_execution_payload_bid`
`beacon.raw.payload_attestations`	View	`raw.blocks.payload_attestations`
`beacon.raw.execution_requests`	View	`raw.blocks.execution_requests` (pre-Gloas), `raw.execution_payload_envelopes` (Gloas)
`beacon.raw.execution_payload_envelopes`	Table	Execution payload envelope endpoint
`beacon.raw.builders`	Table	Beacon state builder registry, once per epoch

`beacon.raw.execution_payload_bids`

Provides one row per Gloas block with the builder’s committed bid from the beacon block body. A view over raw.blocks.signed_execution_payload_bid. Use this table for builder information and builder payments for post-Glamsterdam slots. Unique Key: slot_number

Column	Type	Description
`slot_number`	bigint	Beacon slot number
`slot_timestamp`	timestamp	Slot timestamp
`builder_index`	number(38,0)	Index into `beacon.raw.builders` — not a validator index. 18446744073709551615 means the proposer built the payload itself
`value`	varchar	Amount in Gwei the builder pays the proposer through the beacon chain
`execution_payment`	varchar	Amount in Gwei the builder pays the proposer at the 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`	number(38,0)	Proposed gas limit
`fee_recipient`	varchar	Fee recipient address
`blob_kzg_commitments`	variant	Blob KZG commitments the builder committed to in the bid. A commitment, not proof the blobs were published
`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. A view over raw.blocks.payload_attestations. Unique Key: (slot_number, array_index) — 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
`array_index`	bigint	Position of the attestation in the block
`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.builders`

Provides a per-epoch 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 (first slot of the epoch)
`slot_timestamp`	timestamp	Slot timestamp
`builder_index`	number(38,0)	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`	float	Builder balance in ETH
`raw_balance`	varchar	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). A slot whose builder never revealed its payload has no row. 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`	number(38,0)	Index into `beacon.raw.builders`
`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. A view: pre-Gloas (Electra and later) rows come from raw.blocks.execution_requests, Gloas rows from raw.execution_payload_envelopes. 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 (NULL before Gloas)
`builder_exits`	variant	NEW — builder exit requests (NULL before Gloas)

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 `value` and `execution_payment` in `beacon.raw.execution_payload_bids`	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.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 — 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 15, 2026 — see Devnet Progress Updates for change history.

EVM

​Devnet Progress Updates

​What Is Changing

​Key Change: Block Body Structure

​Impact to Allium Tables

​beacon.raw.blocks — Breaking Changes

​beacon.raw.block_rewards — No Changes

​beacon.validator.consensus_income — No Changes

​New Tables and Views

​beacon.raw.execution_payload_bids

​beacon.raw.payload_attestations

​beacon.raw.builders

​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` — No Changes

`beacon.validator.consensus_income` — No Changes

New Tables and Views

`beacon.raw.execution_payload_bids`

`beacon.raw.payload_attestations`

`beacon.raw.builders`

`beacon.raw.execution_payload_envelopes`

`beacon.raw.execution_requests`

Migration Timeline

Action Items

Additional Notes

EIP-7928 (Block-level Access Lists)

Reference Documentation

Support