# Repricings: A silent hero for Glamsterdam *Opinion piece by Caspar and Ansgar, Oct 24th 2025.* ## Glamsterdam focus: Scale Ethereum L1 For Glamsterdam, ACD for the first time adopted a new process by choosing *headliner(s)* to pick a fork theme. Both headliners, [EIP-7732 (ePBS)](https://ethereum-magicians.org/t/eip-7732-the-case-for-inclusion-in-glamsterdam/24306) on the CL and [EIP-7928 (BALs)](https://ethereum-magicians.org/t/eip-7928-block-level-access-lists-the-case-for-glamsterdam/24343) on the EL, were chosen for their ability to scale Ethereum L1. With headliners locked in and implementations well underway, ACD is shifting its focus choosing non-headliner EIPs to include in Glamsterdam. There are currently [30 EIPs Proposed for Inclusion (PFI)](https://eips.ethereum.org/EIPS/eip-7773#proposed-for-inclusion). In this document we propose to **double down on Glamsterdam's scaling theme** set by its headliners, and argue that a core bundle of repricing EIPs offers an ideal path to that end. **Repricings (1) directly scale Ethereum L1, and (2) unlock the full scaling potential of both headliner EIPs.** In our view, repricings are a silent hero bundle of EIPs for Glamsterdam. *This document does not touch on the details of any individual EIP and only argues for repricings as a general theme, not for any specific EIP bundle. All repricing EIPs proposed for Glamsterdam can be found in the [meta EIP](https://eips.ethereum.org/EIPS/eip-8007). The two breakout calls this and next Wednesday are the best place to discuss the specifics as well as the relationship between these EIPs.* ## The general case for repricings Currently the process to scaling the gas limit has followed this iterative loop:  1. **Identify**: Benchmark all operations to find the slowest one. 2. **Optimize:** Improve client implementations of the identified operation to improve its performance. 3. **Scale:** Raise the gas limit, until the next slowest operation (possibly still the same) reaches limit. As depicted, the distribution of performance across operations is currently very "spiky". That means that scaling is blocked by a few particularly slow operations (e.g. for compute those are a few specific precompiles), while most operations could support a significantly higher gas limit. While the manual optimization loop depicted above can bring some short term relief and additional room for scaling, it doesn't change the overall picture of performance mismatch across operations. A different way of saying that: The operations are *mis-priced* relative to each other. Therefore, the most effective way of addressing this situation is through repricing: <div style="text-align:center;"> <img src="https://notes.ethereum.org/_uploads/rkxyKpqKCxe.png" style="width:55%;"/> </div> A repricing done well allows each individual operation to run at close to its own throughput limit, minimizing the loss from individual worst case outliers. One additional benefit is that this frees engineering resources to focus on optimizing the most commonly used operations instead of on individual outliers (these outliers that currently bind resources are mostly artificial edge cases that would only be seen on mainnet in the case of an attack on the network). Repricing is important both within any given resource (data, compute, or state), but importantly also across resources. Throughput is always constrained by the worst-case operation within a given resource (e.g. slowest opcode in compute) and by the most constrained resource overall.  Note that the resources shown here - data, compute, and state (as in, state access) - are the relevant ones for burst loads only, determining whether any new block can successfully be processed within a single slot. Importantly though, repricing must also take sustained loads into consideration (e.g., state growth, sync, ...). **In conclusion, repricings are a very attractive way to get a significant one-time throughput gain. These gains come primarily from fixing the "pricing bugs" in the protocol, closing the gap between average case and worst case performance.** *^Note that this section is largely a write-up of [Ansgar's talk on L1 scaling](https://www.youtube.com/watch?v=q5T2qzyAt5g), including the figures.* ## Unlocking the scaling potential of ePBS & BALs Beyond the standalone merits of repricing, it also has important cross-synergies with both headliner EIPs. Repricing enables the full scaling potential of ePBS, and unlocks the scaling benefits of BALs in the first place. ### [EIP-7732: ePBS](https://ethereum-magicians.org/t/eip-7732-the-case-for-inclusion-in-glamsterdam/24306) ePBS itself immediately gives L1-scaling benefits by using more of the slot for block processing (as opposed to having to do everythin in first 4s of slot), thus enabling a higher gas limit. But without repricings, only the time period until the payload timeliness committee (PTC) deadline can be taken into account for increasing throughput, because this is the time period where all three burst resources can be used. However, the PTC deadline only limits the download window (so the time for using data/bandwidth), and block processing can otherwise continue until the end of the slot. <u>To make this extra time for compute and state access available for scaling, pricing adjustments are necessary</u>. ### [EIP-7928: BALs](https://ethereum-magicians.org/t/eip-7928-block-level-access-lists-the-case-for-glamsterdam/24343) <u>Without repricing, BALs themselves do not unlock any scaling gains.</u> BALs' various improvements only make compute and state access more efficient: * transaction parallelization allows for more compute per block * state pre-fetching and parallel state root calculation allow for more state reads and writes per block But without repricing, data would become the bottleneck, blocking any gas limit increases from BALs. Repricings can make compute and state access (not state growth of course!) cheaper relative to data, allowing us to take advantage of these BALs improvements for increased throughput. ## Conclusion We propose to prioritize repricings for the non-headliner space of Glamsterdam. Repricings (1) directly scale Ethereum L1, **and** (2) unlock the full scaling potential of both headliner EIPs. Repricings can be a silent hero bundle of EIPs for Glamsterdam.