We are welcoming you to our weekly digest! Here, we discuss the latest trends and advancements in account abstraction, chain abstraction and everything related, as well as bring some insights from Etherspot’s kitchen.
The latest news we'll cover:
- Ethereum Tests Native Rollups to Simplify Layer 2 Verification Model
- Native Account Abstraction Debate Intensifies Ahead of Hegota Fork
- ACDE #232: No Decision on Hegota Headliner as Native AA Debate Continues
- Vitalik Buterin Pushes “One-Click” Staking with DVT-Lite for Institutions
Please fasten your belts!
Ethereum Tests Native Rollups to Simplify Layer 2 Verification Model
Ethereum researchers have presented a proof-of-concept for “native rollups,” a new design that could simplify how Layer 2 networks are verified by moving parts of the process back onto Ethereum itself. The prototype, built using the Ethrex execution client, demonstrates how Ethereum could directly re-execute Layer 2 transactions instead of relying on external proof systems.
The experiment implements EIP-8079 and introduces a new mechanism called the EXECUTE precompile, which allows Ethereum’s base layer to replay Layer 2 blocks and verify their correctness natively. In this model, rollup transactions are submitted to Ethereum and executed within its own environment, while deposits, cross-layer interactions, and withdrawals are handled through onchain contracts and state proofs.
This approach contrasts with the current rollup ecosystem, where verification depends on either fraud proofs (optimistic rollups) or validity proofs (zero-knowledge rollups). Native rollups aim to remove this additional layer of complexity by letting Ethereum’s own state transition function handle verification, potentially reducing infrastructure overhead and simplifying long-term maintenance.
Developers behind the prototype, including contributors from the Ethereum Foundation and L2BEAT, demonstrated a full rollup lifecycle, from block submission to withdrawal validation. They emphasized that the system remains experimental and is not intended for production use at this stage.
One of the key advantages highlighted is tighter alignment with Ethereum’s upgrades. Because verification happens directly on the base layer, improvements to Ethereum would automatically apply to native rollups, eliminating the need for independent verification systems to keep pace.
Native Account Abstraction Debate Intensifies Ahead of Hegota Fork
Ethereum’s core developer community is currently debating competing approaches to native account abstraction (AA), with Frame Transactions (EIP-8141) and Tempo Transactions emerging as two contrasting design philosophies. The discussion, highlighted in ZeroDev’s (acq by Offchain Labs) article by Derek Chiang, comes as planning for the Hegota hard fork accelerates and multiple AA proposals are being evaluated as potential headliners.
The debate reflects a broader split in how AA should be implemented at the protocol level. Tempo Transactions follow a “user-first” philosophy, aiming to enshrine the most demanded features directly into the protocol. These include gas abstraction (such as paying fees in ERC-20 tokens), atomic batching, transaction automation, and alternative signature schemes. By embedding these features into transaction structure, Tempo aims to simplify integration and improve user experience with minimal complexity.
In contrast, Frame Transactions take a more flexible, developer-oriented approach. Rather than hardcoding features, EIP-8141 introduces a generalized transaction model where authorization and gas payment logic are handled by smart contracts. This is enabled through mechanisms like the APPROVE opcode, allowing arbitrary logic for signatures, permissions, and sponsorship. The design supports advanced use cases such as multisig, passkeys, privacy protocols, and conditional gas payments.
However, this flexibility comes with trade-offs. Frame Transactions introduce greater complexity across the stack, including more demanding mempool validation, tooling challenges, and increased implementation burden for wallets and developers. Tempo Transactions, while simpler, may lack extensibility and require ongoing protocol changes to support new use cases.
Recent discussions suggest efforts to bridge the gap between the two approaches. Proposed updates to Frame Transactions include support for EOAs via default accounts, simplified signature handling, and standardized transaction patterns to reduce complexity while preserving flexibility.
ACDE #232: No Decision on Hegota Headliner as Native AA Debate Continues
Ethereum core developers did not reach a final decision on the Hegota upgrade headliner during All Core Devs — Execution (ACDE) #232, instead opting to delay the call amid ongoing disagreements around native account abstraction (AA) and broader protocol complexity.
The meeting focused heavily on whether Frame Transactions (EIP-8141) should be selected as the headliner upgrade. While some teams supported moving forward, others expressed concerns around implementation complexity, particularly around mempool design, DoS resistance, and developer tooling. As a result, client support remained split, with no clear majority to justify headliner status.
A key takeaway was that uncertainty, not outright opposition, drove hesitation. Several client teams emphasized they need more clarity on how frame transactions would function in practice, especially regarding transaction validation rules and execution within the mempool. Others argued that committing to such a large change without fully defined constraints could introduce long-term technical debt or delay the fork.
Alongside the AA debate, developers also discussed EIP-8037 (state gas changes) for the upcoming Glamsterdam fork. Multiple participants flagged rising complexity in Ethereum’s gas model, with concerns that overlapping proposals could create inconsistencies and increase bug risk. Suggestions included moving toward a more “principled” multi-dimensional gas model, though this was deemed too large to finalize in the current timeline.
On the Hegota headliner decision itself, two candidates, Lucid (encrypted mempool) and SSZ-related proposals, were formally rejected, narrowing the choice to either Frame Transactions or no headliner at all. With most clients leaning toward no headliner, the default outcome currently favors proceeding without one.
However, given how close the discussion remains, developers agreed to revisit the decision in two weeks, allowing time for additional research, breakout discussions, and clearer alignment — particularly around mempool feasibility and real-world usability.
The outcome highlights a broader theme: Ethereum is approaching major architectural decisions, especially around account abstraction and scaling, with caution, prioritizing long-term robustness over short-term delivery.
Vitalik Buterin Pushes “One-Click” Staking with DVT-Lite for Institutions
Vitalik Buterin said the Ethereum Foundation has begun using a simplified form of distributed validator technology, known as DVT-lite, to stake 72,000 ETH, highlighting a broader push to make staking significantly easier for institutions. The funds were deployed in late February and are currently in the validator entry queue, expected to go live around March 19.
Buterin described DVT-lite as a practical middle ground between solo staking and full distributed validator setups. Instead of splitting keys across multiple machines like traditional DVT, DVT-lite allows multiple nodes to run using the same validator key. This reduces downtime risk if one node fails, while avoiding the operational complexity of full distributed systems.
He emphasized that simplifying infrastructure is critical for decentralization. “The idea that running infrastructure is this scary complicated thing… is awful and anti-decentralization,” Buterin noted, arguing that staking should be as simple as deploying a Docker container or similar one-click setup per node.
The long-term goal is to make distributed staking accessible to institutions without requiring deep technical expertise. By lowering the barrier to entry, Ethereum aims to increase validator participation while keeping control distributed across multiple operators rather than centralized providers.
The move also aligns with earlier discussions around integrating native DVT into Ethereum, allowing validators to operate without relying on a single machine. DVT-lite is positioned as an intermediate step toward that vision.
🐞 Etherspot: Pay-As-You-Go for AA tools on supported mainnets
Pay only for what your app uses on mainnet.
One RPC URL compatible with all tools.
Gas fees charged at network cost (no markup).
Secure API keys with CORS, IP, and Smart Account whitelisting.
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 (Twitter) and join our Discord.
❓Is your dApp ready for Account Abstraction? Check it out here: https://eip1271.io/
Follow us
Etherspot Website | X | Discord | Telegram | Github | Developer Portal


Top comments (0)