> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Schema Changes: Glamsterdam ePBS Upgrade

> Breaking schema changes to beacon.raw.blocks and beacon_hoodi.raw.blocks due to EIP-7732 (Enshrined Proposer-Builder Separation)

<Warning>
  **Breaking Schema Changes**

  Ethereum'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.
</Warning>

## 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](https://forkcast.org/upgrade/glamsterdam).

<AccordionGroup>
  <Accordion title="September 9, 2026">
    Pending — no verified update yet. The last confirmed status is the July 10, 2026 entry below; check back or see [Forkcast](https://forkcast.org/upgrade/glamsterdam) for the latest devnet number and client readiness before relying on this page for current status.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## 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:

```json theme={null}
{
  "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:

```json theme={null}
{
  "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.

<Note>
  `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`.
</Note>

<Info>
  **Why This Matters**

  ePBS 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.
</Info>

## 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                                                |

<Note>
  `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](#new-tables). The `ExecutionRequests` schema also grows two new request types in Gloas, `builder_deposits` and `builder_exits`, alongside the existing deposits/withdrawals/consolidations.
</Note>

**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  |

<Warning>
  **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.
</Warning>

### `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](#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                                                          |

<Info>
  **Additive-First Strategy**

  Allium 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.
</Info>

## 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                          |

<Note>
  Deadlines are keyed to devnet/testnet/mainnet milestones rather than fixed calendar dates — see [Devnet Progress Updates](#devnet-progress-updates) for the current schedule, since Glamsterdam has slipped past its original April/May 2026 estimates.
</Note>

## 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

* [Ethereum Consensus Specs - Gloas (Glamsterdam)](https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/beacon-chain.md)
* [EIP-7732: Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732)

### 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](#devnet-progress-updates) for change history.*