Glamsterdam Gas Repricing: What Trading Bots Need to Know

A transaction that works before a gas repricing can fail afterward without any change to its calldata or contracts. Raising its outer gas limit may fix the failure. If a contract forwards a hardcoded amount of gas to the failing call, raising the outer limit may do nothing.

That is the compatibility question for trading bots ahead of Glamsterdam. EIP-8037 introduces separate accounting for state creation. EIP-8038 raises the cost of several state-access and write operations. As of September 16, 2026, both are planned for the upgrade, not active on Ethereum mainnet.

The Ethereum Foundation’s August 24 testing guide and repricing impact checker are the starting points. Use them to identify affected contracts, then replay the actual execution paths your bot uses.

What changes

EIP-8037: state creation in a separate gas dimension

EIP-8037 introduces a separate gas dimension, state-gas, alongside execution-gas. State creation operations (new accounts, new storage slots, deployed code) are charged to state-gas. The cost per new state byte (CPSB) is 1,530, targeting an average state growth of 120 GiB per year at a reference block gas limit of 150M units. Source: EIP-8037 specification, Abstract.

A transaction’s state-gas cap equals the full tx.gas limit; the execution-gas cap is bounded separately by EIP-7825’s TX_MAX_GAS_LIMIT. The state_gas_reservoir holds gas that exceeds the execution budget and is passed in full to child frames (the 63/64 rule applies only to execution-gas). State-gas charges draw from the reservoir first; once it is empty, charges draw from gas_left and are tracked as state_gas_from_gas_left. The per-user paid gas is the sum of both dimensions. At the block level, only the bottleneck dimension (the one with higher cumulative gas) determines the block-full check and base fee update; the block header gas_used equals max(execution_gas_used, state_gas_used). Source: EIP-8037 specification, Reservoir model and Block-level accounting.

EIP-8038: access and write costs rise

EIP-8038 raises execution-gas costs for accessing and modifying existing state, benchmarked against real client performance at mainnet state size. Source: EIP-8038 specification, Parameters.

The embedded “before” values are the EIP’s decomposition of existing composite costs, not standalone opcode prices. For example, an SSTORE charge also depends on cold versus warm access and the slot’s original, current and new values. The largest change is STORAGE_WRITE, net-metered within a transaction: a slot changed and then restored to its original value gets its STORAGE_WRITE refunded. The refund is an execution-gas refund capped at 20% of total gas used, not always fully granted.

Impact categories per the EF replay analysis

The EF’s replay of historical mainnet transactions under the new schedule found four outcomes (source: EF blog, Impact section):

1. No change – identical outcome and execution. The large majority of transactions fall here.
2. Succeeds with changes – still succeeds but gas used differs.
3. Fixable with a gas-limit increase – out-of-gas at original limit but completes with a higher one.
4. Potentially broken – fails even with a substantially raised limit.

The EF reports direct outreach to the most-affected builders is already underway and lists flagged contracts at the repricing impact checker.

Where bot operators should focus

Hardcoded gas values in forward calls

A contract that calls a third-party swap, oracle, or liquidation contract with a fixed gas budget (target.call{gas: 100000}(data)) may fail if the called code now exceeds that budget. The EF blog flags this as the primary cause of “potentially broken” classifications.

What to change: Test a larger explicit budget or reconsider whether the call needs a fixed cap. Removing a cap changes the amount of work untrusted code can perform. It is not a mechanical search-and-replace fix: review reentrancy, apply checks-effects-interactions or the appropriate guard, and check the low-level call’s success result. Ordinary gas forwarding still obeys the EVM’s 63/64 rule.

The 2300 gas stipend

Solidity’s transfer() and send() expose the recipient to a 2,300-gas budget. Glamsterdam does not change CALL_STIPEND, but relying on a particular recipient implementation continuing to fit that budget is fragile when its opcode costs change.

Do not use storage writes as an example of something that previously worked inside that stipend. EIP-2200 already forbids SSTORE when the remaining gas is at or below the stipend. Cold account-access costs also already exceeded 2,300 gas before this upgrade. The relevant question is whether the recipient’s actual executable path, including warm accesses and code inspection, still fits.

If a payment path needs redesign, consider the withdrawal pattern. Replacing a transfer with a low-level value call requires explicit failure handling and a reentrancy review; forwarding more gas is not itself a security fix.

gasleft() branching

Contracts that branch on gasleft() thresholds may trigger an expensive path when less gas remains than expected under the new schedule. These branches are application-specific and require manual review.

Presigned transactions

A signed transaction commits to its gas limit. If that limit becomes too small, you cannot edit the serialized transaction and retain its signature. Re-estimate, re-sign where the signing authority is available, and replace any affected queued submissions. If another party supplied a signature you cannot renew, treat that as a separate compatibility problem.

Testing workflow

The EF testing guide points developers to Platåberget, the community-joinable Glamsterdam testnet. Use the linked network resources for current endpoints and supported client versions; a normal current-mainnet node does not execute transactions under the future gas schedule.

1. Check deployed contracts at the repricing impact checker. Flagged addresses show the specific repricing driving each failure.

2. Replay against the new schedule. Use the compatible execution-client builds and test-network resources linked from the EF guide. For a controlled local replay, hold the starting state, calldata, sender and transaction order constant. Compare results under the old and proposed rules. Changing the network’s state as well as its rules makes the cause of a difference harder to isolate.

3. Exercise complete bot transactions. Include successful swaps, rejected slippage bounds, liquidation paths, first-time approvals, new positions and any executor deployment. Compare receipt status, return data, balance changes and gas use. A successful empty call is not evidence that a multi-contract trading route still works.

4. Inspect failures inside the call tree. First determine whether an outer gas-limit increase fixes the path. If not, identify an internal forwarded-gas cap, a gasleft() branch or an application revert. Do not apply one multiplier to every transaction.

5. Revisit state-gas assumptions. The GAS opcode behind gasleft() reports gas_left, not the separate reservoir. Recheck code that treats this value as a complete description of the transaction’s remaining budget.

6. Update gas estimation and signing together. Manual cost tables need all applicable fork rules, not just one new opcode price. RPC estimation needs a client configured for the fork. Verify that the resulting estimate actually reaches the transaction your signer produces.

The repricing economics for searchers

Do not estimate the change in a strategy’s total cost by multiplying its old gas use by the largest increase in the table. One route can mostly read warm state; another creates accounts, initializes storage and invokes several hooks. Refunds and call-frame behavior differ too.

Keep a route-level record: which starting state was used, whether the transaction succeeded, total charged gas, and resulting asset balances. A route that remains profitable before gas may no longer clear the executor’s minimum-profit condition after fees. Conversely, a temporary storage change restored in the same transaction does not have the same net cost as a new persistent slot.

The reservoir is not free extra gas. Users pay for execution-gas and state-gas, and state charges draw from gas_left once the reservoir is exhausted. The fact that the reservoir passes in full to child frames does not guarantee that a deep call succeeds.

Status

As of September 16, 2026, both EIPs are scheduled for Glamsterdam and remain in Review. Parameters may change before mainnet. Track EIP-8037, EIP-8038 and the Glamsterdam meta EIP. Testnet results describe the client and fork configuration used for that run, not an unconditional guarantee about the final release.

What to fix first

Start with contracts flagged by the impact checker and the executor paths that use hardcoded internal gas limits. Then inspect presigned transactions and gasleft() checks. An outer limit can be changed before signing; a cap embedded in an immutable third-party contract is a different problem.

The Glamsterdam overview covers the broader fork. For routes that encounter arbitrary callback logic, the Uniswap v4 hooks simulation guide explains why a pool quote is not enough.

BLAZED.sh’s local node endpoint serves Ethereum mainnet. Configure a separate compatible testnet or local replay environment for this rehearsal. Faster access to today’s mainnet state cannot tell you whether a transaction will pass tomorrow’s execution rules.