Glamsterdam Upgrade: What Changes for RPC Users

Glamsterdam is the next Ethereum hard fork. Its name joins Amsterdam (the execution layer upgrade) and Gloas (the consensus layer upgrade), and its two headline changes are enshrined proposer-builder separation (ePBS, EIP-7732) and block-level access lists (EIP-7928). For anyone calling JSON-RPC the visible changes are small and specific: two new block header fields, new access-list methods, an extra log for every ETH transfer and new gas numbers that change eth_estimateGas results.

Until mainnet forks, none of this changes what mainnet returns. Sepolia already runs the fork, so you can see every change below on a live chain now.

Status on 7 November 2026

Sepolia activated Glamsterdam on 6 October 2026 at 13:53:36 UTC (epoch 353024).

Hoodi was postponed on 22 October 2026 with no new date, according to the Ethereum Foundation, to investigate how EIP-8037 interacts with mainnet smart contracts.

On 6 November 2026 core developers delayed the fork process after ChainSecurity found a few projects that rely on invariants broken by EIP-8037 and EIP-8038. Hoodi will not fork until the issues are resolved.

No mainnet date is set, and ethereum.org says the scope is frozen but can still change before mainnet.

This box is dated on purpose. Everything below describes what the fork does, not when it arrives, so read “when Glamsterdam activates on mainnet” wherever the text talks about the change itself.

What RPC callers will notice

Block headers gain blockAccessListHash and slotNumber.
Two new methods return a block’s access list: eth_getBlockAccessList and debug_getRawBlockAccessList.
The access list itself is not part of the block body.
A slot can have a beacon block with no execution payload, so block number is a weaker clock than it was.
Every nonzero ETH transfer emits a Transfer-shaped log, so receipts and eth_getLogs results grow.
Gas costs change, and eth_estimateGas has to follow them.
The Beacon API gains payload envelope endpoints and a new head_v2 event with a payload_status.

No new transaction type comes with the fork: we read the descriptions of all 18 EIPs scheduled for it and none adds one.

New block header fields

The execution-apis specification adds two properties to the block and header objects, next to requestsHash:

blockAccessListHash (EIP-7928): the Keccak-256 hash of the RLP-encoded block access list.
slotNumber (EIP-7843): the consensus slot as a uint64.

On 7 November 2026 we called eth_getBlockByNumber with ["latest", false] on three BoltRPC chains and compared the keys:

ethereum-sepolia: both fields are there. In block 0xb8613a the slotNumber was 0xafe1be, which is slot 11526590.
ethereum-hoodi: neither field, as expected for a chain that has not forked.
ethereum (mainnet): neither field.

A public Sepolia endpoint returned the same two extra keys in the same call, so this is the fork and not one provider’s quirk.

What to do about it:

Decoders: a strict header decoder or a typed client that rejects unknown keys will meet two new ones. Most JSON decoders ignore extra keys; strict ones do not.
Block hash recomputation: the block hash is the Keccak-256 of the RLP-encoded header, and the EIPs extend the header encoding, so code that recomputes hashes from header fields must add both fields. That is our reading of the EIPs, which say the encoding is extended but do not say “the block hash changes”. Read the field order from the EIP text before you write the encoder.
Simulation: the execution-apis spec says a block from eth_simulateV1 carries every header field a real block carries at the fork active for that block, which includes both new fields after Amsterdam. The one exception: slotNumber is omitted when the parent block has none.

Block-level access lists (EIP-7928)

A block-level access list (BAL) records every account and storage location touched while a block executed, along with the post-execution values. The EIP’s stated purpose is to let nodes read state from disk, validate transactions and compute the state root in parallel.

Three facts matter for RPC callers:

The BAL is not in the block body. The execution layer stores it separately and passes it along in the ExecutionPayload over the Engine API. It is there for nodes, and eth_getBlockByNumber does not return it.
The header carries only its hash. For an empty list the hash is 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347.
Nodes do not keep BALs forever. The EIP requires the execution layer to keep them available over the Engine API for at least 14299 epochs, and says the full bytes may then be pruned.

For JSON-RPC, execution-apis defines two new methods:

eth_getBlockAccessList returns the list decoded into JSON. Every account entry has the same six fields: address, storageChanges, storageReads, balanceChanges, nonceChanges and codeChanges. It returns null for an unknown block or the pending tag. For a block from before the fork it must return error -32001 (Resource not found), and for a pruned list error 4444 (Pruned history unavailable).
debug_getRawBlockAccessList returns the raw RLP bytes. A block with no state accesses returns the empty RLP list 0xc0.

Support depends on the provider. On 7 November 2026 the public PublicNode Sepolia endpoint answered eth_getBlockAccessList with the decoded list and answered debug_getRawBlockAccessList with -32601 (method not available). Do not assume either method exists on an endpoint until you have called it. Test on Sepolia first, and handle -32601, -32001 and 4444 explicitly.

ePBS (EIP-7732)

Today a proposer builds or buys an execution payload and puts it inside the beacon block. With ePBS the ExecutionPayload field leaves the beacon block body. In its place the block carries a signed commitment, a bid, from a builder who promises to reveal a payload later. The bid names the execution block hash, the root of the execution requests and a value to be paid to the proposer. Builders are new staked entities that do not validate the beacon chain.

The slot then runs in three steps:

The beacon block with the builder’s bid arrives at the start of the slot.
The builder reveals the payload, due 50% of the way through the slot.
A 512-member Payload Timeliness Committee (PTC) attests whether the payload arrived on time, due 75% of the way through the slot.

The EIP defines three outcomes for a slot:

Full: the beacon block and its execution payload were both revealed and included.
Skipped: no beacon block, and so no execution payload, was included.
Empty: the beacon block was included but the committed execution payload was not.

An honest builder may withhold the payload when the beacon block holding its bid was late and is not the head in the builder’s view. The EIP pays the proposer whenever its beacon block with the bid was timely, even if the payload never arrives, and a builder whose bid block was revealed late is not charged the bid.

What this likely means for RPC

This part is inference. The EIP text does not mention eth_* methods, latest, safe or finalized, and the only Engine API change it names is support for the new execution request types.

An Empty slot is a beacon block with no execution payload. The execution chain gets no new block for that slot, and the next execution block should point back at the last payload that was revealed. Code that assumes one execution block per slot, or uses block number as a clock, should use slotNumber or timestamps instead.
The execution block for a slot becomes visible when the payload is revealed and imported, around mid-slot, not at the start. The EIP does not say what latest returns between bid and payload.
safe and finalized are defined by the consensus layer and nothing in the EIP changes them. On Sepolia, which already runs the fork, eth_getBlockByNumber with safe and with finalized both returned a block through BoltRPC on 7 November 2026.

We also looked for gaps on Sepolia. On 7 November 2026 at about 11:44 UTC we checked 153 slots, from slot 11526344 to slot 11526496, using public endpoints. Two slots had no execution block, slots 11526358 and 11526378, and for both the beacon node returned 404 for the beacon block and for the payload envelope, so both were Skipped. We saw no Empty slot. A sample that size neither shows nor rules out Empty slots, but the header’s slotNumber is what makes any gap visible.

ETH transfers emit a log (EIP-7708)

Today a plain ETH transfer leaves no log. With EIP-7708, a log identical to a LOG3 is issued for any nonzero-value-transferring transaction to a different account, plus the other cases the EIP lists. The log comes from the address 0xfffffffffffffffffffffffffffffffffffffffe and its first topic is the standard ERC-20 Transfer topic. The EIP says this matches the ERC-20 Transfer event definition.

That has two effects on callers:

Receipts gain extra logs, whether you read them with eth_getTransactionReceipt or eth_getBlockReceipts, and so do eth_getLogs results.
An eth_getLogs filter on the Transfer topic with no address filter will also match these logs. That is the “busy without address” case in our eth_getLogs block range limit measurements, where results are capped sooner than block windows are.

In practice (our inference) an indexer that treats every Transfer log as a token transfer will start recording ETH transfers as transfers from a token contract at that system address. Filter by token contract address, or skip logs from the system address on purpose.

Gas changes and eth_estimateGas

Several scheduled EIPs reprice gas, and EIP-8037, EIP-8038 and EIP-7976 each tell gas estimators to update. EIP-8038 (state-access gas costs) puts it this way:

Wallets using eth_estimateGas MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.

It also says RPC methods such as eth_estimateGas MUST incorporate the new formula in node software. That second part is the node’s job, not yours, but the first part is. The others, one line each:

EIP-8037 (state creation gas): adds a separate state gas reservoir, and the GAS opcode returns only gas_left, excluding the reservoir.
EIP-7976: raises the calldata floor cost to 64/64 gas per byte.
EIP-7981: prices access lists for data.
EIP-2780: splits intrinsic transaction gas by resource. A plain ETH transfer to an existing account stays at 21,000 execution gas.
EIP-7778: block gas accounting no longer includes refunds. Our reading is that header gasUsed can then differ from the sum of what transactions paid in their receipts. The EIP does not say that in those words.
EIP-7954: raises the maximum contract code size from 24 KiB to 64 KiB and initcode from 48 KiB to 128 KiB.
EIP-8246: SELFDESTRUCT no longer burns ETH.

The Ethereum Foundation has warned that replaying historical mainnet transactions under the new schedule showed a small set of smart contracts relying on assumptions it shifts, and that most flagged issues are fixed with a gas-limit increase. Its testnet announcement tells developers that contracts relying on fixed gas stipends, hardcoded gas limits or assumptions about remaining gas may need changes.

So re-estimate gas instead of hardcoding it, add headroom where a failed transaction is costly and test the paths that matter on Sepolia. If you run contracts, the Foundation’s 6 November post asks contract developers and auditors to check whether their projects rely on the eight invariants it describes, and gives glamsterdam@ethereum.org as the contact.

Beacon API changes (Gloas)

The beacon-APIs repository adds these for Gloas:

GET /eth/v1/beacon/execution_payload_envelopes/{block_id} returns the signed execution payload envelope for a block, with a 404 when none exists.
POST /eth/v1/beacon/execution_payload_envelopes publishes an envelope and POST /eth/v1/beacon/execution_payload_bids publishes a bid.
POST /eth/v1/beacon/pool/payload_attestations submits payload attestations.
State endpoints under /eth/v1/beacon/states/{state_id}/: builders, ptc, builder_pending_withdrawals and builder_pending_payments.
Validator endpoints include /eth/v1/validator/duties/ptc/{epoch} and /eth/v1/validator/payload_attestation_data.
The event stream gains execution_payload, execution_payload_gossip, execution_payload_available, execution_payload_bid, payload_attestation_message and head_v2 topics.

A new head_v2 event describes a beacon block and its payload_status, and the old head event is deprecated. The spec says a node should emit a second head_v2 event for the same block when the status moves from empty to full, and before Gloas payload_status must be full. The payload_attributes event drops parent_block_number.

The beacon block body no longer has an execution_payload. It carries signed_execution_payload_bid, payload_attestations and parent_execution_requests instead. The fork version string in responses is gloas.

We checked this on 7 November 2026 through BoltRPC. The Sepolia beacon returned HTTP 200 with "version":"gloas" for the envelope endpoint on head, and its head block reported version gloas. The mainnet beacon returned HTTP 404 for the same path, while /eth/v1/beacon/headers/head on mainnet returned 200, so the route exists and there is simply no envelope yet. The Hoodi beacon head still reported version fulu. For the basics of the REST API, see the Ethereum Beacon Chain API guide.

Test it on Sepolia now

Sepolia already runs the fork, so it is the place to try all of this. One exception on BoltRPC: the Sepolia endpoint does not serve the two access-list methods today. eth_getBlockAccessList and debug_getRawBlockAccessList both answered -32601 on 10 November 2026. The endpoint pattern on BoltRPC is:

https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum-sepolia

The Sepolia network page has the chain details and the Sepolia testnet RPC guide covers setup. Hoodi has not forked, so it cannot stand in for Sepolia here.

The script below checks whether an endpoint’s headers carry the new fields. It uses plain fetch (we ran it on Node 24.19.0) and reads the endpoint from RPC_URL:

// Feature detection: does the block header from this endpoint carry the EIP-7928 field?
// Usage: RPC_URL=https://... node detect-bal.mjs
const url = process.env.RPC_URL ?? 'https://ethereum-rpc.publicnode.com';

const res = await fetch(url, {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_getBlockByNumber',
    params: ['latest', false],
  }),
});
const { result: block, error } = await res.json();
if (error || !block) throw new Error(`RPC error: ${JSON.stringify(error)}`);

const hasBal = typeof block.blockAccessListHash === 'string';
console.log(`block ${parseInt(block.number, 16)}`);
console.log(
  hasBal
    ? `blockAccessListHash present: ${block.blockAccessListHash}`
    : 'blockAccessListHash not present (pre-Amsterdam header)',
);
console.log(`slotNumber ${block.slotNumber !== undefined ? 'present: ' + parseInt(block.slotNumber, 16) : 'not present'}`);

On 7 November 2026 we ran it as written against public endpoints. It printed not present for both fields on Ethereum mainnet and on Hoodi, and blockAccessListHash present with a slotNumber on Sepolia. Only RPC_URL changed between the runs. Point it at your own Sepolia URL to see the same.

Feature-detect like this, never date-check. Test for the field or call the method and handle the error, so the same code works before and after mainnet forks, whenever that is.

FAQ

When does Glamsterdam go live on mainnet?

No mainnet date is set. On 7 November 2026 Glamsterdam was live on Sepolia, the Hoodi activation had been postponed with no new date and core developers had delayed the fork process on 6 November over EIP-8037 and EIP-8038 findings. The scope can also still change before mainnet.

What is ePBS?

Enshrined proposer-builder separation (EIP-7732) moves the builder’s role into the protocol. The beacon block carries a signed bid from a builder instead of the execution payload, and the builder reveals the payload later in the slot. A committee of validators attests whether the payload arrived on time.

What are block-level access lists?

A block-level access list (EIP-7928) records every account and storage location a block touched, with their post-execution values. The block header carries its hash in blockAccessListHash, the list itself travels over the Engine API and not in the block body, and new methods such as eth_getBlockAccessList expose it if your provider serves them.

Do I need to change my RPC code?

Probably not for ordinary reads, and not before mainnet forks. Check four things: header decoders and block hash code (two new fields), eth_getLogs indexers that filter by the Transfer topic without an address (new ETH transfer logs), anything that treats block number as a slot clock (use slotNumber) and hardcoded gas limits (re-estimate with eth_estimateGas).

Can I test Glamsterdam today?

Yes, on Sepolia, which activated the fork on 6 October 2026. Call eth_getBlockByNumber and look for blockAccessListHash and slotNumber, and try eth_getBlockAccessList to see whether your provider serves it. Hoodi has not forked, and mainnet has no date.

Next steps

Read the Ethereum RPC guide for latest, safe and finalized as they work on mainnet today and the Ethereum Beacon Chain API guide for the REST side. The Ethereum network page lists the mainnet endpoint.

BoltRPC serves Ethereum mainnet, Sepolia and Hoodi, plus the beacon API for each of them. Create a key at dashboard.boltrpc.io and run the script above against ethereum-sepolia.

Content is for informational purposes only and does not constitute financial, legal or technical advice. Code examples and configurations are provided as-is. Verify against official documentation and test in your own environment before deploying to production.