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

The latest news we’ll cover:

• Ethereum Targets Four-Minute Finality

• Glamsterdam on Hoodi Is Postponed

• A Pre-ERC Defines a Safer EOA Migration Path

• Privacy Pools v2 Adds Payments and Yield

• ERC-8447 Proposes Agent Swarms

Please fasten your belts!

Ethereum Targets Four-Minute Finality

Ethereum researchers filed a draft aiming to cut the time a transaction takes to become final from about 16 minutes to roughly four. Ben Edgington, who coordinates the fast-finality research, filed it with Francesco D’Amato, Roberto Saltini, Yann Vonlanthen, and Mikhail Kalinin, with a four-fold improvement as the initial target.

The mechanism change is a vote split. Today each validator casts one vote that both helps pick the next block and helps lock older blocks in, so finality can only move as fast as that rotation, and the proposal gives each job its own vote so the locking-in can run on a faster clock.

The practical payoff is cheaper cross-chain movement. A transfer service that fronts funds on the other chain has money tied up until Ethereum finalizes, and the Foundation counts that idle capital as a real cost, so a service fronting $1 million an hour would hold about $267,000 waiting at 16 minutes but only about $67,000 at four.

There is a post-quantum angle too. The researchers say splitting the votes would make it easier to eventually swap in quantum-resistant signatures, though the design is unfinished, has no activation date, and many parts remain to be decided.

Glamsterdam on Hoodi Is Postponed

The Glamsterdam activation on the Hoodi testnet, which we flagged last week for October 26, has been postponed with no new date set. Core developers made the call at ACDE #248 to allow further investigation of how one of the gas-repricing changes interacts with mainnet smart contracts.

The specific concern is EIP-8037. That proposal raises and separately meters the cost of creating state, and the delay buys time to study its effects on deployed contracts before the change reaches a public testnet.

The rollback is clean rather than disruptive. It removes the scheduled execution and consensus activations and the gas-limit bump to 200 million, but it does not revert Hoodi’s chain history, and a replacement schedule will be announced later.

For our audience, the repricing is the part to keep watching. EIP-8037 and its companion EIP-8038 change the state assumptions that bundlers, paymasters, and smart-account stacks are built on, so the extra caution before activation is exactly the diligence this infrastructure needs.

A Pre-ERC Defines a Safer EOA Migration Path

A new pre-ERC lays out how an EOA can safely retire its key by adopting account code at its own address. It builds on EIP-8298, which lets an account adopt code through a SETCODEFROM operation, and EIP-8151, which makes ecrecover stop returning addresses that hold regular code, so together they stop an old secp256k1 key from authorizing anything without moving assets.

The danger is that adoption is one-way. There is no return to empty code, so the adopted code and the transaction that adopts it must be right the first time, and the author catalogs seven failure modes, most of them irreversible, including a self-recovery check that locks the account out the moment it is adopted.

The proposal answers with structure. It defines an adoption profile of requirements for the new code, a migration guard that reverts unless the old key signed the migration, the signed code was adopted, initialization ran, and ecrecover now rejects the old key, all in one transaction.

This is the plumbing behind the bunker-mode urgency we have covered. The reference kernel uses ERC-7913 verifiers for post-quantum keys and depends on EIP-8141 Frame Transactions, so it is a concrete path for an account to move to quantum-resistant authentication while keeping its address and assets.

Privacy Pools v2 Adds Payments and Yield

0xbow launched Privacy Pools v2, turning its privacy protocol from a deposit-and-withdraw tool into something closer to a private account, live across seven networks including Ethereum, Base, Arbitrum, and OP Mainnet. Once funds are shielded, a user can pay any EVM address while hiding who paid whom and how much, or request money through a shareable link.

Two additions make the pool somewhere to stay. Shielded deposits can now earn lending yield through Aave without leaving the pool, and a LI.FI integration lets users enter with nearly any asset, swap inside the pool, and exit into a different token or even a different chain.

The compliance model is unchanged. An association set provider still screens each deposit and can revoke approval, but there is no KYC and no viewing key, and anyone can ragequit by exiting publicly without permission.

For our readers, the account abstraction link is in the distribution. Every v2 feature is exposed through an SDK so wallets and payment apps can embed it, the Ethereum Foundation’s Kohaku wallet-privacy initiative is integrating it, and Ambire is among the first wallets on board, which is how shielded balances reach ordinary smart-account UX.

ERC-8447 Proposes Agent Swarms

A new draft, ERC-8447, proposes a registry and charter model for autonomous agents to form, bound, run, and dissolve swarms, recorded as one interoperable on-chain object. The author argues that existing agent standards cover the individual, the act, the decision, and the job, but none says what a group of agents actually is: who is inside, why it exists, how it is organized, and when it stops.

The design keeps the executable part small. A hashed spec freezes roles, phases, and authorities at formation, while the descriptive charter lives off-chain and versioned, and admission is two-sided, with an authority admitting and the member signing acceptance of the current charter.

Crucially, the kernel holds no value and does not define what an agent is. Members are simply accounts, while identity and trust information can be pulled from external registries such as ERC-8004. This keeps the core swarm logic simple and leaves agent eligibility to other parts of the stack.

The review has already made it safer. Contributors surfaced ways a member could flash-borrow a token balance to pass an eligibility check or reuse an approval across a phase change, and the author tightened the spec so modules read checkpointed rather than live balances and decisions are bound to the phase they were filed in. It is an early look at how on-chain agent coordination gets built on account abstraction primitives.

🛠️ Builder note: Etherspot

AA infra should make development easier, not harder.

• One RPC endpoint across chains
• Pay-as-you-go pricing on mainnet
• No markup on gas fees
• API key controls with built-in security

👉 Learn more

Start exploring Account Abstraction with Etherspot!

• Learn more about account abstraction here.
• Head to our docs and read all about Etherspot Prime.
• Skandha — developer-friendly Typescript ERC4337 Bundler.
• Arka — an open-source Paymaster Service for gasless & sponsored transactions.
• Explore our TransactionKit, a React library for fast & simple Web3 development.
• Follow us on X and join our Discord.

❓Is your dApp ready for Account Abstraction? Check it out here: https://eip1271.io/

Follow us

Website | X | Discord | Telegram | Github | Developer Portal

Powered by Etherspot

TransactionKit | Pillar Wallet | Case Studies