The latest news we’ll cover:
Please fasten your belts!
The EF Asks Developers to Check Glamsterdam Invariant
The Ethereum Foundation explained why the Glamsterdam fork on Hoodi was delayed, which we flagged over the past two weeks. During testnet testing, ChainSecurity found projects that would be vulnerable after Glamsterdam because they rely on gas invariants that EIP-8037 and EIP-8038 break, as those proposals rework how much gas is charged for certain operations and for state.
The response is a coordinated audit rather than a quiet fix. All Core Developers chose to delay the hardfork until the issues are resolved, while work on Hegotá continues in parallel, and the Foundation is engaging ChainSecurity and Dedaub alongside internal audits.
The scope is too large for the auditors alone. No team can cover every project on Ethereum, so the post is a call for contract developers and auditors to check their own code against eight specific invariants that Glamsterdam will break.
For our audience, this lands close to home. The repricing changes the state and gas assumptions that bundlers, paymasters, and smart account stacks depend on, so this is the moment for account abstraction infrastructure teams to run their contracts against the published invariant list.
Frame Transactions Put a Privacy Pool to the Test
Daniil Ankushin of Nethermind published a concrete measurement of a real privacy pool running on frame transactions, where the pool pays its own gas so a private withdrawal needs no relayer. Running soispoke’s minimal shielded pool on current Nethermind master, a withdrawal where the pool is the sender costs 679,322 gas.
Two drafts make this safe in the public mempool. With EIP-8250, the pool uses each note’s nullifier as a nonce key, so a reused nullifier is a reused nonce that the protocol rejects before the pool’s code runs, and with EIP-8272, the transaction checks the pool’s Merkle root against a recent-roots contract so a node never reads the pool’s storage.
Two things do not work yet. The proof check uses more than the EIP-8141 cap on validation gas, which a proposed change would turn into a shared mempool floor each node can raise, and a pool cannot yet pay for a call that comes from the user’s own address in one transaction.
That open case is a useful signpost. The author notes it mostly matters for plain EOAs, since smart accounts can already be driven by the pool-as-sender flow, and it is a clear look at exactly where native-AA privacy works today and where the spec still needs work.
A Draft Adds Protection to ERC-20 Accounts
A new draft proposes protected accounts, an opt-in per-account flag built into an ERC-20 token itself rather than a wallet. Small sends stay instant, anything larger is scheduled and can be cancelled by a pre-registered backup wallet, and a stress action sweeps the whole balance to that backup and locks it, which also helps against physical coercion.
The asymmetry is the core idea. Turning protection on is instant, while weakening it, by raising the limit, shortening the waits, or changing the backup, takes a delay the holder chooses, so a stolen key cannot both loosen the rules and drain the account at once.
Putting this in the token is what makes it broadly useful. Over-limit transferFrom reverts rather than silently failing, so routers and lenders cannot be fooled, and because the logic lives in the token it works for any holder and any wallet, including plain EOAs and EIP-7702 delegated accounts.
The thread shows the standards process working. A reviewer found a griefing attack where a stranger could write a long lock onto someone’s backup, and the author responded with a backup-acceptance step and an owner-only stress default, tightening the design before it advances. It is a token-level complement to the smart-account security work we track.
Consensys Launches a Cross-Ledger Stack
Consensys launched Sovereign Network Interoperability, a stack that lets banks settle transactions across independently operated blockchains without moving assets off their native ledgers. Announced at Devcon in Mumbai, it targets collateral mobility, securities settlement, and cross-currency payments.
The design is bridgeless by intent. Its Cross Ledger Interoperability Protocol uses zero-knowledge proofs so assets stay on their home ledgers while cross-ledger state and execution are verified cryptographically, and an institution specifies its requirements and approved counterparties while the software selects a route and coordinates execution.
It is built to speak several interoperability languages. The stack will support the Ethereum Economic Zone standard we covered recently, the Inter-Blockchain Communication protocol, and others, with EVM networks available now and Canton connectivity planned.
From a chain abstraction perspective, this is a familiar pattern at institutional scale. Coordinating execution across ledgers that each keep their own state, with cryptographic verification instead of a trusted bridge, is the same problem account and chain abstraction solve for users, now aimed at wholesale finance.
Start exploring Account Abstraction with Etherspot!
- Learn more about account abstraction here.
- Head to our docs and read all about Etherspot Modular SDK.
- 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/
Subscribe to Etherspot’s All About Abstraction Newsletter!
Get In Touch:
Website | X | Discord | Github | Telegram | Developer Portal
Powered by Etherspot