DEV Community: Etherspot

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

Alexandra — Thu, 16 Apr 2026 09:16:27 +0000

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.

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 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

Post-Quantum Urgency, Ethereum Economic Zone, Glamsterdam Repricing

Alexandra — Thu, 09 Apr 2026 08:50:36 +0000

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

This week: Gnosis and Zisk propose an Ethereum Economic Zone to reconnect L2s, EIP-8037 stays in focus amid DevNet fixes, quantum research raises pressure on Ethereum and Bitcoin, and Base doubles down on payments and builders.

Gnosis and Zisk Launch Ethereum Economic Zone to Reconnect Layer 2s With Mainnet
Glamsterdam Repricing Call Keeps Focus on EIP-8037 as DevNet 3 Bugs Are Addressed
New Quantum Papers Sharpen Post-Quantum Pressure on Ethereum and Bitcoin
Base’s 2026 Roadmap Centers on Payments, Markets, and Builder Growth

Please fasten your belts!

Gnosis and Zisk Launch Ethereum Economic Zone to Reconnect Layer 2s With Mainnet

Gnosis and Zisk have unveiled the Ethereum Economic Zone (EEZ), a new framework backed by the Ethereum Foundation that aims to reduce fragmentation across Ethereum’s Layer 2 ecosystem and strengthen Ethereum mainnet’s role as the base economic layer.

The proposal argues that Ethereum’s rollup strategy has solved scaling, but created a new problem: every L2 has become its own silo, with separate liquidity, bridges, wallet integrations, and duplicated infrastructure. EEZ is designed as an L1<>L2 framework, not just another rollup stack, with the goal of making rollups extend Ethereum rather than branch away from it.

Its core feature is synchronous composability across Ethereum mainnet and participating EEZ rollups. In practice, that means a smart contract on one EEZ rollup could call a contract on Ethereum or another EEZ rollup, receive a response, and use it within the same transaction. The model is meant to enable atomic cross-chain execution, shared liquidity, and a more unified security environment.

The framework also keeps ETH as the gas token, settlement asset, and source of truth, rather than allowing participating rollups to pull value away into separate token economies. For protocols, the pitch is simpler deployment and less duplicated integration work. For users, the promise is a more seamless “one Ethereum” experience without constant bridging and chain-specific friction.

Gnosis and Zisk said technical specifications, benchmarks, tooling details, and integration paths will be published in the coming weeks. Founding alliance members include Aave, Titan, Beaver Build, Centrifuge, and xStocks, with the effort positioned as open-source, shared Ethereum infrastructure.

Glamsterdam Repricing Call Keeps Focus on EIP-8037 as DevNet 3 Bugs Are Addressed

Ethereum developers used the fifth Glamsterdam repricings call to focus almost entirely on EIP-8037, the proposal that raises state creation gas costs, while keeping broader repricing work on hold until updated benchmarking data is ready. The main priority was stabilizing Bolt DevNet 3, where client teams are still ironing out interoperability issues before launch.

The discussion centered on a small set of specification mismatches and implementation bugs that are currently blocking smooth DevNet 3 coordination. Spencer said another spec update would be released the same day with only limited adjustments, mainly to align the execution-spec code with the EIP markdown and reduce unnecessary back-and-forth between clients. Developers stressed that these should be treated as narrow fixes for DevNet 3, not a broader redesign of the proposal.

Several technical edge cases were reviewed, including how state gas is consumed in failed CREATE and CREATE2 paths, when static call checks occur, and whether state gas should be returned to a parent frame after failures. The broad direction from the call was to avoid adding the larger “state gas refill on failure” change to DevNet 3, and instead leave that debate for later, most likely DevNet 4.

Maria argued that state gas should represent the long-term cost of actual state growth, meaning it should ideally only be charged when new state is truly created. Still, participants agreed that changing this behavior affects deeper EVM gas semantics and needs more review before being adopted. To move that forward, Maria said she would open a fuller discussion on Ethereum Magicians so teams can compare options in detail before the next devnet cycle.

New Quantum Papers Sharpen Post-Quantum Pressure on Ethereum and Bitcoin

Justin Drake said two newly released papers mark a major shift in the quantum threat discussion, arguing that recent advances in Shor’s algorithm and hardware-specific optimization make the case for post-quantum migration more urgent.

His warning is grounded in two fresh papers: a Google Quantum AI paper on breaking secp256k1-style elliptic curve cryptography more efficiently, and an Oratomic/Caltech paper estimating much lower qubit requirements for a neutral-atom implementation.

The Google paper is the firmer of the two from a fact-checking standpoint. It estimates that attacking the 256-bit elliptic curve discrete logarithm problem could require fewer than 1,200 logical qubits and fewer than 90 million Toffoli gates, and that on superconducting architectures the attack could run in minutes with under 500,000 physical qubits. That broadly matches Drake’s summary, including his point that the work targets the signature systems used by Bitcoin and Ethereum.

The second paper is more aggressive and should be treated more cautiously, as Drake himself noted. The Oratomic/Caltech paper says Shor’s algorithm could run with as few as 10,000 reconfigurable atomic qubits, and that a 26,000-qubit system could solve ECC discrete logs in a few days on a neutral-atom architecture. That supports the broader claim that resource estimates are falling fast, even if the exact timeline to a cryptographically relevant machine remains uncertain.

For Ethereum, the takeaway is not that Q-Day has arrived, but that the margin for delay is shrinking. The papers do not prove a break is imminent, yet they do strengthen the case for accelerating account abstraction, key migration, and post-quantum planning before the threat becomes operational rather than theoretical.

Base’s 2026 Roadmap Centers on Payments, Markets, and Builder Growth

Base has outlined its 2026 mission, vision, and strategy, framing the next phase of its roadmap around three priorities: building global markets, scaling payments and stablecoins, and becoming the home for builders. The post positions Base as infrastructure for a broader onchain economy, building on what it described as major 2025 growth across trading, stablecoins, apps, and ecosystem funding.

On the markets side, Base says it wants to upgrade the chain with market-specific infrastructure, support new ERCs for smart accounts and tokens, and scale toward sub-second settlement at sub-cent cost. It also says it wants Base to host a wider range of assets and market types, including equities, commodities, tokenized assets, predictions, perpetuals, and spot trading.

For payments, Base is doubling down on stablecoins after reporting more than $17 trillion in stablecoin volume across 26 local currencies and 17 countries in 2025. Its 2026 plan includes privacy primitives, native account abstraction, stablecoin gas payments, and protocol-level support for memos, policies, and rewards, alongside deeper liquidity for stablecoin borrowing, lending, and trading.

Base is also expanding its builder strategy with a strong focus on agents and developer growth. The roadmap highlights agent-native smart accounts, tooling such as CLI and MCP access, support for standards like x402, and growth programs including Base Batches, builder councils, ERC-8021 builder codes, analytics dashboards, and liquidity incentives.

Taken together, the strategy shows Base leaning harder into a thesis that onchain infrastructure is moving beyond crypto-native use cases and toward a unified economy built around tokenized markets, internet-native money, and AI-driven participation.

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

Frame Transactions Debate, Post-Quantum Ethereum Challenge, BitGo & ZKsync, ACDE #233

Alexandra — Thu, 02 Apr 2026 11:05:28 +0000

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

This week: Frame Transactions (EIP-8141) spark headliner debates, post-quantum risks push AA urgency, ACDE #233 keeps native AA alive, and BitGo × ZKsync move deeper into institutional onchain infrastructure.

EIP-8141 Debated as Potential Headliner for Next Ethereum Fork
Ethereum Faces Post-Quantum Challenge as “Q-Day” Timeline Moves Closer
ACDE #233 Keeps Frame Transactions Alive While Delaying Hegotá Headliner Choice
BitGo and ZKsync Partner on Tokenized Deposit Infrastructure for Banks

Please fasten your belts!

EIP-8141 Debated as Potential Headliner for Next Ethereum Fork

Ethereum developers held a headliner breakout call on EIP-8141 (Frame Transactions), focusing on implementation challenges and its potential role as the next major upgrade centerpiece.

The discussion centered on mempool integration, with teams exploring multiple strategies for handling Frame Transactions, particularly around paymaster design, transaction validation, and EVM-level restrictions. Approaches ranged from precompiles and delegation models to cryptographic validation schemes, reflecting ongoing debate about complexity versus flexibility.

Developers also raised concerns about usability and clarity, prompting calls to simplify the approval mechanism within the proposal. Contributors agreed to refine the specification and explore more restrictive, whitelist-based mempool strategies.

The call concluded with EIP-8141 advanced to “considered for inclusion” (CFI) for the Hegotá hardfork, with any headliner decision deferred to the subsequent All Core Devs meeting.

Ethereum Faces Post-Quantum Challenge as “Q-Day” Timeline Moves Closer

Ethereum developers are increasingly focused on post-quantum readiness, as new projections suggest a potential “Q-Day” as early as 2029, accelerating the urgency around upgrading wallets, infrastructure, and security models.

The Ethereum Foundation’s roadmap highlights that the main risk is not just broken cryptography, but the complex coordination required to migrate a live financial system. Vulnerabilities are concentrated across multiple layers, including user wallets, exchanges, bridges, custodians, and validator keys — all of which require different upgrade paths.

A key solution is account abstraction, which allows users to transition away from traditional cryptographic signatures without requiring a full network reset. Existing infrastructure like ERC-4337 smart wallets provides a foundation, though adoption remains partial relative to Ethereum’s total user base.

Particular concern lies in bridges and custodial systems, where large amounts of capital are secured by a limited number of keys. These areas are already frequent attack vectors and will require early migration to mitigate both current and future risks.

Another emerging issue is dormant wallets that cannot upgrade themselves. Ethereum may eventually face a governance decision on whether to leave these funds vulnerable or introduce measures such as freezing them, raising complex questions around decentralization and user rights.

While the cryptographic transition is expected to take years, the operational and political challenges are already underway, with post-quantum readiness becoming a growing factor in security, market trust, and institutional adoption.

ACDE #233 Keeps Frame Transactions Alive While Delaying Hegotá Headliner Choice

Ethereum core developers used ACDE #233 to make a key process decision for the Hegotá fork: EIP-8141 Frame Transactions was not selected as the execution-layer headliner, but it was also not dropped. Instead, the proposal was moved forward as CFI, keeping it in active consideration while developers continue refining native account abstraction.

The call showed broad agreement that account abstraction is now a priority, even if there is still disagreement on the exact path. Supporters argued that native AA is long overdue, that Ethereum risks falling behind on user experience, and that Frame Transactions could unlock more than just alternative signatures, including atomic batching, sponsored transactions, privacy-preserving flows, and future post-quantum migration paths. Several participants stressed that Ethereum should stop postponing hard but important upgrades.

At the same time, client teams remained divided on whether Frame Transactions is mature enough to justify headliner status. Concerns focused on mempool complexity, implementation risk, and whether the current proposal delivers too much flexibility at once. Some developers preferred a narrower or more incremental route, while others said the proposal should continue through experimentation rather than be tied to the fork’s critical path.

In practice, the result was a compromise. Hegotá will proceed without an EL-specific headliner for now, but Frame Transactions remains very much alive. By giving EIP-8141 CFI status, developers signaled that native AA deserves serious ongoing work and that the discussion is now shifting from whether to prioritize the topic to how to shape it into something shippable.

BitGo and ZKsync Partner on Tokenized Deposit Infrastructure for Banks

BitGo and ZKsync have announced a partnership to build tokenized deposit infrastructure aimed at bringing traditional banks onchain while maintaining regulatory compliance.

The solution combines BitGo’s institutional custody and wallet services with ZKsync’s Prividium, a permissioned and privacy-focused blockchain developed by Matter Labs. The joint platform is designed to allow banks to issue, transfer, and settle tokenized deposits within existing regulatory frameworks.

Currently in testing, the infrastructure targets a growing demand among financial institutions for programmable payments without relying on public stablecoins. Unlike stablecoins, tokenized deposits keep funds within the banking system, offering a more familiar and compliant pathway for adoption.

The initiative reflects a broader trend of crypto infrastructure providers packaging end-to-end, compliance-friendly solutions to lower the barrier for institutional entry into blockchain-based finance.

A wider rollout is expected later this year as testing with regulated partners continues.

🛠️ 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 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

Encrypted Frame Transactions Target MEV Protection, Glamsterdam Progress, ERC-8004 Growth, Tempo Mainnet, x402 Identity Layer

Alexandra — Thu, 26 Mar 2026 12:01:22 +0000

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

This week: Ethereum research pushes toward real MEV protection, agent ecosystems scale faster than their utility, and payments infrastructure shifts toward machine-native design.

Encrypted Frame Transactions Aim to Bring Same-Slot MEV Protection to Ethereum
ACDC #176: Glamsterdam Devnets Progress as Hegota Timeline Depends on EL Decision
ERC-8004 Hits 130K Agents as Onchain AI Ecosystem Expands
Tempo Launches Mainnet with Focus on Stablecoin Payments and AI Agent Commerce
x402 Payments May Need “Proof of Human” Layer to Prevent Abuse

Please fasten your belts!

Encrypted Frame Transactions Aim to Bring Same-Slot MEV Protection to Ethereum

Ethereum researchers have proposed “encrypted frame transactions,” a new design that could significantly reduce MEV extraction by hiding critical transaction data until after block ordering is finalized.

At its core, the approach separates ordering from execution. Builders must first commit to the full list and order of transactions in a block before any decryption keys are revealed. Only after this commitment do transactions get decrypted and executed, within the same slot, preventing builders or searchers from exploiting transaction details during ordering.

The design builds on Frame Transactions (EIP-8141), which replace fixed authorization logic with programmable validation via VERIFY frames. This allows transactions to selectively hide execution details — such as calldata, contract targets, or fees — while still proving validity upfront. It also opens the door to more advanced features like post-quantum-compatible signatures and flexible permission systems.

Unlike earlier proposals, such as LUCID, which rely on next-slot execution and separate encrypted lanes, encrypted frame transactions enable same-slot encrypted execution without restructuring the block. Encrypted and plaintext transactions can coexist in a single ordered flow, simplifying integration while preserving privacy guarantees.

The system relies on a key-releaser model, where decryption keys are revealed only after the block is committed. These keys can be released by users themselves, delegated to committees, or handled by external entities. Validators then verify that decrypted data matches pre-committed hashes, ensuring correctness without exposing sensitive information prematurely.

However, the design introduces new trade-offs. Builders must commit to ordering without knowing full transaction contents, increasing execution risk. There are also unresolved challenges around reveal timing, mempool rules, and the “free option” problem, where users may choose not to reveal keys if execution becomes unfavorable.

📅 Worth attending: ACDE #233

All Core Devs — Execution (ACDE) #233 is happening this Thursday (March 26) at 14:00 UTC and may include a decision on EIP-8141.

If you’re following native account abstraction, this call is worth joining, especially if you want to voice support for its inclusion.

👉 Zoom link.

ACDC #176: Glamsterdam Devnets Progress as Hegota Timeline Depends on EL Decision

Ethereum consensus-layer developers focused on Glamsterdam devnet progress and Hegota planning during All Core Devs — Consensus (ACDC) #176, with discussions highlighting steady progress on testing alongside key dependencies on execution-layer decisions.

A major focus was the status of Glamsterdam devnets, particularly early testing environments like epbs-devnet-0, which had a “rocky start” but is now considered reasonably stable. Developers are continuing to evaluate what’s needed for subsequent devnets, including resolving outstanding specification issues and improving readiness for broader testing.

Several technical workstreams are advancing in parallel. These include progress on enshrined PBS (ePBS), updates to PTC (Payload Timeliness Committee) mechanisms, and ongoing work around SSZ-based Engine API, which aims to improve communication between execution and consensus layers. Additional efforts like JWT secret standardization are also being explored to streamline client interoperability.

On the roadmap side, developers discussed how Hegota upgrade planning depends heavily on execution-layer decisions — particularly the selection of a headliner EIP. The consensus layer is effectively waiting for that decision before opening the window for non-headliner proposals, signaling tight coordination between EL and CL roadmaps.

The call also followed an earlier async coordination on March 5, reflecting a growing trend of handling some protocol discussions outside of live calls to accelerate iteration.

Overall, ACDC #176 signals incremental but steady progress toward Glamsterdam, while reinforcing that major architectural decisions, especially around account abstraction, will shape the timeline and scope of the next Ethereum fork.

ERC-8004 Hits 130K Agents as Onchain AI Ecosystem Expands

The ERC-8004 community wrapped up its “Genesis Month” with a two-hour event highlighting rapid adoption and early experimentation around on-chain AI agents and agent registries.

According to contributors, ERC-8004 has grown into one of the most active distributed agent registries, now tracking ~130,000 agents across more than 20 EVM chains, with over 97,000 verified entries after filtering. The ecosystem has also expanded beyond Ethereum-compatible networks, with the first non-EVM implementation now live, alongside multiple independent audits contributed by the community.

The initiative has been built entirely through open collaboration, with contributions spanning chains, infrastructure providers, developers, and tooling teams. This has led to the emergence of early use cases such as agent identity, discovery systems, agent-to-agent payments, task marketplaces, and DeFi or trading agents.

Despite the growth, participants emphasized that agent economies remain in an early stage, with limited revenue generation so far. The community identified three key challenges moving forward: improving real-world usefulness, addressing security risks like spoofed or malicious agents, and developing better data and reputation systems to evaluate agent performance.

Several live implementations were showcased during the event, including integrations with existing agent frameworks and registries, as well as applications enabling self-custodial agent marketplaces and autonomous interactions.

Looking ahead, the ERC-8004 roadmap focuses on strengthening its role as a discovery layer for agent services, improving reputation mechanisms, and enabling richer data infrastructure. The next phase aims to drive practical utility, trust, and interoperable standards across emerging agent ecosystems.

Press enter or click to view image in full size

Tempo Launches Mainnet with Focus on Stablecoin Payments and AI Agent Commerce

Tempo has officially launched its mainnet, positioning itself as a blockchain infrastructure purpose-built for real-world payments at internet scale, with a focus on stablecoins, high throughput, and predictable fees.

The network is designed to address limitations in existing blockchains, where fluctuating fees and constrained throughput make them less suitable for high-frequency payment use cases. Tempo instead emphasizes instant settlement, low and predictable costs, and global availability, particularly for large-scale transaction flows.

Alongside the launch, the team introduced the Machine Payments Protocol (MPP), an open standard for programmatic payments co-authored with Stripe. The protocol enables machines, such as AI agents or services, to request, authorize, and settle payments automatically, without relying on custom integrations for each service.

While MPP runs on Tempo, it is designed to remain payment-rail agnostic, with extensions already supporting cards, wallets, and even Bitcoin via the Lightning Network.

A core use case highlighted is the rise of agentic payments, where autonomous systems execute workflows that require continuous transactions, such as paying for APIs, compute, or data.

These environments often involve dozens or hundreds of micro-transactions, exposing inefficiencies in traditional payment systems and existing blockchain infrastructure. Tempo aims to support this model through native primitives like payment “sessions,” which allow streaming payments and batch settlement.

The platform also launched a payments directory, enabling agents to discover and transact with services programmatically. At launch, it includes over 100 integrations across infrastructure, data, and compute providers.

With public RPC access now available, developers can begin building directly on Tempo mainnet, particularly for applications requiring high-frequency, programmatic, and cross-border payment flows.

x402 Payments May Need “Proof of Human” Layer to Prevent Abuse

As the x402 HTTP payment standard gains traction, developers are highlighting the need for an additional layer: “proof of human” to address identity and Sybil resistance.

While x402 enables programmatic payments for APIs and web services without accounts or API keys, it only proves a request can pay, not whether it comes from a real user or automated bot networks.

A proposed solution is combining payments with privacy-preserving identity proofs, such as zero-knowledge-based credentials, allowing users to prove uniqueness or eligibility without revealing personal data.

The combination could improve fairness in online markets, enabling use cases like bot-resistant ticket sales, rate-limited API access, and more secure agent-driven commerce, positioning “proof of human” as a potential extension to the emerging x402 ecosystem.

🛠️ 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 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

Ethereum Tests Native Rollups, Vitalik Pushes One-Click Staking, Native Account Abstraction, ACDE #232 Delays Hegota

Alexandra — Thu, 19 Mar 2026 11:42:23 +0000

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.

👉 Learn more

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

Vitalik Sanctuary Tech Vision, EOA Path for AA, Programmable Smart Accounts, ERC-8004 Agent Stack

Alexandra — Thu, 12 Mar 2026 13:28:55 +0000

The latest news we'll cover:

Vitalik Buterin Urges Ethereum to Focus on “Sanctuary Technologies”
EIP-8141 Breakout Focuses on EOA Support as Adoption Debate Intensifies
JAW Launches Programmable Smart Accounts with ERC-4337 Infrastructure
Ethereum Publishes ERC-8004 Resources as Trustless AI Agents Gain Momentum

Please fasten your belts!

Vitalik Buterin Urges Ethereum to Focus on “Sanctuary Technologies”

Vitalik Buterin said Ethereum should expand its mission beyond finance and help build what he calls “sanctuary technologies.” In a detailed post, he noted two growing concerns he hears frequently: the direction of the world — including rising surveillance, geopolitical conflict, corporate power, social media polarization, and AI risks — and the perception that Ethereum has played only a limited role in improving everyday life on issues like freedom, privacy, digital security, and community self-organization.

Buterin said acknowledging problems is easy, but proposing practical solutions is harder. While financial freedom remains important, he argued it cannot address deeper structural risks alone. At the same time, Ethereum is not suited to “fix the world” through centralized power. Instead, its realistic contribution is enabling resilient digital infrastructure.

He proposed that Ethereum should be part of an ecosystem creating open, decentralized tools that let people live, work, communicate, manage risk, build wealth, and collaborate while remaining resistant to outside pressure. The goal is not to move all governance and finance fully on-chain, but “de-totalization” — preventing total control by winners and preventing total collapse for losers. In this framing, Ethereum provides neutral digital space where durable social and economic structures, such as money, multisigs, markets, and governance systems, can exist without owners.

The post triggered broad discussion among builders and commentators. Supporters said the “sanctuary tech” framing clarifies Ethereum’s role as neutral infrastructure that protects privacy, coordination, and resilience rather than chasing speculation.

Privacy advocates stressed that sanctuary systems only work when protections are built into protocol design. Others linked the vision to DeFi credit markets, decentralized social platforms, NFTs, and encrypted messaging as early examples.

Critics argued that blockchains cannot solve deep societal problems and warned against overstating Ethereum’s impact.

EIP-8141 Breakout Focuses on EOA Support as Adoption Debate Intensifies

The March 5 breakout call on EIP-8141 Frame Transactions centered on one practical question: whether native support for EOAs should be added to improve adoption. The discussion followed concerns raised on All Core Devs that frame transactions, in their current form, may be too dependent on smart-account adoption and too distant from the existing EOA user base.

A key proposal was to update the specification so that if a frame transaction targets an account with no deployed code, clients would apply a default verification path for EOAs only within that transaction context. Derek from ZeroDev argued that a major blocker for account abstraction today is that most existing Ethereum users cannot benefit from it without first moving to a new account or setup flow. In his view, adding EOA support would make frame transactions more useful by enabling features such as sponsored transactions and token-based gas payments for a much wider set of users.

Several speakers said the proposal could improve EIP-8141’s adoption story, especially for wallets and applications that do not want the complexity of 7702 delegations or custom account implementations. Others clarified that this would not mean permanently inserting code into EOAs. Instead, the behavior would apply only within the frame transaction itself.

The call also covered overlap with EIP-7702, hardware wallet support, mempool policy, validation performance, and long-term post-quantum migration. Some participants warned that too much flexibility could recreate earlier account abstraction problems, while supporters argued frame transactions offer a more extensible path by moving signature logic out of the protocol.

By the end of the discussion, organizers said there appeared to be meaningful support for exploring a default EOA path, though the exact implementation still needs further work.

JAW Launches Programmable Smart Accounts with ERC-4337 Infra

JAW.id has launched its programmable smart account infrastructure built on Ethereum standards, combining ERC-4337 account abstraction with EIP-7702 delegation. The team positions the release as a production-ready stack that separates accounts from private keys and enables constrained, replaceable signers secured in device enclaves.

The core account contract, JustanAccount.sol, supports multi-owner setups with both ECDSA and WebAuthn (P-256) signers and is ERC-7739 compliant. Existing EOAs can delegate to the account via EIP-7702, enabling both native ERC-4337 usage and a migration path from traditional wallets.

Identity is ENS-native. Each account receives a human-readable subname at creation through ENS via JustaName, removing separate naming steps and making identities portable across the ENS ecosystem.

Infrastructure runs on self-hosted Etherspot Skandha bundlers for UserOperation processing, with ERC-20 gas sponsorship via Pimlico paymasters, enabling stablecoin gas payments.

A dedicated permission layer (JustaPermissionManager) operates as an account owner, granting time-bound and revocable permissions scoped by contract, function selector, and token spending limits.

JAW.id introduces three signer modes: cross-platform passkeys with E2E encryption, app-specific passkeys for white-label integrations, and a headless account class for server-side or agent workflows. Multiple concurrent sessions are supported, including parallel dApp usage and cross-chain owner synchronization.

Developer tooling includes an EIP-1193 provider, wagmi connector, EIP-5792 batching, and AI-ready integrations via an LLM spec and CLI tooling.

Ethereum Posts ERC-8004 Resources as Trustless AI Agents Gain Momentum

Ethereum has published a curated list of 34 resources for developers building with ERC-8004, signaling that trustless AI agents are becoming a major focus area across the ecosystem. Framed as a practical starter pack for exploring, building, and deploying agentic services, the collection spans education, research, marketplaces, discovery tools, and developer infrastructure.

The post presents ERC-8004 as the trust layer for the emerging “internet of agents.” Ethereum describes the standard as the missing piece that turns AI agents from isolated code into accountable economic actors by giving them portable identity, onchain reputation, and verifiable execution. In that framing, agent commerce without ERC-8004 remains fragmented, with reputations locked inside individual platforms.

At the core of the standard are three registries: an identity registry for verified agent metadata and endpoints, a reputation registry for immutable feedback, and a validation registry for proving that work was completed correctly. Together, Ethereum argues, these create a global directory where agents can discover, evaluate, and coordinate with one another across organizational boundaries.

The resource list itself shows how quickly the ecosystem around ERC-8004 is expanding. It includes official documentation from 8004.org, research from the Ethereum Foundation’s dAI team, tutorials from MetaMask, Phala, and Pinata, discovery layers such as 8004Scan, and marketplaces and coordination tools from teams like Autonolas, Supermission, and Towns Protocol.

The broader message is clear: AI agents are no longer being treated as a side narrative. Ethereum is actively positioning ERC-8004 as foundational infrastructure for an open AI economy, and the publication of a large ecosystem resource map shows that this is moving from concept into active builder coordination.

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

Ethereum’s 2029 Strawmap, Hegota Smart Accounts, Native Key Delegation, Protocol-Level AA

Alexandra — Thu, 05 Mar 2026 09:21:30 +0000

The latest news we'll cover:

Ethereum Foundation Drafts Seven-Fork “Strawmap” Through 2029
Vitalik Buterin Targets Hegota Fork to Deliver Ethereum Smart Accounts
EIP-8164 Proposes Native Key Delegation for Ethereum EOAs
EIP-8141 Proof of Concept Demonstrates Native AA at Protocol Level

Please fasten your belts!

Ethereum Foundation Drafts Seven-Fork “Strawmap” Through 2029

Ethereum core researchers have published a draft “strawmap” outlining a long-term vision for Ethereum layer-1 upgrades through 2029, targeting faster finality, native privacy, post-quantum cryptography, and gigagas-level throughput. The framework, introduced by Justin Drake, sketches seven forks over the next four years, assuming a rough cadence of one upgrade every six months.

Drake described the strawmap as an invitation to view L1 protocol upgrades through a holistic lens rather than fork-by-fork planning. The document places consensus, data, and execution layer upgrades on a unified visual timeline to surface dependencies and long-term coordination challenges that may not be visible in shorter-term planning cycles.

The roadmap defines five “north stars” for Ethereum’s base layer: faster user experience via shorter slots and finality measured in seconds; gigagas L1 throughput (~1 gigagas per second, or roughly 10,000 TPS) through zkEVMs and real-time proving; teragas L2 scaling via data availability sampling; durable post-quantum cryptography based on hash-based schemes; and first-class privacy through shielded ETH transfers.

One of the most significant proposed shifts is moving from the current Gasper consensus mechanism toward a one-round Byzantine Fault Tolerant (BFT) design known as “Minimmit,” aimed at reducing slot times and shrinking finality from today’s ~16 minutes toward single-digit seconds. Vitalik Buterin called the strawmap “a very important document,” suggesting slot times could be reduced incrementally (12 → 8 → 6 → 4 → 3 → 2 seconds) while maintaining safety through improvements such as optimized peer-to-peer networking and erasure coding.

The roadmap also pairs faster consensus changes with a transition toward post-quantum hash-based signatures and STARK-friendly cryptography. Buterin noted that slot-level quantum resistance could potentially arrive before finality-level changes, allowing the chain to continue operating even if quantum breakthroughs undermine existing finality guarantees.

The strawmap originated as a discussion starter at an Ethereum Foundation workshop in January 2026 and is explicitly framed as a living, non-official document. Drake emphasized that it is not a prediction but an accelerationist coordination tool, acknowledging that roadmapping in a decentralized ecosystem remains inherently provisional. Updates are expected at least quarterly as research, governance discussions, and ecosystem feedback evolve.

Vitalik Buterin Targets Hegota Fork to Deliver Ethereum Smart Accounts

Vitalik Buterin said Ethereum’s long-awaited smart accounts will ship “within a year” as part of the upcoming Hegota hard fork, marking a major milestone for account abstraction on the network.

Speaking over the weekend, Buterin noted that Ethereum has been discussing account abstraction since 2016. He pointed to EIP-8141 as an “omnibus” proposal designed to resolve the remaining challenges that account abstraction was meant to address, with deployment targeted for this year under Hegota.

The upgrade introduces “frame transactions,” where a transaction becomes a sequence of frames that can reference each other’s data. Individual frames can authorize a sender or gas payer, enabling more flexible execution logic. In practice, this allows externally owned accounts to function with smart contract-like capabilities without forcing users to migrate to entirely new wallet infrastructure.

Under this model, smart accounts can support multisignature setups, quantum-resistant wallets, and changeable keys through validation and execution frames. Gas payments in non-ETH tokens can be handled via paymaster contracts or decentralized exchange mechanisms that source Ether in real time, without intermediaries.

EIP-8164 Proposes Native Key Delegation for Ethereum EOAs

A new Ethereum Improvement Proposal, EIP-8164, is currently in draft status, introducing “Native Key Delegation for EOAs” as an extension of the delegation designator framework established in EIP-7702.

Authored by Gregory Markou and James Prestwich, the proposal would allow externally owned accounts (EOAs) to permanently replace secp256k1 ECDSA authentication with alternative signature schemes, starting with Ed25519. The mechanism uses a new 0xef0101 code prefix to designate an account whose authentication key is embedded directly in its code field. Once activated, the original ECDSA key is rendered permanently invalid at the protocol level.

The EIP introduces a new typed transaction (0x05) supporting both ECDSA-signed key migration and Ed25519-authenticated transaction origination. It also defines gas costs, strict Ed25519 verification rules, and an irreversible ECDSA rejection rule for converted accounts.

A notable feature is a “crafted-signature” method enabling creation of provably rootless accounts, where no ECDSA private key ever existed. The proposal frames this as groundwork for future post-quantum signature schemes within the reserved 0xef01XX namespace.

EIP-8141 Proof of Concept Demonstrates Native AA at Protocol Level

Harry Jeon has released a proof-of-concept implementation of EIP-8141, showcasing how “frame transactions” could enable native account abstraction directly at the Ethereum protocol level.

The PoC includes a modified go-ethereum (geth) client, a custom Solidity compiler fork, new EVM opcodes, and reference smart accounts ranging from minimal wallets to a modular Kernel architecture. Unlike ERC-4337, which relies on an EntryPoint contract and bundlers, EIP-8141 introduces a new typed transaction that allows accounts to define validation, execution, and gas payment logic using ordered “frames” executed by the protocol itself.

Frame transactions separate concerns into modes such as VERIFY, SENDER, and DEFAULT, with strict read-only constraints during validation. The implementation also includes ERC-7562-style mempool validation rules and a dedicated frame transaction pool.

Two case studies highlight practical implications: an ERC-20 paymaster design and a modular Kernel account port. Gas benchmarks on a local devnet suggest 24%–43% reductions compared to equivalent ERC-4337 setups, primarily by removing EntryPoint overhead.

The repository is explicitly labeled as research-only and unaudited. Proposed future work includes post-quantum signature integration, refined gas accounting for paymasters, and further mempool performance analysis.

🐞 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.

👉 Learn more

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

EIP-8151 Key Deactivation on Ethereum, Vitalik’s Cypherpunk Layer Vision, Base Stack Shift, 7702 Delegation Checker

Alexandra — Thu, 26 Feb 2026 09:04:42 +0000

The latest news we'll cover:

EIP-8151 Proposes Private-Key Deactivation Awareness for ecRecover
EIP-7851 Advances Key Deactivation for Delegated EOAs
Vitalik Buterin Pushes Cypherpunk Ethereum Layer
Coinbase-Backed Base to Move Off OP Stack
Curvegrid Launches EIP-7702 Delegation Checker App

Please fasten your belts!

EIP-8151 Proposes Private-Key Deactivation Awareness for ecRecover

A new proposal, EIP-8151, has been introduced on the Ethereum Magicians forum to modify the ecrecover precompile so that it becomes aware of private-key deactivation under EIP-7851. The draft, authored by Colinlyguo and published on February 9, 2026, aims to close a gap created by the interaction between delegated EOAs and key deactivation mechanisms.

EIP-7851 allows delegated externally owned accounts (EOAs) to deactivate their private keys. However, ecrecover is a stateless precompile: even if a key is deactivated at the protocol level, on-chain signature verification using ecrecover will still return the original address for valid signatures. This creates inconsistencies for contracts that rely on signature-based authorization.

According to the proposal, EIP-8151 would modify ecrecover so that after recovering a public key, the precompile checks whether the corresponding address has been deactivated. If the key is deactivated, the function would return the zero address instead of the recovered address. This change is intended to protect immutable contracts, such as ERC-20 tokens implementing ERC-2612 permit and systems like Uniswap’s Permit2, that depend on ecrecover and cannot be upgraded to add deactivation logic.

The proposal explicitly notes its limitation: contracts that implement ECDSA verification directly in Solidity, bypassing the precompile, would not be affected by this change.

EIP-7851 Advances Key Deactivation for Delegated EOAs

EIP-7851 continues to evolve on the Ethereum Magicians forum, proposing a protocol-level mechanism that allows delegated externally owned accounts to deactivate their private keys. Originally introduced in December 2024 by Colinlyguo, the proposal has undergone multiple refinements through 2025 and into early 2026.

The most recent update, published on February 14, 2026, removes the reactivation flow entirely, introduces a 7-day cancellation window for deactivation requests, and replaces the earlier trailing-byte encoding design with a system contract approach. These changes aim to simplify the security model and reduce ambiguity around key lifecycle management.

EIP-7851 is designed to work alongside EIP-7702, which enables delegated EOAs. The primary goal is to let users deactivate their original ECDSA private key once delegation is in place, reducing attack surface, particularly in a multi-chain ecosystem where the same key may control accounts across multiple EVM-compatible networks.

One of the central technical considerations discussed in the thread is the impact on transaction validation. The proposal introduces an additional account code read during txpool validation to check whether a key has been deactivated. Alternatives explored include adding a boolean field to account state or encoding deactivation status into the nonce, though each approach carries trade-offs in complexity and compatibility.

A major point of debate has been how ecrecover should behave after key deactivation. Community members raised concerns that if ecrecover continues to return valid addresses for deactivated keys, signature-based authorization systems, such as ERC-2612 permit implementations, could remain vulnerable. This discussion later led to a separate proposal (EIP-8151) focused specifically on making ecrecover deactivation-aware.

Vitalik Buterin Pushes Cypherpunk Ethereum Layer

Vitalik Buterin signaled plans to build a “cypherpunk principled non-ugly Ethereum” layer as a tightly integrated bolt-on to the current network, rejecting calls to abandon the existing chain and rebuild from scratch.

Responding to criticism about fragmentation across clients, L2s, and app chains, Buterin said the goal is to strengthen censorship resistance, zk-friendliness, and consensus properties system-wide, while preserving interoperability and continuity.

His comments come as Ethereum developers schedule Fork-Choice Enforced Inclusion Lists (FOCIL), under EIP-7805, for the Hegota hard fork expected in late 2026, following the Glamsterdam upgrade. FOCIL is designed to harden censorship resistance by requiring validators to include valid public mempool transactions. Validator committees would enforce inclusion via fork-choice rules, meaning blocks that ignore valid transactions could be rejected.

Developers argue FOCIL provides protocol-level guarantees that valid transactions are included within a bounded number of slots, even in contentious cases. Critics, however, warn the mechanism could expose validators to legal risk and increase protocol complexity. Despite debate, FOCIL has been slated for Hegota after being deferred from Glamsterdam.

Alongside FOCIL, EIP-8141 is expected to advance protocol-level account abstraction, enabling native smart wallets and multisig support. The upgrade also aims to improve support for quantum-resistant keys and gas-sponsored privacy transactions. By allowing smart wallet transactions to flow directly through the public mempool to FOCIL includers, developers hope to reduce reliance on intermediaries and wrappers.

Buterin also outlined a broader vision to gradually evolve Ethereum’s base layer. He pointed to potential “jet engine changes in-flight,” referencing the Merge as precedent, and listed future transformations including state tree redesign, lean consensus, ZK-EVM verification, and even a VM change, such as a move toward RISC-V for stronger zero-knowledge compatibility and broader language support.

Coinbase-Backed Base to Move Off OP Stack

Coinbase-incubated Ethereum layer-2 network Base announced it will transition away from the open-source Optimism OP Stack and adopt a unified in-house technology stack to accelerate upgrades and reduce operational overhead.

Base Head of Product Wilson Cusack said the shift will give the team “autonomy to ship protocol improvements more frequently” and focus on scaling the network toward its long-term goal of 1 gigagas per second, equivalent to 1 billion gas units per second. That throughput target, previously described as Base’s “north star,” represents roughly 40x the network’s earlier performance benchmarks.

Become a Medium member
Under the new roadmap, Base plans to double its hard-fork cadence from three to six per year. The aim is to ship narrower, more focused upgrades at a faster pace.

According to the Base developer blog, parts of the network, including the sequencer, are currently maintained across multiple teams and repositories, creating coordination and maintenance overhead. The new unified stack, referred to as base/base, will consolidate components and optimize them specifically for Base’s use case, leveraging open-source building blocks such as Reth.

Although no immediate action is required, node operators and developers will need to migrate to the new Base client in the coming months to remain compatible. The team says the architectural changes are expected to support greater scalability and decentralization over time.

The move comes shortly after Coinbase’s Q4 earnings, where the company reiterated plans to drive more transaction activity on Base in 2026.

Curvegrid Launches EIP-7702 Delegation Checker App

Curvegrid has introduced a new open-source EIP-7702 Delegation Checker App, designed to help users verify whether their Ethereum addresses have been delegated under EIP-7702 across multiple EVM chains. The tool addresses a growing visibility gap as account abstraction and wallet delegation become more common.

EIP-7702 allows externally owned accounts (EOAs) to execute programmable smart contract logic via delegation, effectively enabling an address to function both as a traditional EOA and as a smart wallet. While this unlocks batching, gas sponsorship, and custom authorization rules, delegation introduces a new trust model, closer to installing persistent software than approving a one-time transaction.

Curvegrid argues that delegation visibility is critical for safety. Before the checker’s release, users had to manually inspect multiple block explorers or write custom scripts to determine whether an address had been delegated. The Delegation Checker consolidates this process into a simple interface where users paste an address or ENS name and instantly see delegation status across supported EVM networks, without requiring a wallet connection.

The tool surfaces three visual signals for detected delegations: a green check mark for recognized implementations, a question mark for unknown delegates, and an orange warning triangle for contracts associated with malicious or compromised activity. Curvegrid emphasizes that these indicators assist interpretation but do not replace user due diligence.

The app runs entirely in the browser, requires no backend infrastructure, and does not transmit wallet data upstream. It queries multiple RPC endpoints directly and allows revocation where wallet support exists. However, revocation remains inconsistent across wallet providers, highlighting what Curvegrid describes as a broader UX gap in the ecosystem.

The company notes that while the checker improves transparency, it cannot recover funds after compromise or guarantee delegate contract safety.

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

Ethereum’s Role in AI, L2 Interop Highlights, Robinhood L2 Testnet, 2026 Smart Contract Risks

Alexandra — Thu, 19 Feb 2026 08:10:10 +0000

The latest news we'll cover:

Vitalik Reframes Ethereum’s Role in AI Around Privacy, Trust and Governance
L2 Interop WG #19 Highlights EIP-7702 + 5792 Cross-Chain UX
Robinhood Launches Public Testnet for Robinhood Chain
OWASP Forecasts 2026’s Most Critical Smart Contract Vulnerabilities

Please fasten your belts!

Vitalik Reframes Ethereum's Role in AI Around Privacy, Trust and Governance

Vitalik Buterin revisited his 2024 essay on crypto and AI intersections, arguing that discussions around AGI often frame progress as undifferentiated acceleration rather than a conscious choice of direction. He emphasized that Ethereum’s role is not simply to “work on AGI,” but to help steer AI development toward human freedom, decentralization, and defense-oriented outcomes.

He outlined four priority areas in his updated framework.

First, Buterin called for building tooling that enables more trustless and private interactions with AI systems. This includes local LLM tooling, zero-knowledge payments for API calls to prevent identity linkage, cryptographic privacy improvements for AI usage, and client-side verification of cryptographic proofs and TEE attestations. The goal is to apply Ethereum’s privacy and verification ethos to AI compute, particularly LLM interactions.

Second, he positioned Ethereum as an economic coordination layer for AI-related interactions. Use cases include API payments, hiring bots, security deposits, on-chain dispute resolution mechanisms, and standards such as ERC-8004 for AI identity and reputation. According to Buterin, economic coordination enables decentralized AI architectures rather than centralized in-house systems.

Third, he described making the cypherpunk “don’t trust, verify” vision practical through AI. Local models could propose and verify transactions, audit smart contracts, interpret formal verification proofs, and remove reliance on third-party UIs. AI, in this framing, allows individuals to realistically verify complex systems at scale.

Finally, Buterin highlighted improved markets and governance. With LLMs scaling human judgment, mechanisms such as prediction markets, quadratic voting, combinatorial auctions, and decentralized governance could overcome traditional limits of human attention and decision-making.

He summarized the agenda as a 2x2 matrix spanning infrastructure vs. impact and survival vs. thriving outcomes, arguing that Ethereum and AI together can reinforce decentralized cooperation and defensive resilience rather than unchecked acceleration.

L2 Interop WG #19 Highlights EIP-7702 + 5792 Cross-Chain UX

Call #19 of the L2 Interop Working Group focused on making cross-chain UX feel “one-click” without giving up self-custody, with two main threads: (1) using EIP-7702 + EIP-5792 to execute multi-step, cross-chain actions from existing EOAs, and (2) roadmap updates across the Open Intents Framework (OIF) stack.

Effortless presented a 7702+5792-based approach to let users approve complex flows in a single signature. Examples included “bridge to an L2 and then do a swap” or “bridge… do a swap and then put it into a staking… or a lending contract… all in a single transaction.”

They positioned the goal as matching centralized cross-chain UX while keeping decentralized self-custody, and described an additional L2 used “purely for recordkeeping” to mirror confirmations across chains into one place for tracking finality.

Wonderland’s Orca shared a status tour of OIF as a public-good, full-stack framework for intent-based interop, targeting less fragmentation and less vendor lock-in while enabling modular settlement paths and “trust minimized options.”

Updates touched multiple layers: revisiting ERC-7683 away from “standardized events” toward a “resolver-based pattern,” audited OIF settlement contracts that are “ready for use,” ongoing work on a trust-minimized “broadcaster” aligned with ERC-7888, plus parallel progress on API specs, a reference solver, and an interop SDK aimed at wallets/apps integrating cross-chain capabilities.

Robinhood Launches Public Testnet for Robinhood Chain

Robinhood has launched the public testnet for Robinhood Chain, a financial-grade Ethereum Layer 2 built on Arbitrum and designed to support tokenized real-world and digital assets. The company said the goal is to accelerate the development of onchain financial services, beginning with tokenized assets, and allow developers to start building ahead of a future mainnet launch later this year.

The testnet provides foundational infrastructure for developers to build and verify applications. Early ecosystem integrations include Alchemy, Allium, Chainlink, LayerZero, and TRM, with additional partners expected to onboard during the testnet phase. Robinhood positioned the launch as a step toward expanding institutional and developer participation in tokenized finance.

Johann Kerbrat, SVP and GM of Crypto and International at Robinhood, stated that the testnet “lays the groundwork for an ecosystem that will define the future of tokenized real-world assets and enable builders to tap into DeFi liquidity within the Ethereum ecosystem.”

The testnet supports standard Ethereum development tools through Arbitrum compatibility, provides network entry points, and offers developer documentation via Robinhood’s portal. Planned additions include testnet-only assets such as Stock Tokens, direct testing with Robinhood Wallet, and expanded infrastructure integrations.
Robinhood also committed $1 million to the 2026 Arbitrum Open House program to support development activity. The company will participate in global buildathons and founder events in New York City, Dubai, London, and Singapore as it prepares for mainnet deployment.

OWASP Forecasts 2026’s Most Critical Smart Contract Vulnerabilities

The OWASP has released the 2026 edition of the OWASP Smart Contract Top 10, a forward-looking awareness document identifying the most critical smart contract vulnerabilities expected to impact Web3 projects in the coming year. The ranking is based on 2025 breach data and practitioner survey input, projecting which risks are likely to remain most significant in 2026.

The 2026 list ranks Access Control Vulnerabilities as the top risk, followed by Business Logic Vulnerabilities, Price Oracle Manipulation, and Flash Loan–Facilitated Attacks. Two new categories enter the Top 10: Arithmetic Errors and Proxy & Upgradeability Vulnerabilities, reflecting the growing complexity of DeFi systems and upgradeable contract architectures. Meanwhile, Insecure Randomness and Denial of Service have been removed from the ranking.

OWASP notes that the 2026 edition is predictive rather than purely retrospective. The methodology combines empirical 2025 incident data, including sources such as SolidityScan’s Web3HackHub, SlowMist, BlockSec, and DeFiHackLabs, with a practitioner survey to determine category weightings and projected impact. The goal is to anticipate where smart contract risk is heading, not just where it has been.

The updated ranking highlights a shift toward higher-level economic and governance flaws. Business logic weaknesses and flash loan–facilitated exploits moved up in prominence, underscoring how attackers increasingly leverage capital efficiency and protocol design assumptions rather than relying solely on low-level coding bugs.

As part of the broader OWASP Smart Contract Security initiative, the Top 10 serves as a reference for developers, auditors, and protocol teams. It is intended to support awareness, prevention, and secure development standards across the ecosystem.

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

Post-Quantum AA on Ethereum, ERC-4337 Security, EIP-7702 Wallets, Chain Abstraction on TRIA

Alexandra — Thu, 12 Feb 2026 09:28:45 +0000

The latest news we'll cover:

Ethereum PQTS Call Positions Native Account Abstraction as Post-Quantum Foundation
Ethereum Foundation Awards $50K Maximum Bounty for ERC-4337 ‘High-Severity’ Attack Vector
Rivet Fork Adds EIP-7702 Support, Showcases ‘Build Your Own Wallet’ Use Case
KuCoin Lists TRIA in Global Premiere, Showcases Chain Abstraction Vision With $34,000 Incentives

Please fasten your belts!

Ethereum PQTS Call Positions Native Account Abstraction as Post-Quantum Foundation

Ethereum’s first Post Quantum Transaction Signature (PQTS) Breakout Room (#1889) centered on one clear conclusion: account abstraction is the architectural foundation for Ethereum’s post-quantum transition.

During the call, contributors emphasized that while the final post-quantum signature algorithm has not been selected, the ecosystem broadly agrees that AA will serve as the base layer enabling whichever scheme is ultimately adopted. Native account abstraction is viewed as the structural anchor that can support cryptographic migration without repeatedly redesigning transaction flows.

Nico, who has worked extensively on account abstraction, outlined the limitations of ERC-4337. While compatible with post-quantum cryptography, 4337 remains non-native, introducing gas overhead, bundler dependencies, and added complexity around entry points and gas management. These constraints are driving momentum toward native AA integration at the protocol level.

The discussion highlighted EIP-8141 (“Frame Transactions”), a proposed new transaction type designed to replace the rigid ECDSA-centric transaction model. Frame Transactions introduce a structured flow with verification, execution, and sender frames. Crucially, signature verification occurs in a read-only verification phase, meaning failed validation does not burn gas. This model allows flexible signature schemes without enshrining any single cryptographic primitive in the protocol.

Participants clarified that EIP-8141 would replace the earlier 7701 proposal. Existing ERC-4337 wallets would continue functioning, but a transitional migration toward native AA is expected over time.

Beyond structural changes, the call strongly emphasized cryptographic agility. Current Ethereum transaction formats hardcode ECDSA assumptions (V, R, S fields), making algorithm replacement costly and disruptive. Contributors argued that Ethereum must support multiple signature schemes simultaneously and allow modular replacement over time. Given the uncertainty of post-quantum cryptography, where schemes may evolve or break, designing for agility is considered critical.

Ethereum Foundation Awards $50K Maximum Bounty for ERC-4337 ‘High-Severity’ Attack Vector

The Ethereum Foundation has awarded a $50,000 bug bounty, its maximum high-severity payout, to Trust Security for identifying a previously undisclosed attack vector affecting ERC-4337, the standard that powers account abstraction. The issue was disclosed on Thursday and has since been patched in the latest release.

According to the foundation, the vulnerability allowed a malicious actor to intentionally cause certain ERC-4337 account-abstraction transactions to revert while still forcing users to pay gas fees, even though the transactions were valid and properly signed. Trust Security described the issue as a censorship and griefing vector rather than a fund-theft exploit.

At the time of discovery, usage of the vulnerable ERC-4337 transaction type was relatively limited. However, around 1.7 million such transactions were sent over the past week, roughly 9% of total Ethereum transactions during that period, underscoring the need to address the issue before wider adoption amplifies potential impact.

The root cause stemmed from a hidden assumption in the ERC-4337 implementation. Developers assumed account abstraction transactions would execute cleanly and in isolation, similar to standard Ethereum transactions. In practice, an attacker could frontrun certain pending account abstraction transactions interacting with protocols that use reentrancy protection or temporary state changes, causing the inner transaction to revert while still consuming gas.

To mitigate the issue, developers introduced changes requiring specific contract functions to be callable only from non-account-abstraction wallets. The Ethereum Foundation urged protocols relying on ERC-4337 to upgrade to the newest release as soon as possible.

In addition to the $50,000 bounty from the foundation, Trust Security reported receiving $59,500 in additional bounties from DeFi applications built on ERC-4337.

Rivet Fork Adds EIP-7702 Support, Showcases ‘Build Your Own Wallet’ Use Case

Dhruv (@0xdhruva) announced a new release of a Rivet fork that integrates support for EIP-7702 and EIP-5792, positioning it as a practical example of how developers can build their own programmable wallet experiences on top of Ethereum’s evolving account abstraction stack.

In his post, Dhruv highlighted several capabilities enabled by the update: native EIP-7702 support, contract interactions that “don’t fight you,” contract deployment, arbitrary calldata submission, and typed data signing. The release is available on GitHub under the tag v0.0.0-nightly.25702ab, with ongoing feature development planned for a utility-focused interface.

EIP-7702 allows externally owned accounts (EOAs) to delegate execution logic to smart contracts, effectively enabling execution abstraction without requiring users to abandon their existing addresses. In practice, this means wallet behavior can be upgraded or customized, including gas abstraction, batching, or alternative signature logic, while preserving user identity and balances.

The Rivet fork demonstrates how 7702 can be used as a foundation for custom wallet infrastructure rather than relying solely on standardized wallet implementations. By combining 7702 delegation with 5792 support (which standardizes wallet request capabilities), the tool provides a sandbox for experimenting with programmable account behavior at the transaction layer.

KuCoin Lists TRIA in Global Premiere, Showcases Chain Abstraction Vision With $34,000 Incentives

KuCoin has officially launched TRIA on its Spot platform on February 3, 2026, marking the project’s global premiere. The exchange is supporting the listing with a combined $34,000 USDT incentive program tied to trading, deposits, and on-chain participation.

The listing highlights TRIA’s positioning at the center of the chain abstraction narrative in 2026. While previous cycles focused on launching new Layer 1 and Layer 2 networks, TRIA targets what it describes as the resulting “fragmentation crisis.” As a self-custodial global neobank and unification layer, TRIA abstracts away blockchain complexity, enabling users to spend, trade, and earn across multiple chains without manually bridging assets or managing gas tokens.

At the infrastructure level, TRIA’s chain abstraction model is powered by its BestPath AVS (Actively Validated Service), an AI-driven intent engine. Rather than forcing users to execute multiple cross-chain steps, users declare their desired outcome, and the BestPath engine routes transactions end-to-end, aiming for optimal pricing and sub-second settlement.

The protocol reports that this technology is already utilized by more than 70 protocols and integrated across ecosystems such as Polygon, Arbitrum, and Injective.

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

Ethereum's Frame Transactions for Post-Quantum Accounts, ChA Quietly Advances Beyond the Hype, ERC-8004 Is Live

Alexandra — Thu, 05 Feb 2026 08:43:09 +0000

The latest news we'll cover:

Ethereum Drafts “Frame Transaction” Type for Post-Quantum & Abstract Accounts
Why Chain Abstraction Quietly Progressed After the Hype Faded
ERC-8004 Is Live on Mainnet
OP Stack Roadmap Targets Post-Quantum Smart Accounts by January 2036

Please fasten your belts!

Ethereum Drafts “Frame Transaction” Type for Post-Quantum & Abstract Accounts

EIP-8141, recently published on the Ethereum Improvement Proposals repository, defines a new core transaction type called a Frame Transaction, designed to enable abstract transaction validation, execution, and gas payment.

Unlike current Ethereum transactions, which rely on a single ECDSA signature for authorization, Frame Transactions allow accounts to freely define and interpret their signature schemes with arbitrary cryptographic systems, helping support future privacy and post-quantum security goals.

The specification introduces the new FRAME_TX_TYPE (0x06) and associated opcodes including APPROVE, TXPARAMLOAD, TXPARAMSIZE, and TXPARAMCOPY, enabling multi-frame transaction structures that separate validation, execution, and payer approval phases.

Frame Transactions organize data into a list of frames with modes like VERIFY, SENDER, and DEFAULT, allowing each frame to perform distinct steps such as validating signatures, executing logic, or approving gas payment.

The proposal’s rationale emphasizes achieving account abstraction directly in the protocol by unlinking transactions from fixed signature mechanisms, advancing beyond EIP-7702 and enabling arbitrary validation and fee schemes native to Ethereum.

EIP-8141 also updates transaction behavior, gas accounting, and receipt formats to support these multi-frame operations while maintaining compatibility with blob gas fees introduced by EIP-4844.

Security considerations highlight new denial-of-service vectors introduced by arbitrary validation logic and recommend limits on opcode access and frame execution to ensure safe propagation within transaction pools.

As a Standards Track: Core EIP authored by Vitalik Buterin and others, Frame Transactions represent a foundational step toward more flexible and future-ready transaction semantics on Ethereum, though implementation and deployment timelines remain in draft discussion.

Why Chain Abstraction Quietly Progressed After the Hype Faded

A recent X article by Ethan from Particle Network argues that chain abstraction has not disappeared due to technical failure, but because crypto narratives are driven by short attention cycles rather than long-term engineering progress. According to the post, most market participants never deeply understood chain abstraction and quickly moved on once incentives and hype shifted elsewhere.

The thread describes a familiar lifecycle for crypto narratives: early validation through social capital, rapid amplification by token-aligned participants, peak euphoria, followed by a slow decline as products fail to match expectations. In this framing, chain abstraction joined a “narrative graveyard” alongside modularity, NFTs, GameFi, and AI agents, not because the ideas failed, but because speculative momentum dissipated.

Crucially, the author stresses that narrative death and technological death are not the same. Narratives are tied to price action and attention, while technology compounds quietly over time. Many ideas that fall out of discussion can resurface if incentives realign, but their underlying progress continues regardless of social visibility.

From a practical standpoint, the thread claims chain abstraction is already delivering real user-experience improvements without being labeled as such. Examples cited include chain-agnostic products like Fomo, Particle Network’s Universal Accounts, DeFi App, Polymarket, Ostium, and more, all of which reportedly processed significant user activity while abstracting away chain complexity.

The post also points out that the Ethereum Foundation committed in late 2024 to building native chain abstraction primitives, reinforcing the view that the concept remains strategically relevant at the protocol level despite reduced social discussion.

The conclusion is explicit: chain abstraction addresses a fundamental problem, poor crypto UX, and is therefore inevitable. While the narrative may no longer be fashionable, the technology is described as alive, growing, and increasingly embedded in applications.

ERC-8004 Is Live on Mainnet

ERC-8804 is live on mainnet! ERC-8004 is an Ethereum standard designed to solve the “trust gap” between autonomous AI agents operating across organizations. The proposal introduces a public, permissionless trust layer that allows agents to discover each other, verify identity, and assess reliability without relying on centralized platforms or intermediaries. The article frames ERC-8004 as foundational infrastructure for an emerging agent economy, similar in spirit to how ERC-20 unified tokens and ERC-721 standardized NFTs.

At the core of ERC-8004 are three lightweight on-chain registries: Identity, Reputation, and Validation. The Identity Registry provides each agent with a portable, globally unique on-chain identity implemented as an ERC-721 NFT, linking to a machine-readable registration file that advertises endpoints and capabilities. The Reputation Registry records client feedback in a composable on-chain format, enabling agents to build portable reputations that persist across platforms. The Validation Registry adds optional third-party verification, supporting approaches ranging from crypto-economic re-execution and zero-knowledge proofs to TEE attestations and trusted judges.

The design deliberately keeps the standard minimal, storing only essential trust signals on-chain while leaving application-specific logic off-chain. This allows developers to plug in custom trust models, keep costs low, and evolve the ecosystem without breaking compatibility.

ERC-8004 complements existing agent communication protocols such as Google’s A2A and MCP rather than replacing them, adding a neutral discovery and trust layer on top.

In this framing, Ethereum is not where AI models run, but where agent trust and accountability live. Early use cases span DeFi, enterprise coordination, agent marketplaces, and DAO governance, with tooling, SDKs, explorers, and testnet deployments already live.

OP Stack Roadmap Targets Post-Quantum Smart Accounts by January 2036

OP Labs says it is committing, subject to governance approval, to a 10-year timeline to deprecate ECDSA-based EOAs on OP Mainnet and across the Superchain, with the countdown starting in this post and the target date set for January 2036.

By January 2036, the roadmap states that “ECDSA-signed EOA transactions will be deprecated” and “Every ECDSA EOA must have delegated its key management to a post-quantum smart contract account.” The post frames this as a long-lead migration to avoid rushed ecosystem breaks.

The user migration path is built around account abstraction and EIP-7702 support in the OP Stack, with the post describing “Smart wallet migration via EIP-7702 or future AA standard” so EOAs can delegate authority to smart accounts that verify post-quantum signatures while keeping addresses and balances. It also emphasizes users “don’t need to take any action today.”

On the infrastructure side, the post says the L2 sequencer and batch submitter will transition off ECDSA to post-quantum signatures, and it argues that Ethereum Foundation and the wider ecosystem should plan for post-quantum consensus upgrades because Ethereum relies on BLS signatures and KZG commitments today.

Finally, it presents execution as coordinated hardforks, with overlapping ECDSA and post-quantum support during the window, then defaulting to PQ-aware smart accounts at the end — “hardforks, not heroics.”

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

Ethereum Hits Record Usage as Fees Fall, ERC-7779, Vitalik Targets “Trust-Me” Wallets, Ethereum's Post-Quantum Security Team

Alexandra — Thu, 29 Jan 2026 08:53:53 +0000

The latest news we’ll cover:

Ethereum Hits Record Usage as Fees Fall, Easing Network Conditions
ERC-7779 Brings Safe Wallet Migration to EIP-7702 Accounts
Vitalik Buterin: 2026 Is the End of “Trust-Me” Wallets
Ethereum Forms Post-Quantum Defense Team with $2M Prize Programs

Please fasten your belts!

Ethereum Hits Record Usage as Fees Fall, Easing Network Conditions

Ethereum has reached record daily transaction activity while average costs continue to drop, signaling stronger network conditions and sustained user engagement, according to Decrypt.

On-chain data shows that daily transaction counts have climbed past previous cycle peaks from the 2021 bull market, while average fees have fallen to levels not seen in years. Over a recent two-week period, daily transactions climbed from around 1.8 million to 2.1 million, even as average gas costs slid to a fraction of their historical norms.

This combination of higher throughput and lower costs reflects the impact of Ethereum’s scaling architecture, including modular upgrades and enhanced data throughput for Layer 2 rollups that allow more activity to settle cheaply on the mainnet. Most of the increased usage appears to be driven by stablecoin transfers and payments, with Tether’s USDT volume on-chain running roughly twice that of Circle’s USDC.

Validator dynamics also point to network confidence: with roughly 30% of all ETH staked and the validator exit queue at zero, there is no immediate rush to leave staking positions, suggesting staking economics remain balanced.

While some analysts caution that a portion of low-value stablecoin transfers may reflect dusting or address-poisoning campaigns rather than organic activity, the broader picture shows Ethereum handling unprecedented usage at reduced cost, underscoring its growing role as a resilient settlement layer across diverse applications.

ERC-7779 Brings Safe Wallet Migration to EIP-7702 Accounts

The ERC-7779 draft introduces standardized interfaces to make EIP-7702 delegated EOAs interoperable across wallets, addressing storage collision risks and broken redelegation flows. It defines how smart accounts expose their storage bases and identity so users can safely migrate between wallet implementations without losing sovereignty or bricking their accounts.

The proposal assumes widespread adoption of EIP-7702, where EOAs temporarily delegate execution to smart contract logic for features such as gas sponsorship, batch execution, and automated flows. Because these delegated accounts use custom storage, switching wallets can cause storage collisions that lead to locked funds or security vulnerabilities, which ERC-7779 aims to prevent through standardized discovery and verification of storage bases.

To solve this, ERC-7779 introduces the InteroperableDelegatedAccount interface with two core methods: accountId() for human-readable wallet identity, and accountStorageBases() for returning all historical storage base slots used by the account. Wallets must check these values before redelegating to ensure the new implementation will not collide with previous storage layouts.

Storage bases must be appended to a shared array located at a deterministic slot derived from keccak(“InteroperableDelegatedAccount.ERC.Storage”), and computed using keccak256() to reduce collision risk. This creates a persistent audit trail of all storage namespaces the account has used, allowing wallets to verify redelegation safety instead of relying on hash probability alone.

The rationale compares this storage validation model to how ERC-2535 Diamonds verify facet storage layouts, arguing that explicit checks are safer than assuming low collision probability. It also notes that delegated EOAs require stronger guarantees than smart accounts, because EOA users already expect seamless wallet migration.

Security guidance warns that accounts may falsely claim compliance, so wallets should verify known implementations. The standard enforces keccak-based storage derivation, forbids replay-protection resets during redelegation, and recommends best-effort storage cleanup while acknowledging architectural limits.

Vitalik Buterin: 2026 Is the End of “Trust-Me” Wallets

Vitalik Buterin claims 2026 will be the year Ethereum begins ending the dominance of “trust-me” wallets — wallet experiences that implicitly rely on centralized RPC providers and other off-chain trust assumptions.

Buterin argues that over the past decade, while Ethereum’s protocol remained trustless, user defaults drifted toward convenience-first compromises, including wallets depending on centralized servers for blockchain data and applications becoming tied to cloud endpoints that can leak user information. He frames this as a reversion point where the ecosystem should make trust-minimized paths the default experience.

The article outlines a menu of infrastructure fixes aimed at making trustless behavior easier than trusting intermediaries. These include verified RPC clients that convert remote RPC responses into locally verifiable data, private information retrieval (PIR) to protect query privacy, and fork-choice-enforced inclusion lists (FOCIL, EIP-7805) to structurally enforce censorship resistance in block building.

A central example of this effort is Helios, a light client that can sync quickly and serve verifiable blockchain data locally, reducing reliance on third-party RPC providers. The CryptoSlate report notes Helios can run a local JSON-RPC endpoint and serve proof-verified responses to wallets and apps.

The Ethereum Foundation’s Kohaku project is highlighted as the delivery vehicle for these changes, with plans to integrate Helios and other primitives into a reference wallet that can be used as a model or SDK for other wallets. Making such tooling default would shift user experience toward trust-minimized operation rather than implicit reliance on centralized infrastructure.

Ethereum Forms Post-Quantum Defense Team with $2M Prize Programs

The Ethereum Foundation has launched a dedicated Post-Quantum (PQ) Security team, formally elevating quantum resistance to a top strategic priority for the protocol. The initiative is led by Thomas Coratger, with Emile from leanVM joining as a core contributor, and is backed by $2 million in research prizes aimed at hardening Ethereum against future quantum threats.

In a public statement, Ethereum researcher Justin Drake confirmed the strategic shift, writing:

“After years of quiet R&D, EF management has officially declared PQ security a top strategic priority.”

The funding is split into two major initiatives: the $1M Poseidon Prize, focused on strengthening the Poseidon hash function used in zero-knowledge systems, and the $1M Proximity Prize, which supports broader quantum-resistant cryptography research. Drake added that Ethereum is “betting big on hash-based cryptography to enjoy the strongest and leanest cryptographic foundations.”

Ethereum has already deployed multi-client post-quantum consensus devnets, with early participation from Lighthouse, Grandine, and experimental clients. Weekly PQ interoperability calls are coordinating development across teams, while a new PQ All Core Devs breakout focused on transactions, account abstraction, precompiles, and signature aggregation will begin next month.

The Foundation is also expanding education and research through international PQ workshops, a multi-part ZKPodcast series, and a forthcoming public roadmap, which aims to deliver a full transition to post-quantum security with zero downtime and zero loss of funds.

Together, the team, funding, devnets, and roadmap mark Ethereum’s shift from long-term quantum theory into active protocol-level engineering, positioning PQ security as a core pillar of Ethereum’s future architecture.

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