Ethereum's Glamsterdam upgrade is live on Sepolia, and the testnet can now carry blocks with up to 200 million gas. Validators still have to choose that limit, though. A node left on its default settings could keep proposing 60M blocks.
Is Sepolia's 200M Gas Limit Automatic After Glamsterdam?
No, Sepolia's 200M gas limit is not automatic. In the Ethereum Foundation's original setup, Prysm and Teku default to 60M after Glamsterdam activates, and each validator must set 200M explicitly. That opt-in limit is more than three times the roughly 60M block gas limit on Ethereum mainnet today . A late Prysm patch changed the default for many Sepolia operators.
Quick Answer: No. Glamsterdam went live on Sepolia on October 6, 2026. Prysm and Teku shipped with a 60M default, so validators had to set 200M gas themselves. Prysm v7.2.1, an emergency release, later made 200M the Sepolia default. Teku operators still need to set it manually. Mainnet stays near 60M for now.
Glamsterdam activated on Sepolia on October 6, 2026 at 13:53:36 UTC, at epoch 353,024 and slot 11,296,768 . The Ethereum Foundation set this timing in its official Glamsterdam Testnet Announcement. Glamsterdam combines the "Amsterdam" execution-layer changes with the "Gloas" consensus-layer changes. It is the next network upgrade after Fusaka, which reached mainnet on December 3, 2025 .
The gas limit was the detail that caught operators off guard. In Ethereum, a block's gas limit is not set by the protocol. Each block proposer signals it through client settings, so the limit the network actually uses depends on how validators configure their software. The EF's guidance was specific:
- Prysm: set 200M through version-2 proposer settings .
- Teku: pass
--validators-builder-registration-default-gas-limit=200000000. - No action taken: the client proposes blocks at the 60M default, which pulls the network's effective capacity well below the test target.
Shortly before the fork, Prysm released an emergency version, v7.2.1, so that Sepolia validators default to 200M from activation. Without that fix, Prysm operators who had not changed their configuration would have kept building 60M blocks . According to CoinMarketCap Academy, the fork went live with 18 core EIPs plus 7 other EIPs .
Traders should not treat the headline number as a mainnet commitment. Coverage of the first blocks after activation, from KuCoin News, found that sampled blocks used only 26% to 46% of capacity . Glamsterdam has no mainnet date yet, and its final mainnet gas-limit parameters have not been decided.
"Sepolia's 200 million figure is a test target, not a promise," — Crypto Briefing (source: Crypto Briefing)
The rest of this guide covers how validators opt in, what the 18 core EIPs change, why larger blocks are now technically feasible, and what the results could mean for mainnet fees.
How Do Validators Opt In to 200M Gas Blocks?
Validators opt in to 200M gas blocks by changing their consensus client configuration. The fork does not raise the limit on its own. According to the Ethereum Foundation's Glamsterdam testnet announcement, Prysm and Teku both default to 60M gas after activation, and validators must set 200M explicitly . In Prysm, operators use version-2 proposer settings. In Teku, they pass a specific command-line flag. A block producer only proposes larger blocks once that setting is in place, so on Sepolia the network's real capacity depends on how many operators update their configuration.
Each client exposes the setting differently:
- Prysm: Set the gas limit through version-2 proposer settings, which is the per-validator configuration format Prysm uses for proposal preferences .
- Teku: Add the flag
--validators-builder-registration-default-gas-limit=200000000, which sets the default gas limit that validators register with builders .
| Client | Default after Sepolia fork | How to set 200M | Notes |
|---|---|---|---|
| Prysm (before v7.2.1) | 60M | Version-2 proposer settings | Operators who changed nothing would have kept proposing 60M blocks |
| Prysm v7.2.1 | 200M on Sepolia from the fork | No change needed with this release | Emergency release shipped just before activation |
| Teku | 60M | --validators-builder-registration-default-gas-limit=200000000 | The EF announcement says the value must be set explicitly |
| Other clients | Not specified in the sources reviewed | Check the client's own release notes | Our research did not confirm per-client defaults beyond Prysm and Teku |
Sources: Ethereum Foundation ; KuCoin News .
The Prysm release shows why configuration matters. Just before the October 6, 2026 fork, Prysm shipped an emergency release, v7.2.1, so that Sepolia validators would default to 200M gas from the fork. Without it, Prysm operators who had not touched their settings would have kept proposing 60M blocks, and those blocks would have counted against the network's effective capacity . CoinMarketCap Academy also covered the last-minute fix in its fork-day report .
The main lesson for traders and node operators is that client configuration decides the gas limit validators actually use. The protocol rules alone do not. Ethereum's gas limit is set by block producers, and each producer signals its preferred limit through its client. A protocol upgrade can make larger blocks safe to propagate and validate, but the limit only rises when enough validators run software that asks for more. The same issue will apply on mainnet: any increase will depend on client defaults and operator choices, not only on the upgrade itself.
For anyone tracking Sepolia data, this means block capacity can vary in the first days after the fork, depending on which clients and versions validators run. Operators testing on Sepolia should check their client version and their gas-limit setting before reading too much into early block sizes.
What Do the 18 Core EIPs in Glamsterdam Actually Change?
Glamsterdam has 18 core Ethereum Improvement Proposals (EIPs) . Two of them change the most. EIP-7732 builds proposer-builder separation into the protocol. EIP-7928 adds block-level access lists, which let clients load state and validate transactions in parallel. Most of the other core EIPs reprice gas or refine how the execution and consensus layers work, according to the Ethereum Foundation's Glamsterdam testnet announcement. Taken together, these changes are what make a gas limit far above 60M realistic. They also change gas costs that smart contracts rely on, so developers should re-test against the new rules.
The upgrade's name joins two parts. "Amsterdam" is the set of execution-layer changes, and "Gloas" is the set of consensus-layer changes. Glamsterdam follows Fusaka, which reached mainnet on December 3, 2025 . The Ethereum Foundation (EF) lists these 18 core EIPs :
- EIP-2780, EIP-7688, EIP-7708, EIP-7732, EIP-7778, EIP-7843
- EIP-7928, EIP-7954, EIP-7976, EIP-7981, EIP-7997, EIP-8024
- EIP-8037, EIP-8038, EIP-8045, EIP-8061, EIP-8246, EIP-8282
Ethereum core contributor Pooja Ranjan said the Sepolia fork went live "with 18 Core + 7 Other EIPs," according to CoinMarketCap Academy . The research for this article does not identify those 7 other EIPs, so this article does not list them. Readers who need the full list should check the client release notes and the EF's own documentation.
Some older coverage gives a smaller scope. A mid-September video explainer said only EIP-7732 and EIP-7928 were confirmed (video: FatheryFinds). That reflected an earlier stage of planning. The final Sepolia fork shipped all 18 core EIPs listed above, so any summary that describes Glamsterdam as a two-EIP upgrade is out of date.
EIP-7732: enshrined proposer-builder separation (ePBS). Proposer-builder separation is the division of work between the validator who proposes a block and the specialized builder who puts its transactions together. Today that split depends on outside relay software. ePBS moves it into the protocol and separates consensus validation from execution validation. Everstake says this extends the payload propagation window to about 9 seconds . The extra time lets validators receive and check larger blocks before they have to attest to them.
EIP-7928: block-level access lists (BALs). A block-level access list records every account and storage slot that a block touches. With that list in hand, clients can load the needed state ahead of time and validate transactions in parallel instead of one after another . This is why validation time can stay manageable as blocks grow. Without parallel execution, a 200M-gas block would take roughly three times longer to process on the same hardware.
EIP-8037 and EIP-8038: gas repricing. These two EIPs change what different actions cost. Everstake says EIP-8037 raises the cost of creating new state, such as deploying contracts and writing to new storage slots, to slow the long-term growth of state ("state bloat") . Secondary coverage says EIP-8038 updates gas costs for reading and accessing state . The EF tells developers to test their contracts and gas estimation against the new rules . Hard-coded gas values that were safe under Fusaka may not be safe after Glamsterdam.
| Headline EIP | What it does | Who is affected |
|---|---|---|
| EIP-7732 (ePBS) | Moves the proposer/builder split into the protocol and lengthens the payload propagation window to about 9 seconds | Validators, block builders, relay operators, MEV searchers |
| EIP-7928 (BALs) | Records the accounts and storage slots each block touches, so clients can load state and validate in parallel | Client teams, node operators, validators running larger blocks |
| EIP-8037 | Raises the gas cost of creating new state (contract deployments, new storage slots) | Contract deployers, dApps that create many storage slots, token launchers |
| EIP-8038 | Updates gas costs for accessing state (based on secondary coverage) | Smart contract developers, wallets and tools that estimate gas |
For traders, the main takeaway is that Glamsterdam both adds capacity and changes prices. ePBS and BALs make bigger blocks possible. The repricing EIPs change which actions get cheaper and which get more expensive. These changes do not move fees on their own, though. On Sepolia, the 200M gas limit takes effect only when validators set it in their clients .
Why Are 200M-Gas Blocks Feasible Now When 40M Worried Researchers?
200M-gas blocks are feasible now because Glamsterdam changes how blocks are checked and passed around the network, which was the problem that kept limits low. In 2025, researchers warned of block propagation problems above about 40M gas . ePBS gives validators a much longer window to receive each block's contents, and block-level access lists let clients check transactions in parallel. Together, these changes remove the timing limit that capped earlier increases.
The history explains why caution was the default. Raising the gas limit on mainnet has always been slow and contested. A validator signal in February 2025 only narrowly approved a move from 30M to 32M gas. The limit then reached 60M later in 2025 , according to KuCoin News. Under the old design, a block had to reach validators across the world and be fully executed within a few seconds of the slot. If a block is too large, slower nodes miss the deadline. That causes missed attestations and reorgs, and it puts home stakers at a disadvantage compared with well-connected operators. The roughly 40M warning level reflected that limit on propagation and execution time, not a limit on demand.
Glamsterdam addresses this with two separate mechanisms:
- ePBS (EIP-7732) separates consensus validation from execution validation. Enshrined proposer-builder separation is a protocol-level split in which the proposer commits to a block header and the builder delivers the execution payload separately. According to Everstake, this extends the payload propagation window to about 9 seconds . A Glamsterdam explainer says the window was about 2 seconds before the upgrade (video: FatheryFinds). The video's figure has not been independently confirmed. Even so, a window several times longer gives nodes much more time to download and verify a larger payload.
- Block-level access lists (EIP-7928) let clients work in parallel. A BAL is a record, included in each block, of every account and storage slot the block touches. Because clients know in advance which state each transaction will touch, they can load that state, execute transactions and compute the state root in parallel rather than one step at a time . Validation time grows more slowly than block size, which is what keeps a 200M block practical for ordinary hardware.
The two changes support each other. ePBS gives the network more time, and BALs make better use of that time. Without the parallel execution BALs allow, a longer window would only delay the bottleneck. Without the longer window, parallel execution would still have to fit a 3x larger block into the old tight deadline. The Crypto Briefing coverage of the Sepolia fork also points to the extra room the restructured slot leaves for blob capacity. Blobs are the data space rollups use, so faster propagation can benefit layer-2 networks as well as L1 execution .
Being able to run 200M blocks does not mean mainnet will adopt them. The testnet gives client teams and validators a way to measure how much headroom the new design really adds before anyone proposes mainnet parameters.
"Sepolia's 200 million figure is a test target, not a promise," — Crypto Briefing editorial coverage of the Glamsterdam Sepolia fork (source: Crypto Briefing)
For traders, this is a change in what limits mainnet blocks rather than a change in fees today. Before Glamsterdam, the limit came from how long it took to move and check a block, which held capacity near 60M. After Glamsterdam, the practical ceiling depends on node hardware, bandwidth and how many validators opt in. Those factors can be measured and adjusted step by step, and the Sepolia rollout is the first public test of them.
What Did the Devnets and First Sepolia Blocks Show?
The devnets and the first Sepolia blocks show that 200M-gas blocks work in practice on test networks. Devnet 11 moved from 60M to 200M gas with about 84,000 validators running several clients . On Sepolia, more than 25 early blocks used between 52M and 92M gas . That is well above mainnet's current ceiling, though still far below the new limit.
The gas limit was raised in steps on the devnets before any public testnet. According to The Defiant, the final devnet phase targeted a 200M gas-limit floor rather than a ceiling . That distinction matters. A floor means client teams expected 200M to be the baseline they had to handle, not an upper bound. Devnet 11 also included validators across several client implementations. That shows multi-client networks can reach consensus at the higher limit, not just one client running alone, as reported by KuCoin News.
The first Sepolia data after the fork on October 6, 2026 is mixed but steady :
- Utilization: sampled blocks used 26% to 46% of capacity. This is normal for a testnet, where demand is low and often scripted .
- Peak blocks: more than 25 blocks consumed 52M to 92M gas. Several of them were larger than any block mainnet can produce under its roughly 60M limit .
- Stability: staking participation was reported at 99.97%. This suggests validators kept up with bigger blocks without missing many attestations .
Traders should keep two limits in mind. First, no early Sepolia block came near a full 200M, so a sustained full-capacity load has not yet been shown publicly. Second, testnet participation says little about how home stakers on modest hardware would cope with mainnet traffic. As Crypto Briefing put it, the 200M figure is a test target, not a promise .
Some performance figures come from only one source: a YouTube explainer. They have not been independently checked against Nethermind's or the Ethereum Foundation's own publications. The video reports the following (video: FatheryFinds):
- Testnet networks forked on September 16, 2026, then moved from 60M to 200M gas about an hour after going live on September 17 .
- Nethermind's block-level access list (BAL) performance testing passed all 2,302 tests. It processed 570.7 billion gas in 3 minutes 15 seconds, about 2.9 billion gas per second .
If confirmed, the throughput number would mean one client can execute a full 200M-gas block in a fraction of a second. Treat it as a claim to check, not as a benchmark.
| Milestone | Date | Gas limit | Key metric |
|---|---|---|---|
| Devnet 11 | Before Sepolia (exact date not reported) | 60M → 200M | ~84,000 validators across several clients |
| Final devnet phase (The Defiant) | Before Sepolia (exact date not reported) | 200M floor targeted | 200M set as the baseline, not a cap |
| Testnet networks (video-sourced, unverified) | Forked Sep 16, 2026; raised Sep 17, 2026 | 60M → 200M about 1 hour after launch | Nethermind BAL: 2,302/2,302 tests, ~2.9B gas/sec |
| Sepolia public testnet | Oct 6, 2026, 13:53:36 UTC | 200M (validator opt-in) | 26–46% sampled utilization; 25+ blocks at 52M–92M; 99.97% participation |
Taken together, the testing record supports one claim and leaves another open. Multi-client networks can run at 200M gas without breaking consensus. Whether they can sustain full 200M blocks under real, adversarial demand has not been shown publicly yet.
What Would a Higher Gas Limit Mean for Mainnet Fees?
For now, a higher gas limit changes nothing about Ethereum mainnet fees. Glamsterdam has no mainnet activation date, and the mainnet gas-limit parameters have not been decided . Sepolia's 200M figure is a test of what the network can handle. It is not a fee forecast. If mainnet later adopts a much higher limit, the first likely effect is lower base fees when demand stays the same. Real-world fees will still depend on how much demand shows up to fill the extra space. Traders should treat any fee projection as conditional until the Ethereum Foundation sets mainnet parameters (source: Crypto Briefing, 2026-10).
The mechanism comes from EIP-1559. Under EIP-1559, each block has a target size, and the base fee rises only when blocks are fuller than that target. Today's mainnet limit is about 60M gas. Moving to something near 200M would let each block hold more than three times as many transactions . With the same number of users competing for space, blocks would sit below target more often, and the base fee would drift down. According to Everstake, that is the direction of travel, but it depends on demand staying flat.
"Actual fees depend on L1 demand," notes staking provider Everstake in its Glamsterdam explainer (source: Everstake).
This caveat matters for anyone pricing in cheaper transactions. Lower fees tend to attract activity that was previously priced out, such as arbitrage, high-frequency onchain trading and applications moving back from rollups. That new activity can refill blocks and push the base fee back up. Extra capacity sets a lower ceiling on fee spikes. It does not set a permanently lower price.
The repricing EIPs mean fees will not move evenly across transaction types. Everstake describes EIP-8037 as raising the gas cost of creating new state to slow state bloat . The likely split looks like this:
- Likely more expensive: deploying contracts and writing to new storage slots, because both create new state under EIP-8037.
- Likely cheaper: many routine ETH transfers, token transfers and swaps that touch existing state, as base-fee pressure eases.
- Uncertain: state-access costs, which secondary coverage says EIP-8038 updates . The net effect depends on each contract's access pattern.
The Ethereum Foundation tells developers to test contracts and gas estimation against the new accounting rules (source: Ethereum Foundation, 2026-09). That warning extends to wallets and bots. If they hard-code gas assumptions, they could misprice transactions after a mainnet fork.
Priority fees are the least predictable part. EIP-7732 (ePBS) builds the builder/proposer split into the protocol itself. That changes how block-building value, often called MEV, flows between builders and validators. Everstake says ePBS may affect priority fees, but the "direction is uncertain" . Active traders who pay up for fast inclusion should not assume tips will fall along with base fees.
Finally, some numbers circulating online need a clear label. Some secondary outlets cite a fee reduction of about 78.6% and a long-term goal of 10,000 transactions per second . Neither figure is an Ethereum Foundation commitment, and neither has been shown on a public testnet. As of October 2026, the only verified data is Sepolia's opt-in 200M ceiling and the 26%–46% utilization measured in early sampled blocks (source: KuCoin News, 2026-10). A cautious reading is that Glamsterdam gives mainnet room for cheaper base fees. How much of that room users actually see will depend on the final parameters and on demand.
What Are the Risks: Node Load, Decentralization and Config Errors?
Glamsterdam's larger blocks bring three main risks. Nodes need more resources, smaller operators could be squeezed out, and a client setting can quietly decide the real gas limit. Sepolia's 200M ceiling is more than three times mainnet's current limit of about 60M . Every validator that proposes or checks those blocks has to handle the extra load. These are the trade-offs to weigh before treating the testnet number as a mainnet plan.
The first risk is hardware. Bigger blocks mean more data to download, more transactions to run and faster state growth on disk. ePBS and block-level access lists are meant to keep validation time under control, but they do not remove the cost. They spread it across a longer propagation window and parallel execution. Crypto Briefing notes that heavier node requirements could put pressure on smaller operators. That raises decentralization questions for a network whose security depends on many independent validators. Home stakers with consumer bandwidth and modest SSDs are the group most exposed if mainnet parameters rise sharply.
The second risk is configuration, and Sepolia has already shown it in practice. The Ethereum Foundation's announcement said Prysm and Teku would default to 60M after activation unless operators set 200M explicitly . Prysm shipped emergency release v7.2.1 just before the fork so that Sepolia validators would default to 200M. Without it, operators who left their settings alone would have kept proposing 60M blocks . This matters for traders reading capacity headlines because:
- Protocol rules set the ceiling. Client defaults and operator settings decide the gas limit validators actually use.
- Defaults can lag the plan. A single client default can hold part of the network at the old limit with no failure that anyone sees.
- Release timing is a risk of its own. Last-minute patches leave operators little time to update before a fork.
The third risk is reading too much into a test. Crypto Briefing described Sepolia's 200 million figure as a test target, not a promise. Glamsterdam has no mainnet activation date, and the final mainnet gas-limit parameters have not been decided . Mainnet could adopt a lower figure or raise the limit in steps, and either would change any fee or throughput forecast built on 200M.
For ordinary holders the practical risk is fraud, not the protocol. ETH holders do not need to do anything for Glamsterdam. Balances, addresses and tokens are unaffected, and anyone offering to "upgrade" your ETH is running a scam . Upgrade periods reliably bring phishing links, fake migration portals and "swap your old ETH" messages. The safe response is the same each time: no wallet connection, no seed phrase and no transfer is needed.
What Comes Next: Hoodi, Mainnet Timing and What to Watch
The next step for Glamsterdam is the Hoodi testnet. Hoodi is tentatively planned for late October, and one report gives October 27 as the date . The Ethereum Foundation's own activation table still lists Hoodi as "TBD" (source: Ethereum Foundation, 2026-09) . Mainnet has no confirmed date. The final mainnet gas-limit parameters also have not been decided, so Sepolia's 200M blocks show what is technically possible. They do not set mainnet's starting point.
Treat the timeline with caution. Ethereum.org shows a Q4 2026 mainnet target, but no fork date has been confirmed. An earlier target of end-of-August 2026 has already passed without activation (source: IG, 2026-06; CoinMarketCap Academy) . Hard forks usually move to mainnet only after every public testnet has run cleanly. Any bug found on Hoodi would therefore push the mainnet schedule back.
Watch list for the coming weeks
- Hoodi activation date: check whether the EF replaces "TBD" with a fixed epoch, and whether that lands on or near October 27.
- Gas-limit signaling: see which gas-limit default client teams ship for Hoodi, and whether validators keep 60M or move to 200M without being prompted.
- Client releases: look for more emergency patches like Prysm v7.2.1. They are a sign of how close defaults are to being production-ready .
- Node-operator feedback: watch for reports on bandwidth, disk growth and missed slots from smaller and home stakers once Hoodi is under load.
Scenario view
- Base case: staged increase. Glamsterdam reaches mainnet with a gas limit above today's roughly 60M. Validators then raise it step by step instead of jumping straight to 200M. This matches how Ethereum has handled gas-limit changes before.
- Bull case: close to 200M. Hoodi runs cleanly, client defaults line up and operators report manageable load. Mainnet then adopts a limit near Sepolia's target, which would give more than three times today's block capacity .
- Bear case: delay or a lower limit. Hoodi turns up bugs or decentralization concerns, and the mainnet fork moves into 2027 or launches with a limit well below 200M. As Crypto Briefing put it, the Sepolia figure is "a test target, not a promise."
The practical takeaway for traders is that nothing on mainnet changes until a fork date and a gas-limit default are both published. Track the EF activation table and client release notes, not secondary forecasts of fee cuts or throughput. Validators should confirm their gas-limit settings on every testnet and not assume the default is right. For FatheryFinds' early devnet-to-200M walkthrough, see the video listed below (video: FatheryFinds).
Frequently Asked Questions
When did Glamsterdam go live on Sepolia?
Glamsterdam went live on the Sepolia public testnet on October 6, 2026, at 13:53:36 UTC. That was epoch 353,024, slot 11,296,768 . The Ethereum Foundation set this date in its official Glamsterdam Testnet Announcement. The fork combines the "Amsterdam" changes to the execution layer with the "Gloas" changes to the consensus layer. It shipped with 18 core EIPs .
Is the 200M gas limit automatic on Sepolia?
No. The 200 million block gas limit on Sepolia is opt-in. According to the Ethereum Foundation, the Prysm and Teku clients default to 60M after activation, so validators have to set 200M themselves. Prysm validators use version-2 proposer settings. Teku validators use --validators-builder-registration-default-gas-limit=200000000 . Shortly before the fork, Prysm released an emergency update, v7.2.1, which makes 200M the Sepolia default. Validators who hadn't updated their settings would otherwise have kept proposing 60M blocks, according to KuCoin News .
Will Glamsterdam lower Ethereum mainnet fees?
Not yet. Glamsterdam has no mainnet date, and the final gas-limit parameters for mainnet haven't been decided . Mainnet's current limit is about 60M. If it eventually rises toward 200M, demand would be spread over more block space, and under EIP-1559 that tends to push base fees down as long as demand stays the same. However, Everstake points out that actual fees depend on L1 demand, and cheaper fees could attract enough activity to fill blocks again. EIP-8037 also makes it more expensive to create state, such as deploying contracts or writing new storage slots . Some outlets predict an exact fee cut, such as about 78.6%. These are not Ethereum Foundation commitments.
Do ETH holders need to do anything?
No. Glamsterdam doesn't change ETH balances, wallet addresses or tokens, and holders don't need to take any action. As IG notes, anyone offering to "upgrade" or "migrate" your ETH for the fork is running a scam. Don't share your seed phrase, and don't send funds to any address that claims to be part of the upgrade. Only node operators and validators need to act, and on Sepolia that mainly means checking their client version and gas-limit settings.
When is Glamsterdam coming to Ethereum mainnet?
There is no confirmed date. The next step is the Hoodi testnet, tentatively planned for late October 2026. One report gives October 27 , but the Ethereum Foundation's activation table still lists Hoodi as TBD . Ethereum.org shows a Q4 2026 mainnet target, which is also unconfirmed. An earlier target of late August 2026 has already been missed, according to CoinMarketCap Academy . Treat any mainnet date as provisional until the Ethereum Foundation publishes one on its blog.
Enjoyed this article? Subscribe to get new stories by email whenever they're published.