Ethereum core developers just kicked off devnet-5, the latest dedicated test network for the upcoming Glamsterdam hard fork. It's a quiet but significant step. While the broader crypto market watches price charts, client teams are busy testing code that will change how smart contracts are written and how standard wallets behave. Glamsterdam targets two of the biggest pain points developers and users face today: the restrictive smart contract size limit and the clunky user experience of standard externally owned accounts (EOAs).
The devnet phase is where theoretical proposals face real-world conditions. Client teams are running nodes, simulating transactions, and looking for edge cases that could disrupt the network.
Breaking the 24KB Barrier
Let's start with the developer side. If you've ever built a complex decentralized application on Ethereum, you've likely hit the wall known as EIP-170. Introduced back in 2016 to prevent denial-of-service attacks, EIP-170 capped the maximum size of a deployed smart contract at 24.576 kilobytes. Back then, 24KB seemed like plenty. But as DeFi protocols grew to include complex lending logic and multi-hop swaps, developers started running out of space.
To get around this limit, developers had to get creative. They split single logical contracts into multiple smaller contracts, using proxy patterns or library calls. These workarounds work, but they introduce serious security risks. Every external call between contracts increases the attack surface, wastes gas, and makes the codebase harder to audit.
EIP-7954 changes this by expanding the contract code limit. Instead of a hard 24KB ceiling, the proposal introduces a flexible limit or a flat increase to 48KB, paired with a revised gas schedule to prevent the original DOS vectors. This means developers can write cleaner, more unified code. They don't have to waste time splitting contracts or worrying about optimization hacks just to fit within an arbitrary limit. It makes smart contract development on Ethereum look more like modern software engineering.
EIP-7702: Smarter Standard Wallets
The second major piece of Glamsterdam is EIP-7702, which addresses the user experience. Right now, Ethereum has two types of accounts: EOAs (like your MetaMask or Coinbase Wallet) and Smart Contracts (like Safe). EOAs are simple but limited. They can't batch transactions or pay gas in stablecoins, and losing your private key means your funds are gone forever. Smart contract wallets can do all of this, but migrating millions of users from EOAs to smart contract wallets is a massive hurdle.
EIP-7702 offers a clever middle ground. Originally proposed by Vitalik Buterin as a replacement for EIP-3074, it allows an EOA to temporarily adopt smart contract code for the duration of a single transaction. When you sign a transaction, you can include an authorization designator. This signature tells the network to run a specific piece of contract code on behalf of your EOA. Once the transaction completes, your account returns to its normal state.
This temporary upgrade unlocks several features that were previously exclusive to smart contract wallets. First, it enables gas sponsorship. A dapp can pay the gas fee for you, or you can pay the gas fee using USDC instead of ETH. Second, it allows transaction batching. Instead of signing three separate approvals and transactions to swap a token on Uniswap, you sign once, and the batched operations execute in a single block.
Unlike the older EIP-3074 proposal, which relied on permanent "invoker" contracts and raised security concerns, EIP-7702 is designed to be fully compatible with ERC-4337, the existing account abstraction standard. This compatibility ensures that the smart contract code applied to the EOA runs through the same entry point contracts that existing smart wallets use, maintaining a unified developer ecosystem.
What Devnet-5 is Actually Testing
Devnet-5 is where these ideas meet reality. Client teams like Geth, Nethermind, Besu, and Reth are using this test network to ensure their software can handle the new transaction types introduced by EIP-7702. The main challenge is state transition logic. When an EOA temporarily acts as a contract, the client needs to process that state change without introducing vulnerabilities or slowing down block production.
Security researchers are also closely watching devnet-5. Since EIP-7702 allows arbitrary code execution on standard accounts, client devs must ensure that malicious authorization signatures can't drain user wallets or trick users into signing away permanent control of their keys. The devnet allows teams to run fuzzing campaigns and simulate attack vectors before deploying to public testnets like Sepolia or Holesky.
Another area of focus is the gas pricing for EIP-7954. Deploying larger contracts means nodes must store and retrieve more data from the state trie. Developers are testing different gas models to ensure that the increased contract size doesn't lead to state bloat or slow down block propagation across the network.
We don't have a firm mainnet date for Glamsterdam yet. The success of devnet-5 will dictate the timeline. If client implementations prove stable and the security audits don't turn up any critical bugs, we will likely see the upgrade move to public testnets in the coming months, with a mainnet launch targeted for later in the year.
This hard fork shows a shift in how Ethereum scales. It's not just about rollups and layer-2s anymore. Core developers are actively cleaning up the execution layer to make the base network easier to build on and safer to use.
