Ethereum Glamsterdam Upgrade: What Builders Need to Know (and Do)

For the past couple of years, every major Ethereum upgrade has felt like a love letter to Layer 2 networks. We got blobs, we slashed rollup fees, and we told everyone to migrate their execution to L2.

The upcoming Glamsterdam upgrade, targeted for later this year, is different. This time, the focus shifts squarely back to Layer 1 scaling.

Glamsterdam, which combines the execution layer upgrade Amsterdam and the consensus layer upgrade Gloas, is designed to shake up how Ethereum processes transactions, builds blocks, and prices resources. It represents a massive step toward parallel execution on the base layer.

Here is the breakdown of what is actually changing under the hood, how it impacts your dApps, and what you need to do to prepare.

The Big Shift: Parallel Execution and ePBS

The core bottleneck of Ethereum has always been its sequential execution engine. Think of it like a grocery store checkout with a single lane. Every transaction, no matter how simple or complex, has to wait its turn in a single file line.

Glamsterdam introduces two massive architectural changes to build a multi lane highway directly on Layer 1.

Block Level Access Lists (EIP 7928)

To process transactions in parallel, the network needs to know which transactions might conflict with each other. If Transaction A and Transaction B are trying to update the exact same Uniswap pool, they cannot be run at the same time. But if Transaction A is swapping tokens on Uniswap and Transaction B is minting an NFT on an entirely separate contract, there is no reason to run them sequentially.

EIP 7928 introduces Block Level Access Lists (BALs). Blocks will now include a pre declared map in their header showing exactly which accounts and storage slots will be accessed during execution.

This is a game changer for validator clients. Instead of discovering what state a transaction needs during execution, nodes can read the block level access list and pre fetch the necessary data from disk into memory. By turning sequential disk reads into parallel memory lookups, Glamsterdam targets a massive gas limit increase, moving from the current 60 million up toward 200 million gas per block. This could push Layer 1 throughput past thousands of transactions per second during peak times.

Enshrined Proposer Builder Separation (EIP 7732)

Today, Proposer Builder Separation (PBS) relies heavily on third party relays like MEV Boost. This off chain setup is fragile and places tight timing constraints on block production.

EIP 7732 integrates this process directly into the Ethereum consensus protocol, a concept called enshrinement. Under enshrined PBS (ePBS), the network officially recognizes the separate roles of block builders and proposers.

The immediate benefit for developers and node operators is that ePBS extends the window for validating blocks. Instead of squeezing execution payload processing into a tiny two second window, nodes now have much more time to handle larger blocks and verify data. This structural change gives Ethereum the breathing room to scale base layer capacity safely without forcing validator hardware requirements to skyrocket.

The Glamsterdam Panic Meter (Is your contract going to break?)

When hard forks happen, developers usually experience a brief moment of existential dread. Will my smart contracts break? Do I need to rewrite my entire frontend? Let us evaluate the actual risk factors with a quick panic index.

1. "Will my deployed contracts stop working?"

Panic Rating: 1/10 (Relax)

The Reality: The Ethereum Virtual Machine (EVM) maintains exceptionally strict backward compatibility. Your existing Solidity code will run exactly as it did before.

2. "Will gas costs change for my dApp?"

Panic Rating: 6/10 (Pay Attention)

The Reality: Glamsterdam introduces gas repricing under proposals like EIP 8037. The goal is to charge users for the actual long term resources they occupy on the network. Consequently, computation heavy transactions will become relatively cheaper, but state intensive transactions, such as deploying complex new smart contracts or creating new accounts, will become more expensive. If your dApp relies on deploying clones of contracts frequently, you should budget for higher deployment costs.

3. "Do I need to change how I estimate gas?"

Panic Rating: 4/10 (Expect Updates)

The Reality: Because access lists are now determined at the block level, wallet software and RPC providers will have to update how they calculate and present gas estimates to users. You will likely need to update your client side libraries to the latest versions to avoid failed transactions due to inaccurate gas limits.

The Unsung Hero: Native ETH Logs (EIP 7708)

While parallel processing and ePBS get all the attention, there is a smaller proposal in the Glamsterdam package that will make web3 developers incredibly happy. EIP 7708 changes how simple ETH transfers work on the protocol level.

Historically, ERC20 token transfers emitted a standard Transfer log, making them easy to track, index, and display in block explorers or user dashboards. Standard ETH transfers, however, did not emit logs naturally. If you wanted to track when raw ETH moved between addresses, you had to rely on tracing internal transactions, which is computationally expensive and slow.

EIP 7708 forces the protocol to emit a native log whenever an ETH transfer occurs. This is a massive win for tooling, indexing, and observability. It means indexing services can monitor native ETH movements using the same simple log subscription models they use for ERC20 tokens.

What Developers Need to Do Today

You do not need to rewrite your dApps, but you should not just sit on your hands until Glamsterdam hits mainnet. Here is your checklist.

Audit your gas profiles: Since EIP 8037 will adjust the cost of state creation vs computation, run your smart contract test suites on local environments with the new gas parameters. Identify any functions that write heavily to new storage slots and evaluate if you can optimize them to save your users money.

Test on public devnets: Do not wait for the mainnet launch. Use developer networks like Sepolia or the newer Hoodi testnet to deploy and interact with your contracts. Connecting your development tools, such as Hardhat or Foundry, to public devnets via a node provider like Tatum will allow you to see exactly how your application behaves under the new rules.

Update your client dependencies: Ensure your web3 libraries, node configurations, and wallet integrations are updated as client teams release stable updates for Glamsterdam compatibility.

By taking the time to test on devnets today, you can ensure your application transitions seamlessly when Ethereum shifts into its high performance parallel era.