Vulnerabilities found in Glamsterdam. Agents came to the rescue. Ethlabs Week 18.

October 25, 2026 · published as an article on X

It’s been a rough week for Ethereum core devs. Just when everything was looking good for Glamsterdam to launch in December, ChainSecurity, a top auditing firm, delivered the tough news (or good news depending on how you look at it) that EIP-8037/8038 — two key enablers of the massive gas scaling in Glamsterdam — may introduce new vulnerabilities into existing contracts, and identified no fewer than 13 major DeFi projects that would be affected.

But they say it’s not about how you fall; it’s how you get up. At the ACD this week, core devs and researchers aligned that security trumps any timeliness concerns for the fork, and decided to conduct a thorough analysis on the impact of these issues before committing to a new launch date for Glamsterdam. Our very own @fradamt is playing a key role in this effort, with many of us at Ethlabs chipping in. Here’s how it all went down.

#Vulnerabilities in EIP-8037

For context, EIP-8037 and its companion EIP-8038 aim to increase the gas cost for creating and accessing state on Ethereum. Whenever you write to a new storage slot or create a new account on Ethereum, you are creating new state which must be stored by every validator on the network, so you must pay a cost. At the moment, Ethereum’s state is growing by about 116GB per year, and since Glamsterdam is going to increase the gas limit from 60M to 200M, the extrapolated state growth would become ~387GB per year, which would be so fast as to degrade the decentralization and performance of the network. Therefore, EIP-8037 and EIP-8038 seek to limit state growth by making state creation and access more expensive when state is growing too fast.

This week, it was brought to the core devs’ attention that ChainSecurity has identified a number of security issues with EIP-8037 and 8038. Specifically, some contracts that are secure today will become vulnerable once EIP-8037/8038 are deployed.

How can that happen? It turns out that EIP-8037 doesn’t just change how state is priced; it also changes how gas behaves, which breaks contracts that rely on the previous gas behavior. Today, when a contract A calls contract B, you can safely assume that if the call runs out of gas while B executes, there will only be a little (1/64) gas left to further execute the outer contract A. However, because EIP-8037 introduces a new mechanism where gas can be refilled when a storage slot is freed, it’s now possible for the inner call to B to run out of gas, while the outer call inside A still has a lot of gas left. If the outer call has an error handler that would not have completed with a tiny amount of gas, but would now complete with a larger amount of gas, that would change the behavior of the contract and would be something an attacker could exploit.

(This is a high-level description of the issue that skips over many details — for a more thorough treatment please refer to ChainSecurity’s article.)

Zooming out from the nitty gritty details, the big lesson is that given how complex the Ethereum protocol has become, any change to the protocol may have a large number of second-order effects that the designer did not intend, and therefore it’s critically important that we thoroughly identify the second-order effects before shipping any major change. In this case, the vulnerability was brought up very late in the fork process (less than 2 months before the scheduled launch), causing everyone to scramble to deal with the fallout. In the future, protocol designers would do well to conduct much more thorough analysis of potential breakages that their update might introduce, and to do so much earlier in the process.

But since there’s such a massive amount of projects and code that depend on Ethereum these days, how can we tiny humans be sure that we have investigated them all? The AI overlord comes to the rescue of course.

#Securing Ethereum with agentic collaboration

Remember the OpenAI <> Hugging Face hack where agents went rogue and found a message board to communicate with each other in order to coordinate their hacks? Well, turns out the same pattern is useful for the good agents too.

Shortly after the ACD, Francesco (@fradamt) spun up agents overnight to scan contracts for vulnerabilities that would be caused by 8037. He was delighted to see a number of useful findings when he woke up, and when he shared the findings with Toni (@nero_eth) from the EF, he learned that Toni had been doing the same. To avoid duplicating work, Francesco set up a message board for their agents in the form of a github repo, where agents would:

• Declare their resources in a RESOURCES.md markdown file (e.g. datasets, hardware, etc.)
• Claim open tasks by commenting on a Github issue (first comment wins)
• Update task status and priorities on OPEN_WORK.md based on latest progress
• Record findings in reports/, data/, and findings/ so another agent can inspect and reproduce the results
• Consolidate conclusions in memo/ and plans/ to coordinate next steps with other agents.

Will this be the repo that spawns Skynet? Maybe not, but it’s doing a really good job at pooling everyone’s resources to work towards a shared goal — identifying ALL projects affected by EIP-8037. Since Francesco created this collaboration repo, many other researchers from the EF and Ethlabs joined in, including yours truly, and participation was really as simple as just pointing your Codex/Claude at the repo, and the agent figured out the rest.

Due to the sensitive nature of security issues, we won’t be going into the details of what the agents found — those will be presented at the ACDT next week. But safe to say that the agents have done such a good job that we are now running a SECOND coordination repo for EIP-8198 aka “Quick Slots,” the EIP that @barnabemonnot has been pushing for Hegotá. The goal is to avoid a similar situation with 8037 by conducting a large-scale analysis to identify any projects that might break from the slot time decreasing from 12s to 10s (e.g. due to the project hardcoding the current slot time). And boy are these agents doing a great job too!

At Ethlabs, we anticipate all future major EIPs to go through similar AI-driven flows to identify potential breakages, and we are happy to be doing our small part in leading this transition alongside the EF.

#RPCs adopting FCR

In other news, thanks to the relentless campaign from @_julianma, a number of RPC providers are almost ready to launch their integrations with FCR — the Fast Confirmation Rule that would decrease L1 confirmation time from 13 min (finality) to 24 seconds. This means that if you are running a bridge, exchange, L2, or any project that currently uses an RPC provider to confirm L1 transactions, you may soon be able to confirm the transactions MUCH faster.

If you are unsure whether your RPC provider will support FCR soon, feel free to contact us! In some cases the RPC providers are rolling out FCR to select customers first, so we can help you get into the early release group.

#8288 visualization

If there’s a single EIP that you must pay attention to in 2027, it’s EIP-8288 aka “recursive mempool aggregation of PQ signatures and proofs” — Ethereum’s master plan for supporting PQ and private transactions AT SCALE.

Over the last few months, I’ve slowly become a super fan of EIP-8288 as I realized that it represents a paradigm shift in Ethereum that Vitalik outlined in his recent essay “The cryptographic world computer.” In short, Ethereum is moving into an architecture where its capacity can increase, not decrease, with the level of decentralization.

How is this possible? I created a visual explainer:

The EF is currently leading the development efforts for EIP-8288, but we’ve recently started engaging with them to see how we might contribute. We may have more to share soon!

#Devcon ahead

As Devcon is coming up, all of Ethlabs will be in Mumbai with the exception of me and @joshrudolf, both of whom have babies to tend to. We are planning some VERY exciting events for Devcon, one of which @binji_x has teased:

Our team will talk more about these events soon, but in the mean time, drop us a line if you will be in Mumbai and we’d love to meet!

---

ICYMI, here is last week's update:

Read the original on X →