Dynamic Agent Execution, Glamsterdam & Hegotá Progress, EIP-8224 Enables Private Gas, Account Manager

Welcome to our weekly newsletter, where we unpack the latest in account and chain abstraction, and the broader infrastructure shaping Ethereum.

This week: Ethereum slows Glamsterdam while shaping Hegotá, ERC-8211 introduces dynamic execution for AI agents, new EIPs simplify sponsored and private transactions, and a new concept for a unified account manager across Web2 and Web3.

Ethereum’s April Checkpoint Shows Glamsterdam Slowing While Hegotá Takes Shape
Biconomy and Ethereum Foundation Back ERC-8211 for Dynamic Agent Execution
EIP-8223 Introduces a Simpler Path for Contract-Sponsored Gas
EIP-8224 Introduces Counterfactual Transactions for Private Gas
A Concept for an “Account Manager” Across Web2 and Web3

Please fasten your belts!

Ethereum’s April Checkpoint Shows Glamsterdam Slowing While Hegotá Takes Shape

Ethereum’s Protocol Support Team said Glamsterdam is moving forward steadily, but more slowly than hoped, as developers work through the complexity of enshrined proposer-builder separation (ePBS), gas repricings, and related execution-layer changes. The update frames Glamsterdam as a technically heavy fork, with ePBS requiring the protocol itself to handle partial blocks and two-party coordination, while Block-level Access Lists continue to reshape how gas and state access are handled.

On the execution side, developers are still pushing toward the first generalized Glamsterdam devnet, which would then be followed by several broader devnets that progressively include more non-headliner features. The update also notes growing ecosystem pressure to prioritize EIP-7954, which would increase the maximum contract size, alongside the existing repricing bundle.

For the following fork, Hegotá, the major feature selection is now complete. FOCIL (EIP-7805) has been chosen as the consensus-layer headliner, while account abstraction remains in scope as a non-headliner track after client developers failed to converge on a specific implementation for native AA. The report says EIP-8141 (Frame Transactions) was moved to Considered for Inclusion (CFI) status, leaving the door open for a broader AA proposal to gain support through further collaboration between client teams and the community.

The checkpoint also highlights growing interest in quantum resistance, though no standalone post-quantum proposal has yet been introduced. At the same time, gas-limit testing continues, with 60 million still the current baseline target while higher limits are explored through devnets and repricing work.

Biconomy and Ethereum Foundation Back ERC-8211 to Make AI Agent Execution More Dynamic

Biconomy has introduced ERC-8211, a proposed Ethereum standard for “smart batching” co-developed with the Ethereum Foundation under the EF’s Improve UX track. The proposal is aimed at AI agents and smart accounts that need to execute multi-step DeFi flows without locking every parameter at signing time, and it was published with a reference implementation, demo, and an open discussion thread on Ethereum Magicians.

The core idea is to fix the limits of static batching. In today’s model, an agent that wants to swap assets and then deploy the output elsewhere has to guess the intermediate amount in advance. ERC-8211 instead lets batches resolve some parameters at execution time, using fetchers to read live on-chain state, constraints to validate resolved values, and predicate entries to check whether conditions are satisfied before the next step continues.

That makes the proposal especially relevant for on-chain AI agents, which increasingly need to handle slippage, bridge fees, vault ratios, and other values that move block by block. The proposal is described as account-agnostic and compatible with existing standards such as ERC-4337 and ERC-7683, while also fitting into Ethereum’s broader agent stack alongside ERC-8004, ERC-8183, and x402.

The bigger takeaway is that Ethereum’s AI push is moving beyond identity and payments into execution. ERC-8211 does not create a new protocol upgrade by itself, but it does sketch a shared execution layer for agents that need to do more than simple transfers and swaps. If it gains traction, it could become an important building block for agent-native DeFi workflows on Ethereum.

EIP-8223 Introduces a Simpler Path for Contract-Sponsored Gas

EIP-8223 proposes a new sponsored transaction type that would let a contract at tx.to pay gas fees on behalf of a sender, using a canonical payer registry rather than arbitrary EVM execution. The draft was introduced on Ethereum Magicians on April 11 and is designed as a narrower, simpler path for contract-sponsored transactions.

The proposal uses a two-sided opt-in model. A payer contract would explicitly authorize one sender through a registry predeploy at 0x13, while the sender would opt in by using the sponsored transaction type. Sponsorship would only apply when the transaction is sent directly to the payer contract itself, so tx.to doubles as both execution target and gas payer.

A key part of the design is that validation stays static. Instead of running validation logic in the EVM, the protocol would rely on normal account reads plus a single storage read from the payer registry. The draft argues this keeps the format compatible with inclusion-list designs and statelessness-oriented work, while avoiding the added complexity of more programmable account abstraction proposals.

The intended use case is straightforward: smart contract accounts that want to pay their own gas when called, without forcing the controlling EOA to hold ETH or rely on an external relayer. To preserve existing Ethereum gas accounting behavior, the flow would still use standard EIP-1559 mechanics, with the payer funding the sender for escrow and the unused refund returning to the payer after execution.

The bigger significance of EIP-8223 is that it adds another option to Ethereum’s growing account abstraction debate. Rather than competing directly with broader proposals like Frame Transactions or Composable Transactions, it offers a tightly scoped sponsorship mechanism for cases where static validation is enough.

EIP-8224 for Counterfactual Transactions

A new draft proposal published on GitHub, EIP-8224, introduces a “counterfactual transaction” type designed to solve Ethereum’s private gas-bootstrapping problem for fresh EOAs. The idea is to let users fund gas from a private fee note without first receiving traceable ETH on-chain.

The draft proposes a new EIP-2718 transaction type, 0x08, built around zero-knowledge proofs against canonical fee-note contracts. A user would first deposit ETH into a fee-note contract and receive a private commitment, then later submit a transaction from a fresh EOA proving ownership of an unspent note large enough to cover gas. The protocol would verify the proof, consume the note’s nullifier, settle gas, and send any leftover ETH to a chosen refund recipient, while the transaction body itself executes normally.

A key part of the design is that validation is meant to stay mempool-safe and bounded. Instead of arbitrary EVM execution, the proposal relies on fixed cryptographic verification, code-hash recognition for fee-note contracts, and fixed storage reads. The draft also uses fflonk over BN254 and estimates a typical minimum intrinsic cost of roughly 222,000 gas.

The proposal is positioned as complementary to sponsored transaction work such as EIP-8223. In practice, it is framed as a one-shot privacy bootstrap: use a private fee note once to fund a smart account or initial setup, then rely on cheaper sponsored transactions afterward. The PR is still in draft status on GitHub, and the canonical fee-note bytecode, verification key, circuit artifacts, and cross-client test vectors have not yet been published.

A Concept for an “Account Manager” Across Web2 and Web3

A recent concept, published by Accountless, introduces an “account manager,” a standalone tool designed to give users one place to manage every account they control across Web2 and Web3. The proposal frames the product as neither a wallet nor a password manager replacement, but as a new layer that captures accounts as they are created, maps the credentials that protect them, monitors security over time, and shows what would break if a credential is lost or compromised.

The core argument is that users already manage Web2 and Web3 in separate mental models. Password managers catch new logins and store credentials for Web2, while wallets, seed phrases, signer sets, session keys, and recovery setups across chains usually remain fragmented. According to the post, this leads to blind spots around account discovery, stale recovery paths, signer rotation, session-key revocation, and the overall blast radius of a compromised credential.

To structure the problem, the post defines five user goals: knowing what accounts exist, staying secure without constant effort, changing credentials once and applying that change everywhere, onboarding new accounts without creating new security problems, and understanding exposure at any moment. It then maps the bad outcomes, root causes, and proposed solutions behind each one.

The proposed solution centers on an “account graph” that connects accounts and credentials in a many-to-many model. In that system, an account stores details like location, role, recovery path, linked accounts, and activity, while a credential tracks where it lives, when it was last used, and whether it is backed up. The post also outlines a phased product surface, starting with an extension and web app, and prototypes that move from read-only visibility to security monitoring and finally write operations, such as signer updates and revocations. You can explore the prototype here.

🛠️ Builder note: Etherspot

AA infra should make development easier, not harder.