YAY! Another fork with 10+ repricing EIPs 
Just what we needed after the Glamsterdam repricings…
Joking aside, repricings are an important piece of the Ethereum roadmap that can have both positive and negative effects on the ecosystem. They can improve the long-term health of the network by better aligning gas costs with resource usage, but they can also introduce compatibility risks and break existing tooling if not handled carefully.
Based on my experience with repricings in the last fork, I attempted to compile an opinionated view of the repricing EIPs in Hegotá. The goal is to help the community understand the trade-offs and risks of each repricing EIP and provide guidance on how to approach them.
This is not an exhaustive list and deliberately focuses on the EIPs that:
-
Change the gas cost or cost formula of an existing opcode or precompile.
-
Change transaction-level gas floors, intrinsic gas, or block/state gas-limit constants.
-
Change EVM metering mechanics (e.g., refunds, warm/cold accounting).
I grouped the EIPs based on their primary effect and discuss each group below. The TL;DR is that I think we should do much less than we did in Glamsterdam and focus on the small changes that bring the biggest wins.
Data and state growth
Data repricing has two distinct benefits. At an unchanged gas limit, it reduces the largest block an attacker can construct, giving the network more propagation margin and making worst-case behavior more robust. That safety gain stands on its own even if Hegotá does not scale.
On the other hand, the same headroom can instead be spent on throughput, with Hegotá potentially able to scale the gas limit to 450M. This second benefit matters because bandwidth, rather than execution, is the current binding constraint on further gas-limit increases. Realizing both benefits requires a transaction floor that accounts for every source of block data and prices it at the right rate.
Scaling also requires a way to adjust state-growth pricing as the block limit changes. These goals can be achieved with limited cost and protocol complexity.
Unify the data-floor pricing
EIP-8131 and EIP-8279 are two parts of the same change. EIP-8131 provides one floor formula, 21000 + 64 × weighted byte count, that accounts for every user-controlled transaction-content field: calldata, access-list entries, EIP-7702 authorization tuples, and blob versioned hashes. EIP-8279 includes the bytes generated dynamically in the Block Access List (BAL) in that same calculation. Together, they aim to account for all data added to a block. However, EIP-8279’s trigger table should be checked against new code-mutation paths before relying on that guarantee.
At the current 64 gas/byte floor, EIP-8131 and EIP-8279 reduce the maximum amount of transaction data that can fit in a block by roughly 42%. This is the part of the package whose value does not depend on raising the gas limit: Hegotá can keep the headroom as additional safety rather than spend it on larger blocks.
The overall cost is modest:
-
Based on the EIPs’ mainnet samples, EIP-8131 increases aggregate gas by about 3.56%.
-
Most of EIP-8131’s effect is concentrated in EIP-7702 SetCode transactions: their binding rate rises from 0.04% to 20.63%, and their average floor rises from 240k to 587k gas.
-
Adding BAL-byte accounting through EIP-8279 increases the share of transactions that pay the floor by another 0.54 percentage points.
In addition, protocol complexity remains medium-low because both EIPs contribute to the same floor calculation rather than introduce separate pricing mechanisms. If we don’t plan to scale in Hegotá, these two EIPs are still a good addition as long as they don’t delay the fork too much. If we want to scale in Hegotá, then they become essential and need to be included.
Keep state-growth in check
EIP-8368 and EIP-8372 are alternative ways to recalculate the per-state-byte constant (CPSB) introduced by EIP-8037. The correct choice depends on evidence that will only be available after Glamsterdam. Three scenarios are possible:
-
State and execution demand are mismatched: one resource’s utilization remains far from its target while the other resource constrains the block. This is an EIP-8037 failure mode. In this case, we should adopt EIP-8372, which performs a one-time recalibration of
CPSBand scales the raw state-gas limit at the hard-fork boundary, bringing state and execution capacity back into balance. -
Demand is balanced, but Hegotá raises the block gas limit: in this case, we should adopt EIP-8368 to re-derive
CPSBfor the higher limit and keep state growth on target without changing the mechanism. -
Demand is balanced and the block gas limit stays unchanged: in this case, we should make no Hegotá update and retain EIP-8037’s existing parameters.
For that reason, Hegotá should not commit to either EIP yet.
Recommendation
Before the scoping decision starts, we need to have a conversation about whether we want to scale in Hegotá. If yes, we need to include the data repricing package. If not, we should weigh the protection against worst-case block sizes against the time the data repricings would add to the fork.
In any case, I strongly believe we should wait until Glamsterdam ships before deciding on the right CPSB calibration. We need to observe how gas demand responds to EIP-8037 in order to make an informed decision.
State access and refunds
Hegotá has a significant number of EIPs that touch the refund counter and warm/cold access mechanics. They can be divided into two main opposing philosophies: protocol simplification versus more accurate pricing.
Simplification
The main EIP in the simplification camp is EIP-3298: Remove storage-clear refund and refund cap. It removes the SSTORE-clear refund entirely: no more per-transaction refund bookkeeping, no more interaction with the 20%-of-gas-used cap, and no more surface for GasToken-style schemes that mint storage when gas is cheap and clear it when gas is expensive.
However, this simplification comes with a cost. It removes the incentive to free storage that is no longer needed and denies users credit for reducing persistent state. To quantify this cost, we analyzed one month of mainnet data. In this sample, 24.6% of transactions receive refunds, and the average refund among those transactions is 11.6% of the transaction’s total gas usage. Across each day in the sample, refunds reduce aggregate gas costs by an average of 7.2%. However, this includes refunds from both slot clearing and write reversals. We estimate that slot clearing accounts for at most 16% of the average aggregate refund, implying that storage-clearing refunds reduce gas costs by at most roughly 1.2%. During this period, an average of roughly 525,000 slots are cleared per day, which implies average savings of 11.4 GiB per year (assuming each slot occupies 64 bytes).
Accurate pricing
EIP-8358: Net Gas Metering for Account Changes introduces net gas metering (akin to EIP-2200) for account writes. The PR for the EIP has not yet been merged, and it likely needs a couple of tweaks before being ready. Nevertheless, the idea is to make gas metering of account writes more accurate, which should result in a cost reduction for these operations. It introduces more complexity to EVM gas metering because we now need to track which accounts have already been written to and the values being written. It also adds refunds for balance resets, which goes against the design of EIP-3298 and further complicates gas metering.
EIP-7973: Warm Account Write Metering chases the same idea with a lighter mechanism: instead of net metering, it applies cold/warm pricing to account writes from CREATE/CREATE2/*CALL. It has no champion right now and its constants are still TBD, but I think EIP-8358 should embrace some of the simplifications from this EIP.
In terms of impact, I looked into 15 days of mainnet blocks and estimated the gas savings from a generalized net account-metering system. I assumed the first write to an account per transaction would cost ACCOUNT_WRITE = 9000 gas (per EIP-8038) and any further writes would cost WARM_ACCESS = 100. With this pricing, only 7% of transactions experience gas savings; among those transactions, the average saving is 13% of total gas used. On a gas-weighted basis, this represents 4% of the average gas used per block.
In a similar direction, EIP-8374: Persist Warm Access Sets Across Reverts allows the warm status introduced by EIP-2929 to survive a reverted frame within the same transaction. This means keeping addresses and slots warm after a revert. This EIP is independent of the decision around refunds and thus can be taken in isolation. It is smaller and more contained, but its impact is also smaller: only 0.9% of call frames revert, based on a one-month sample from mainnet.
Recommendation
The simplification case for retiring the general refund counter (EIP-3298) holds up once you account for EIP-8037 already covering the state-growth incentive it used to provide, and it removes a real arbitrage surface in the process. The impact on throughput and gas fees is limited, as refunds from state clearing account for around 1% of gas used. Overall, I think it is a positive change.
Regarding account net metering, I think the idea makes sense in principle. However, the current shape of EIP-8358 still needs some work. It should drop the refunds for balance resets (for consistency with EIP-3298) and simplify the accounting logic. In addition, the impact is limited. Only 7% of transactions will see any savings, and the overall gain per block is only 4%. EIP-8374 also makes sense in principle, but its impact is even smaller. I would only make these changes if there is a low probability of them delaying the fork. To establish that, these EIPs still require more work to de-risk.
Memory
EIP-7923 replaces the current quadratic memory-expansion formula with a flat per-page charge (ALLOCATE_PAGE_COST=100 gas per newly touched 4,096-byte page) and adds an explicit 16,384-page (64 MiB) transaction-global cap in place of today’s implicit gas-based limit.
Even though it is not proposed for Hegotá, the competing EIP-7686 also introduces linear memory pricing, but ties memory limits to available gas rather than imposing a fixed transaction-global cap.
I think the general direction of both EIPs is right: linear pricing makes memory costs more predictable, and an explicit bound removes the worst-case quadratic blowup that today’s formula only discourages rather than rules out. However, the proposals make different trade-offs in granularity, call semantics, and whether the bound is fixed or tied to gas, so more thought is needed to determine the best approach. I am also not yet convinced that the immediate impact is high enough to justify adding either proposal in this fork.
zkEVM preparation
There are three EIPs proposed for Hegotá that aim to address issues for zkEVMs.
First, the EVMification EIPs (EIP-7666 and EIP-8200) replace native precompiles with equivalent EVM bytecode. This simplifies future zkEVM provers and increases precompile costs, helping with worst-case proving.
Second, EIP-7709: Read BLOCKHASH from Storage and Update Cost applies the cold/warm SLOAD pricing to in-window BLOCKHASH lookups and sources the value from storage instead of a separate historical-hash mechanism. By folding BLOCKHASH into ordinary state access, it removes the need for provers to support a separate historical-hash oracle outside the state trie. However, this will significantly increase the cost of a widely used opcode and, as such, is the EIP in this group with the highest impact on the ecosystem.
In my opinion, these changes should only ship if EIP-8025: Optional Execution Proofs also ships. Even then, these EIPs are not blockers for EIP-8025, so there is an argument for waiting until we ship zkEVMs. That way, we could package all zkEVM repricings in one go.
Transient storage
Transient storage has its own overpricing problem: TLOAD/TSTORE still cost the same as warm storage access despite touching a much cheaper resource. EIP-7971 fixes this with single-digit gas costs and a hard cap on total slots used. EIP-7609 chases the same fix with superlinear pricing instead of a hard cap. Neither has a champion, so they will not be considered for inclusion in Hegotá. However, I think this is an area we should look into for future forks. Especially with state-creation costs going up and fewer refunds being given, temporary storage will become more useful. We should analyze the current usage of TLOAD/TSTORE and the barriers to wider adoption. I am not convinced that simply changing their cost will be a silver bullet.