This week's highlights: - EIP-8411 tests sub-second block propagation - @ethlabs_org pitches a faster Ethereum as Base Splits on AA - Glamsterdam clears its 200M gas rehearsal - MATCHA explores private frames in the public mempool Read more👇go.etherspot.io/xBpGgTy

This week's highlights: - Ethereum commits to EIP-8141 for Hegotá - Base and Ethereum split on native AA, says @decentrek - @the_matter_labs’s Prividium is tested by the Bundesbank - @a16zcrypto makes the case for permissionless compliance Read more 👇 go.etherspot.io/5sba2eZ

Arka Paymaster gives dApps more flexibility over how transaction fees are handled, from sponsored transactions to custom gas policies. Learn more 👉 go.etherspot.io/1hwZaqX

This week's highlights: - ERC-8403 standardizes the account authority lifecycle - Vitalik links EIP-8141 to Ethereum's scaling roadmap - @Base Vibenet tests 200ms blocks and native AA - @RobinhoodCrypto blobs stop reaching Ethereum Read the full digest👇go.etherspot.io/xY3x8CD

This week's highlights: - EIP-8141 moves toward Hegotá inclusion - A composable approach to native AA from @pedrouid - Glamsterdam gas changes test account abstraction infrastructure - A post-quantum upgrade path for ecrecover Read more 👇 go.etherspot.io/ZaLvuQN

Etherspot explains: EIP-7906 EIP-7906 adds a post-execution assertion mechanism to EIP-8141 Frame Transactions. EIP-8141 introduces a native account abstraction transaction model for Ethereum. EIP-7906 extends that model with a new POST_TX frame that runs after the main transaction execution. The idea is simple: instead of only checking whether a transaction is allowed before it runs, an account can also check what actually happened after execution. New opcodes let the POST_TX frame inspect the transaction's state changes, including balance changes, storage changes, newly deployed contracts, emitted events, and more. This makes it possible to define conditions around the expected outcome of a transaction. For example, an account could require that a certain balance doesn’t decrease by more than an approved amount. If the result doesn't match the defined conditions, the transaction's execution can be reverted. In simple terms, EIP-7906 lets an account say: “Run this transaction, but only keep the result if it stays within the rules I approved.”

This week's highlights: - @Base makes the case for EIP-8130 across the EVM - @Ethereum opens the Platåberget testnet - Builders debate native account abstraction & wallet fragmentation - @Nethermind moves from LayerZero to @Chainlink Read more👇 go.etherspot.io/PsrF85R

This week's highlights: - Native AA Delayed Over L2 Concerns - ERC-4337 Retrospective by @leekt216 - EOA Migration Debate - Ethereum moves away from Poseidon Read more👇 go.etherspot.io/bROXk8O

Etherspot explains: ERC-8286 ERC-7579 introduced a modular smart account architecture, allowing developers to extend accounts with reusable validators, executors, hooks, and other modules. ERC-8286 brings that modular account model to EIP-8141 Frame Transactions, Ethereum's proposed native account abstraction model. Rather than creating a separate module system for Frame Transactions, it reuses ERC-7579 and adds only the validation flow they need. Validators return an approval mode that tells the account how to handle validation within the verification frame. The broader goal is a portable module ecosystem. A validator, executor, or hook written once can be reused across wallets and account abstraction implementations, whether they're built around ERC-4337 or EIP-8141.