Ethereum activates Glamsterdam on Sepolia on October 6. Solana’s Alpenglow is live on testnet. Both upgrades rewrite consensus-layer mechanics in the same month. This report compares both changes with data.
What Is Glamsterdam
Glamsterdam is Ethereum’s next hard fork, scheduled for Q4 2026 mainnet. It combines two layer upgrades: Amsterdam (execution) and Gloas (consensus). The Ethereum Foundation confirmed the Sepolia testnet activation at epoch 353,024, slot 11,296,768, on October 6 at 13:53:36 UTC.
The upgrade is tracked under Meta EIP-7773. It includes ten EIPs across consensus and execution layers. The two headline proposals are EIP-7732 and EIP-7928. These two EIPs work as an interlocked pair.
EIP-7732: Enshrined Proposer-Builder Separation
Today, over 90% of Ethereum blocks are built by external MEV-Boost relays. The top four builders account for over 90% of all blocks (HHI score: 3,892). These relays operate entirely off-chain with no protocol accountability.
EIP-7732 writes the proposer-builder split into the consensus protocol directly. A builder becomes a staked consensus-layer actor. The proposer commits to a builder’s bid. The builder reveals the payload afterwards. A new payload timeliness committee (PTC) attests whether the data arrived on time.
ePBS also expands the data propagation window from 2 seconds to approximately 9 seconds. This allows larger blocks and more blob capacity per slot without breaching the 12-second slot deadline.
EIP-7928: Block-Level Access Lists
As shown in the chart, Ethereum’s daily gas consumption has historically grown in discrete steps alongside block gas limit increases, hovering around 215–220 billion gas per day in 2026. EIP-7928 enables three concrete execution changes to safely push this capacity higher: parallel disk reads across CPU cores, parallel transaction validation, and executionless state reconstruction for light clients. Together, these optimizations make scaling to a 200M gas limit safe on standard validator hardware.
Without EIP-7928, tripling the gas limit beyond current daily levels would impose proportionally higher sequential execution overhead per validator. Devnet-11 successfully ran 84,000 simulated validators at 200M gas without a finality failure, paving the way for the Sepolia testnet activation on October 6.
Gas Pricing Changes: EIP-8037 and EIP-8038
Glamsterdam reprices two categories of state access. EIP-8037 raises the cost of creating new state entries. EIP-8038 updates the cost of reading existing state. The repricing aligns gas costs closer to actual hardware resource usage. Application developers must test contracts against the new rules before mainnet.
Glamsterdam Activation Schedule
| Network | Date | Status | Notes |
| Sepolia testnet | Oct 6, 2026 (13:53:36) UTC | Confirmed | Epoch 353,024 / Slot 11,296,768 |
| Hoodi testnet | Oct 27, 2026 (tentative) | Not confirmed | Contingent on Sepolia stability |
| Mainnet | Q4 2026 (no date) | Not confirmed | Separate announcement pending |
Arbitrum Sepolia operators must upgrade to Nitro v3.11.4 before October 6. Glamsterdam adds new fields to Ethereum block headers. Batches estimated before the fork and included after it may fail under the new gas rules.
Prysm 7.2.0 defaults to a 60M gas limit after activation. Validators targeting 200M must set it manually via a version 2 proposer settings file or the keymanager API. The ‘suggested-gas-limit’ flag has no effect after the Gloas fork.
What Is Alpenglow
Alpenglow is Solana’s largest protocol change since launch. It replaces TowerBFT, which is the existing consensus mechanism with a two-component system called Votor and Rotor. The upgrade passed validator governance vote (SIMD-0326) in September 2025 with 98.27% approval and 52% of staked tokens participating.
Alpenglow activated on the dedicated community test cluster and then testnet in the final week of September 2026. Mainnet activation arrives with Agave 4.3, targeted for October 2026 with no confirmed block height.
Phase 1: Votor
Under Solana’s legacy TowerBFT consensus, the network pays a heavy performance penalty: every single validator vote must be processed and submitted as a standard on-chain transaction. These consensus housekeeping votes routinely clog the ledger and consume massive amounts of block space. Academic transaction tracking from early 2024 through Q1 2026 (per the graoh) confirms that vote transactions (pink) consistently made up an average of 71.5% and up to roughly 75% of total transactions on Solana, artificially inflating throughput metrics.
Votor eliminates this structural overhead by taking vote transactions completely off-chain. Validators exchange direct BLS signature certificates peer-to-peer off-chain, submitting a single aggregate certificate of approximately 1,000 bytes to the chain per block instead of millions of individual vote transactions. This structurally frees up over 70% of current block capacity for real user transactions.
To achieve this, Votor runs two concurrent finalization paths: a fast-path condition where blocks finalize in a single voting round, and a slow-path condition where a second round completes finalization if fewer validators respond within the window. The combined target is 100 to 150 milliseconds of economic finality which implies a 99% reduction in wait time compared to the current 12.8 seconds.
Fault Tolerance: From 33% to 20+20
TowerBFT requires more than two-thirds of stake (67%) to be honest and online for consensus to proceed. A network where 34% of validators are adversarial causes TowerBFT to stall.
Votor changes the fault model. It tolerates up to 20% adversarial stake plus 20% offline stake simultaneously which means a 40% combined crash-failure resilience. The trade-off is a tighter Byzantine adversarial threshold (33% down to 20%). By tightening that threshold, Votor can finalize in a single round rather than two, which is what produces the 150ms target.
The safety proof underpinning Votor was developed by Anza in collaboration with ETH Zurich researchers. It is formally verified, not simulation-based, unlike TowerBFT’s empirical safety model.
Phase 2: Rotor
Rotor replaces Turbine, Solana’s current block data propagation protocol. Turbine uses a multi-hop tree of nodes to distribute block data across validators. Rotor replaces the tree with a single relay layer, cutting propagation hops. Rotor has no confirmed activation date and is not part of the Agave 4.3 release.
Side-by-Side Comparison
| Dimension | Ethereum Glamsterdam | Solana Alpenglow (Votor) |
| Upgrade type | Hard fork (coordinated cut-over) | Feature gate (stake supermajority) |
| Testnet date | Sepolia Oct 6 (confirmed) | Testnet live Sep 24-25 (confirmed) |
| Mainnet date | Q4 2026 (no confirmed date) | Agave 4.3 (tentatively October, but no clear date) |
| Finality change | None -by this update | 12.8s to 100-150ms (99% reduction) |
| Throughput change | 60M to 200M gas/block (3.3x) | 75% block space freed from vote txns |
| Relay/trust change | 90%+ of blocks off off-chain relays | No relay change |
| Fault tolerance | Unchanged (33% adversarial max) | 20% adversarial + 20% offline |
| Safety proof type | Simulation and empirical testing | Formally verified (ETH Zurich) |
| Fee impact | ETH transfers projected 71% cheaper | Vote fee savings approx. 0.56 SOL per epoch |
| Phase 2 scheduled | Hoodi testnet Oct 27 (tentative) | Rotor ( no confirmed date) |
| What it does NOT fix | Finality speed. L2 trust assumptions. | Raw throughput. Block propagation. |
Key Differences in Approach
As per current live network data from Chainspect highlights a stark contrast in baseline economic finality: Solana currently takes 12.8 seconds to achieve full finalized status under TowerBFT, while Ethereum requires 12 minutes and 48 seconds.
Alpenglow directly addresses this gap for Solana, using Votor to collapse that 12.8-second delay down to 100–150 milliseconds in fast-path consensus conditions. It achieves this by eliminating vote transactions, which currently consume up to 75% of Solana’s block space by indirectly freeing up massive capacity for user transactions without directly raising raw transaction throughput on its own.
In contrast, Glamsterdam leaves Ethereum’s 12m 48s finality unchanged, focusing instead on scaling single-block execution capacity from 60M to 200M gas. By making blocks safer to build larger and execute in parallel, Glamsterdam delivers a 3.3x gas limit expansion to expand block space.
Ultimately, neither upgrade solves the problem the other targets: Ethereum’s multi-epoch finality remains untouched, and Solana’s core transaction engine relies on Votor for speed, not raw execution scaling. These distinct metrics illustrate how each network prioritizes its core constraint through parallel solutions, Ethereum expands block space capacity, while Solana targets sub-second settlement.
What to Watch in October
For Ethereum: Sepolia data from October 6 onward will show whether Devnet-11’s 200M gas benchmark holds under real validator conditions. The Hoodi testnet activation (tentatively October 27) is the next fixed milestone before mainnet is announced.
For Solana: Agave 4.3 has no confirmed release date. Mainnet remains on TowerBFT as of October 5. The sequence is: Agave 4.3 release, validator upgrades, feature gate activation by supermajority. No single activation block number exists to monitor in advance.