Alpenglow vs. Glamsterdam: Comparing Major 2026 Protocol Upgrades

TL;DR

• Alpenglow and Glamsterdam solve different settlement problems: Alpenglow shortens the time until a Solana transaction is irreversible, and Glamsterdam expands how much work each Ethereum block can process.
• Alpenglow replaces the TowerBFT voting system with Votor and targets finality of about 150 ms, down from about 12.8 seconds. Alpenglow has been live on mainnet since October 21, 2026.
• Glamsterdam keeps Ethereum finality at about 12.8 minutes and changes block production through 2 headline upgrades:
  • ePBS (EIP-7732), which writes block building and builder payments into the protocol,
  • block-level access lists (BALs, EIP-7928), which let nodes process transactions in parallel.
• Glamsterdam targets a 200M gas limit floor, up from the 60M default, and EIP-2780 proposes up to 71% lower gas for a standard ETH transfer. The higher limit takes effect on mainnet once enough validators signal for it.
• Glamsterdam activated on the Sepolia test network on October 6, 2026, is scheduled for the Hoodi test network on October 26, 2026, and has no confirmed mainnet date.
• Everstake operates validators on both networks under a non-custodial model and handles client upgrades for institutional clients.

What Problems Do Alpenglow and Glamsterdam Solve for Institutions?

Alpenglow shortens the time before a Solana transaction becomes irreversible. Glamsterdam raises the amount of work each Ethereum block can carry and moves block building into the protocol.

Institutional settlement teams typically assess a network through 3 requirements:

• a defined point after which a transfer is irreversible,
• execution and fees that stay predictable during demand spikes,
• stable network operation through client upgrades and validator outages.

Alpenglow addresses the first requirement, and Glamsterdam addresses the second.

Alpenglow is a consensus upgrade, which means it changes how validators agree on blocks. According to the Solana Foundation Alpenglow page, validators send votes directly to each other and finalize a block in 1 or 2 voting rounds, while the Solana Virtual Machine (SVM) that runs transactions and the fee mechanics stay the same.

Glamsterdam is an L1 scaling upgrade, which means it expands what the Ethereum base chain can process. It has 3 goals on the ethereum.org Glamsterdam roadmap:

• parallel transaction processing,
• larger block capacity through longer data propagation windows,
• fees that reflect the long-term hardware cost of storing new data.

Faster finality reduces the time an institution waits before a transfer counts as settled. Greater execution capacity raises the volume a block can absorb before congestion pushes fees up.

How Do Alpenglow and Glamsterdam Compare at a Glance?

Alpenglow is a finality upgrade live on Solana mainnet since October 21, 2026, and Glamsterdam is an execution and block-production upgrade still in Ethereum testnet rollout.

Criterion	Alpenglow (Solana)	Glamsterdam (Ethereum)
Primary objective	Replace TowerBFT voting to cut time to finality	Scale L1 execution and move block building into the protocol
Consensus and finality	Votor finalizes in 1 or 2 voting rounds; target about 150 ms, down from about 12.8 s	Casper FFG finality kept at about 2 epochs (about 12.8 min)
Throughput and execution capacity	Execution unchanged; vote transactions leave blocks; Rotor propagation upgrade not yet scheduled	BALs prepare parallel execution; ePBS extends block data propagation from 2 s to about 9 s; 200M gas limit floor targeted after the upgrade
Transaction costs	Fee mechanics unchanged	EIP-2780 proposes up to 71% lower gas for a standard ETH transfer between existing accounts; storing and reading state repriced
Validator/operator requirements	Agave-based client v4.3.2; 0.8 SOL per epoch VAT fee paid from the vote account; Firedancer unsupported during migration	Updated execution and consensus clients; staking pools adapt to in-protocol builder payments
Upgrade status and expected deployment	Active on mainnet since October 21, 2026	Live on Sepolia since October 6, 2026; Hoodi on October 26, 2026; mainnet date not set
Institutional use cases	Point-of-sale stablecoin payments, exchange deposits, cross-chain transfers that wait for finality	Tokenized assets, high-volume contract activity, custody reconciliation through ETH transfer logs

When Is a Transaction Final on Solana and Ethereum?

On Solana with Alpenglow, a transaction is final once validators produce a finalization certificate, a bundled set of votes from enough stake to lock the block in, with a target of about 150 ms. On Ethereum, a transaction is final once validators holding at least 2/3 of stake finalize its checkpoint, the first block of an epoch, which typically takes 2 epochs of 32 twelve-second slots each, or about 12.8 minutes, before and after Glamsterdam.

How Alpenglow Changes Finality on Solana

Votor replaces vote transactions, which validators previously posted onchain, with direct validator messages that are aggregated into certificates. A block finalizes in 1 round if at least 80% of stake votes to notarize it, meaning it confirms the block is valid, or in 2 rounds at a 60% stake threshold.

Votor keeps reaching consensus even if up to 20% of the stake acts maliciously or/and another 20% is offline. Under TowerBFT, a block needed votes accumulated over 32 slots to finalize, which took about 12.8 seconds.

The 150 ms measure time to finality. Solana slot time is a separate parameter, cut from 400 ms to 200 ms in 4 stages. This process was completed in October 2026.

Rotor, the second phase of Alpenglow, will replace Turbine, the protocol that spreads block data across validators, and move block propagation from a tree of nodes to one tier of relay nodes. The Solana Foundation lists Rotor for a later release.

What Glamsterdam Changes in Ethereum Block Production

Glamsterdam targets block production and execution efficiency. Ethereum finality continues to run on Casper FFG, while the six-second slot proposal (EIP-7782) was shelved from Glamsterdam.

On Ethereum, the proposer is the validator selected to publish a block. The builder is a specialized party that assembles its transactions. Today, proposers that buy finished blocks from builders do so through third-party relay software such as MEV-Boost, which both sides must trust.

ePBS (EIP-7732) integrates proposer-builder coordination into Ethereum itself, allowing the protocol to enforce the builder’s payment to the proposer.

ePBS also adds a Payload Timeliness Committee (PTC), a group of validators that checks whether the builder delivered the block’s transactions on time. Validators can then vote on the block header and its transactions on separate deadlines, and the window for spreading block data across the network grows from 2 seconds to about 9 seconds.

Block-level access lists (BALs, EIP-7928) record every account and storage location a block touches, together with the values after the transactions run. Nodes can then load data for unrelated transactions in parallel and sync by applying the recorded values.

How Confirmation, Economic Finality, and Practical Settlement Differ

Institutional finality policies typically reference 3 settlement stages:

• Transaction confirmation: the transaction is in a block that validators have voted on (the block can still be reverted in extreme cases).
• Economic finality: validators holding a supermajority of stake have finalized the block, and reverting it would require attackers to control more stake than the protocol is designed to tolerate. On Ethereum, a revert also triggers slashing, a protocol penalty that destroys at least 1/3 of staked ETH.
• Practical settlement point: the moment an institution’s own policy releases funds or credits a client.

Settlement stage	Solana with TowerBFT	Solana with Alpenglow	Ethereum before and after Glamsterdam
Confirmation	confirmed status, about 1 slot, optimistic	confirmed and finalized become 1 status	Block included in a 12 s slot
Finality	finalized status after about 12.8 s	Finalization certificate, target about 150 ms	Finalized checkpoint after about 2 epochs (about 12.8 min)
Finality basis	Votes accumulated across 32 slots	80% of stake in 1 round, or 60% across 2 rounds	2/3 of stake on consecutive checkpoints; a revert costs at least 1/3 of staked ETH through slashing

For a custodian, the practical settlement point on Solana moves from about 12.8 seconds toward the Alpenglow target. Finality policies for Ethereum can keep their 12.8-minute basis after Glamsterdam, since Casper FFG stays in place.

How Do Alpenglow and Glamsterdam Affect Throughput and Transaction Costs?

Alpenglow keeps execution and fees on Solana as they are, while Glamsterdam is designed to raise per-block capacity on Ethereum and reprices gas to match hardware costs. Headline capacity targets on both networks describe design limits, and sustained performance can be measured only on mainnet after activation.

Solana Capacity and Fees Under Alpenglow

Alpenglow removes validator vote transactions from blocks. From October 10 to October 15, 2026, Solana carried about 264 million to 266 million vote transactions per day, against 144 million to 173 million other transactions, according to Solana Compass.

Dashboards that count votes as transactions will report lower transactions per second (TPS) after activation, and the Solana Foundation classifies the drop as an accounting change caused by votes leaving blocks. Institutions that use TPS in vendor due diligence should compare networks on non-vote transactions.

Solana charges a base fee of 5,000 lamports (0.000005 SOL) per signature, plus optional priority fees that rise with demand for the accounts a transaction touches. Alpenglow leaves this fee model in place.

Ethereum Capacity and Fees Under Glamsterdam

Glamsterdam prepares Ethereum for a higher gas limit, the cap on computation per block, through 3 mechanisms:

• BALs let nodes process non-overlapping transactions in parallel.
• ePBS gives the network about 9 seconds to propagate block data.
• Gas repricing (EIP-8037 and EIP-8038) raises fees for creating and reading stored data closer to hardware cost, with a state growth target of 120 GiB per year.

The Ethereum Foundation set a 200M gas limit floor as a post-Glamsterdam target, compared with the 60M default set with the Fusaka upgrade in December 2025. Ethereum validators vote on the mainnet gas limit, so the 200M level takes effect only when enough validators signal for it; the Hoodi test network moves to 200M at activation.

EIP-2780 proposes cutting the intrinsic gas, the fixed base cost every transaction pays, of a standard ETH transfer between existing accounts by up to 71%. The figures in EIP-2780 have been revised more than once, so cost models should use the final specification.

Fee predictability depends on how often blocks reach their capacity limits during demand spikes. Institutions should compare median (p50) and worst-1% (p99) fees and inclusion times over at least 30 days of post-upgrade mainnet data before revising cost models.

What Do Alpenglow and Glamsterdam Require From Validator Operators?

Both upgrades require validators to install new client software before activation, and Alpenglow adds a per-epoch fee and a temporary restriction on which clients can run. Institutions that stake through a provider rely on that provider to complete these steps on time.

Solana Validator Requirements Before Epoch 1064

Solana validators must meet 2 hard requirements before epoch 1064:

1. Run v4.3.2 of an Agave-based client:
   • Agave
   • Jito-Solana
   • Harmonic Salsa
2. Hold at least 0.8 SOL in the vote account above the rent-exempt minimum, the balance an account must keep to stay onchain, to pay the Validator Admission Ticket (VAT, SIMD-0357).

The VAT charges 0.8 SOL per epoch, paid 1 epoch ahead and burned. It replaces vote transaction fees of about 1 SOL per epoch, and a validator whose vote account is short of the fee is excluded from voting and block production in the next epoch.

Firedancer and Frankendancer, independently built Solana clients, are unsupported during the migration, so operators running them must move to an Agave-based client before activation. The Pumpkin’s Pool readiness tracker flagged 45.2% of stake as not ready 2 days before epoch 1064, mostly on Agave 4.3.0 and 4.3.1, according to Solana Compass.

Systems that read Solana block data, such as indexers and explorers, also face 4 changes at activation:

• Vote transactions leave blocks.
• Proof of History ticks, the timing markers inside each slot, leave the data stream.
• The Clock value that onchain programs read as the current time is set by the block producer within bounded limits.
• Geyser real-time data streams tag each event with a bank_id, because 1 slot can hold more than 1 candidate block.

Ethereum Client and Staking Infrastructure Requirements

Ethereum validators run 2 pieces of software from independent teams, an execution client and a consensus client, and Glamsterdam requires updates to both. Operators must run releases whose notes explicitly confirm support for each scheduled activation, and mainnet releases will be announced separately.

Staking pools need architectural updates under ePBS to enable trustless monitoring of builder payments, according to the ethereum.org roadmap.

EIP-8061 lets about 4x more stake exit per period and about 2x more stake merge into larger validators, at current staking levels. It also shortens the weak subjectivity period, the longest a node can stay offline before it needs a recent trusted checkpoint to resync, from about 15.7 days to about 7 days.

What Institutional Staking Teams Should Monitor Before Deployment

Before each activation, staking teams should confirm 5 items with their validator provider:

1. Deployed client versions, checked against the official release tables.
2. Testnet participation on Hoodi for Ethereum and on testnet or devnet for Solana.
3. VAT funding and automated vote account top-ups on Solana.
4. The gas limit the provider’s Ethereum validators will signal after Glamsterdam.
5. Changes to performance reporting, including vote-free transaction counts on Solana.

How Does Everstake Support Institutions Through Both Upgrades?

With years of validator operations on Ethereum and Solana, Everstake has built a track record of operational reliability, maintaining validator infrastructure and supporting network stability without slashing incidents. As both networks advance through major protocol upgrades, Everstake will continue applying its operational experience to client maintenance, upgrade readiness, and reliable validator performance.

Through its non-custodial institutional staking and Validator-as-a-Service offerings, Everstake provides institutions with infrastructure support while they retain control of their keys.

FAQ

Is Alpenglow live on Solana mainnet?

Yes. Alpenglow went live on Solana mainnet on October 21, 2026, in epoch 1064.

When will Glamsterdam activate on Ethereum mainnet?

The Glamsterdam mainnet date has not been set. The upgrade activated on the Sepolia test network on October 6, 2026, and Hoodi activation is scheduled for October 26, 2026.

Does Glamsterdam make Ethereum finality faster?

No, Glamsterdam keeps Ethereum finality at about 2 epochs, or roughly 12.8 minutes. The upgrade targets block production and execution capacity, including a 200M gas limit floor target.

What does Alpenglow require from Solana validators?

Validators must run v4.3.2 of an Agave-based client and fund the vote account for the VAT fee. The VAT charges 0.8 SOL per epoch, paid 1 epoch ahead.

How does Everstake support institutional staking on Ethereum and Solana?

Through non-custodial validator operations, maintaining infrastructure, managing client upgrades, and preparing nodes for major network upgrades while institutions retain control of their keys.