Glamsterdam: A First Look at Ethereum's Next Upgrade

At a glance:

• Timing: planned for H2 2026. No block height or testnet activation dates are set in the Meta EIP yet. Treat all operational planning as provisional until validator client software is released and public testnet forks are announced.
  
  
• The confirmed headliners: enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928). The first reshapes how blocks are built; the second prepares the network for larger blocks.
  
  
• For stakers specifically: EIP-8061, which raises the exit and consolidation churn limits, is now scheduled for inclusion. It is the change that bears most directly on staking.
  
  
• On rewards: base issuance does not change. Some reward-distribution mechanics may shift. There is no credible "+X% APR" number to attach to this upgrade, and we would treat any that circulates with caution.
  
  
• What our clients need to do: nothing. Twinstake manages the transition.

‍

The next stage for Ethereum

Later this year, Ethereum is expected to undergo its next major upgrade, Glamsterdam. It pairs a consensus-layer upgrade (Gloas) with an execution-layer upgrade (Amsterdam), and it is being planned for the second half of 2026. Activation dates are not yet set.

Glamsterdam is a large upgrade, and most of it is about network performance rather than staking. Here we’ll take a first look at the changes that matter to institutional stakers: what is confirmed, what is still under discussion, and what Twinstake is doing to prepare. This piece is being kept relatively high-level, as a full technical report from our engineering team will follow in the same vein as our previous Pectra report, once the remaining details firm up.

‍

Important note: Ethereum upgrades move between "considered" and "confirmed" as core developers finalise the bundle. Everything covered here is currently listed as scheduled for inclusion in the Glamsterdam Meta EIP, though scope can still shift before activation.

What is actually changing

Two changes anchor the upgrade, and both are confirmed. We take each in turn, starting with the one that bears most directly on validators.

Enshrined proposer-builder separation (EIP-7732)

 SCHEDULED  

Today, validators that outsource block building rely on software sitting alongside the validator, connected to relays. It works, and it is widely used, but it depends on trust: validators trust relays to release blocks on time, and builders trust relays not to exploit their access.

Glamsterdam brings this arrangement into the protocol. Builders become a protocol-visible role that stakes and is tracked in the beacon state, and the relay no longer has to be trusted to escrow payment correctly. The practical effect for validators is that consensus voting and execution-payload validation stop being compressed into the same short window: the proposer commits to a signed builder bid first, the payload is revealed shortly after, and execution validation gets more of the slot.

This is the validator-relevant headliner of the upgrade, and the one worth understanding first. The full mechanics, including the new bid flow and what it means for how we select builders, are the subject of the technical report to follow.

‍

‍

What it means for stakers

Two things change for stakers: how blocks get built, and how block-building revenue reaches them.

Block building becomes a trust-minimised market

Removing the trusted relay from the critical path changes the operational trust assumptions behind block production. Over time, a more competitive, less trust-dependent builder market could improve the execution-layer component of staking rewards. It is difficult to put a number on that yet: the effect depends on how the new market develops and how many builders participate. Twinstake will be selecting and monitoring builders on our clients' behalf, and that the existing setup keeps working through the transition.

Rewards: distribution mechanics, not base issuance

Consensus issuance does not change under Glamsterdam. Attestation, proposal, and sync-committee economics stay structurally the same unless a separate reward proposal changes them. What moves is execution and block-building revenue: the path that value takes, not the amount the protocol issues.

‍

The honest line on rewards

Expect reward-distribution mechanics to change, not base issuance. There is no credible "+X% APR" estimate for this upgrade, and Glamsterdam should not be described as an APR upgrade. If a specific reward uplift number appears in external commentary, treat it as speculation until the builder market exists and can be measured.

‍

Block-level access lists (EIP-7928)

 SCHEDULED  

Block-level access lists let nodes see, up front, which accounts and storage a block will touch. That enables parallel disk reads, faster validation, and safer movement toward larger blocks. A companion repricing proposal keeps larger blocks from translating into uncontrolled state growth.

This is a network-capacity change rather than a staking change. It matters because it is what makes higher throughput safe, but it does not alter staking mechanics directly. We include it because it is one of the two confirmed headliners, and because "bigger blocks, safely" is the honest one-line summary of the execution side of Glamsterdam.

‍

Exit and validator-set changes

Alongside the two headliners, changes to exit throughput and validator-set operations have now been scheduled for inclusion:

  SCHEDULED   

• EIP-8061 raises the exit and consolidation churn limits. The exit churn limit was always a dynamic value that had been capped; this change removes that cap while keeping the underlying calculation, restoring more proportional exit throughput.
• EIP-8045 excludes slashed validators from proposer selection. A smaller change, relevant to validator-set hygiene, and now scoped to proposer duties within the look-ahead window only.

For institutions, the relevance is exit-time predictability and large-position planning. The exact figures scale with total staked ETH, so the numbers at the fork will differ from any calculated today. We will cover this properly in the technical report.

‍

What Twinstake is doing

Our readiness for Glamsterdam is straightforward, and most of it sits with us rather than with clients.

• On the validator side, we adopt the upgrade. Being ready means running the updated clients through public testnet activations and into mainnet, which is our standard upgrade process.
• On block building, we adopt a builder-selection strategy. In the near term we expect to keep using a relay while the new in-protocol market matures, then adjust as it does.
• Operationally, we update our internal tooling, including our exit calculator, so that any changes to exit behaviour are reflected the moment they are confirmed.

‍

What Twinstake clients need to do

Twinstake manages the transition of our validator infrastructure on clients' behalf. If Glamsterdam changes how you want to think about exit planning once the exit changes take effect, we are happy to discuss the technical changes in more depth and help model these scenarios.

‍

What comes next

Glamsterdam is still taking shape. The headline changes and the exit churn increase are confirmed, but the activation timeline will only firm up as validator client software is released and public testnet forks are announced.

Our engineering team is preparing a full technical report on the upgrade, covering the block-building changes and the exit and validator-set proposals in the depth institutional teams need.

In the meantime, if Glamsterdam raises questions for your own planning, get in touch at info@twinstake.io.

‍

Disclaimer

‍Twinstake does not provide staking services to retail customers. This blog post is not intended as a promotion, offer, invitation or solicitation for the purchase or sale of any investment, nor is it intended to give rise to any other legal relations whatsoever and must not be relied upon for the purposes of any investment decision. It does not constitute financial, legal, or investment advice. If you do not have the relevant professional experience in matters relating to crypto asset investments, you should not consider this blog post to be directed at you.

‍This blog post and the information in it are not directed at, or intended to be made available to, retail customers. It is directed only at persons who are professional investors (for the purposes of the Alternative Investment Fund Managers Directive (2011/61/EU) (known as 'AIFMD'); professional clients or eligible counterparties for the purposes of the Markets in Financial Instruments Directive II (Directive 2014/65/EU) (known as 'MiFID II'); if you are in the UK, to "Investment Professionals" or "High Net Worth Companies" as defined in Articles 19 and 49 respectively of the Financial Services and Markets Act 2000 (Financial Promotion) Order 2005, or as otherwise defined under applicable local regulations and at whom this blog post and the information in it may lawfully be directed in any relevant jurisdiction.

‍The analysis in this blog post reflects the proposals as specified and the information available at the time of publication. Both proposals remain subject to governance, technical review, implementation and activation, and their specifications, timing and economic effects may change. This blog post will not necessarily be updated to reflect subsequent developments.

‍The appearance of any third-party hyperlinks or third-party references in this blog post does not constitute an endorsement, guarantee, warranty, or recommendation by Twinstake. Do conduct your own due diligence before deciding to use any third-party services.

‍Twinstake shall have no liability for any loss or damage that may arise directly or indirectly from the use of or reliance on the information provided herein or for any errors or omissions in the information.

‍

‍