DEV Community: Alexandra

Verifiable Agent Routing, ZK Wallet Upgrades, Soldøgn Interop, 7702 Collective

Alexandra — Thu, 07 May 2026 09:11:59 +0000

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

This week: Ethereum explores verifiable routing for agent-generated state, new ZK designs upgrade wallets without key exposure, Glamsterdam scaling targets solidify, and the 7702 Collective launches to highlight infrastructure-driven adoption.

Soldøgn Interop Locks In Key Glamsterdam Targets
New EIP-7702-Based Proposal Uses ZK Proofs to Hide Wallet Public Keys
New Ethereum Proposal Targets Verifiable Routing for Agent Solver Outputs
Introducing the 7702 Collective and Its New Industry Report

Please fasten your belts!

Soldøgn Interop Locks In Key Glamsterdam Targets

Ethereum core contributors used the Soldøgn Interop gathering in Svalbard to align on major technical targets for the Glamsterdam upgrade, including a post-upgrade gas limit floor of 200 million, stable ePBS implementations with external builders, and final EIP-8037 repricing numbers. The week brought together more than 100 contributors for a single-track working session focused on turning Glamsterdam’s scaling and hardening goals into production-ready progress.

A large share of the work centered on ePBS, where teams moved from early instability to a multi-client devnet running with external builders by the end of the week. Contributors simplified parts of the Builder API, debugged cross-client edge cases, and tested the full external builder pipeline end-to-end. Two issues remain open for further All Core Devs discussion: whether request signatures should commit to the receiving builder, and how a low-stake builder design can remain resilient against Sybil-based liveness attacks.

On the execution layer side, teams worked in parallel on Block-Level Access Lists (BALs) and gas repricings. BAL benchmark work focused on lifting worst-case performance paths across clients rather than optimizing only the fastest implementations. For EIP-8037, contributors dropped dynamic per-state-byte pricing in favor of a fixed cost model, then iterated through several accounting designs before stabilizing the spec on bal-devnet-6. The combined outcome of ePBS, BAL optimization, and repricing work formed the basis for the 200M gas-limit target.

The interop also pushed forward non-headliner Glamsterdam items, while opening space for deeper Hegotá work on FOCIL and Native Account Abstraction. The broader significance is that Glamsterdam is no longer just about isolated feature work: contributors are now treating execution time, state growth, block construction, and gas accounting as one connected scaling problem.

New EIP-7702-Based Proposal Uses ZK Proofs to Hide Wallet Public Keys

A new Ethereum Research post proposes a way to upgrade any existing Ethereum wallet to post-quantum-style protection in a single transaction using EIP-7702 delegation, zero-knowledge proofs, and a hidden public key. The design keeps the same address, avoids asset migration, and does not require consensus changes. Instead of moving funds to a new post-quantum wallet, an EOA delegates execution to a GatedWallet contract that only accepts ZK proofs showing knowledge of an ECDSA key whose public key never appears on-chain.

The post argues that this matters because any EOA that has already transacted once has exposed its secp256k1 public key on-chain, which would make it vulnerable to Shor-based key extraction by a cryptographically relevant quantum computer. In the proposed construction, the user generates a new hidden keypair off-chain and stores only a hash of that public key in the contract.

The author presents this as a faster migration path for existing wallets, especially institutional setups that still depend on HSMs or MPC systems built around ECDSA. Rather than replacing ECDSA immediately, the approach wraps it inside a proof layer, allowing the lower wallet infrastructure to stay unchanged while shielding the public key from mempool and on-chain exposure.

The post also outlines a hybrid transition mode where both a normal exposed-key signature and a hidden-key ZK proof are required, giving protection against both quantum key extraction and potential proof-system bugs during early deployment.

Benchmarks in the post show a working implementation with roughly 87 ms proving time, 65 ms verification time, a 226 KB proof, and about 3 million gas on-chain in the current form, with further reductions expected from a designated-prover optimization.

New Ethereum Proposal Targets Verifiable Routing for Agent Solver Outputs

A new draft proposal, Autonomous State Gateway (ASG), argues that Ethereum’s agent stack still lacks a standardized way to route valuable off-chain work into a verifiable, settlement-ready on-chain state. While recent agent-related ERCs have focused on identity, authorization, escrow, and conditional settlement, ASG is positioned earlier in the flow: it standardizes how an off-chain solver’s output is committed, collateralized, verified, disputed, and finally settled.

The draft treats every off-chain result as a Proposed State Transition. Instead of each marketplace or agent system inventing its own custom verifier gateway, ASG suggests a shared routing pattern: off-chain result → collateralized commitment → verifier attestation → dispute window → settlement.

The proposal is designed to be domain-neutral, meaning the same gateway logic could support code patches, vulnerability proofs, model-context changes, dataset transformations, or trading strategy updates.

Architecturally, the draft separates ASG Core from ASG Profiles. The Core defines the common state machine and economic rules, including commitment matching, collateral reservation, verifier attestation requirements, priority for the earliest valid commitment, and terminal settlement or slashing. Profiles then define how a specific domain interprets the submitted state_root, such as a repository patch hash, transformed dataset root, or strategy-state hash.

The proposed flow starts with a solver committing a salted hash of the result and reserving collateral. After ordering is anchored, the solver reveals the state root and evidence, the gateway routes it to a verifier, a dispute window opens, and the transition is either settled or slashed.

Introducing the 7702 Collective and Its New Industry Report

Particle Network announced the launch of the 7702 Collective, a new coalition positioned around highlighting the infrastructure trends driving crypto adoption and ecosystem consolidation. As its first initiative, the group released The State of Crypto Innovation, which it describes as a builders-first assessment of the industry’s maturing infrastructure.

The Collective is intended to shift attention away from short-lived narratives and toward the structural developments that are shaping the next phase of Web3. The report gathers input from builders across the industry and focuses on what they believe is pushing crypto to the next level.

The 7702 Collective is powered by Particle Network, LI.FI, Openfort, Avail, ZeroDev, Etherspot, Magic Labs and Rhinestone, while the report also includes contributions from industry participants such as Centrifuge, Avalanche and Noble. This gives the initiative a multi-project foundation rather than positioning it as a single-company campaign.

The announcement also makes clear that the Collective is designed as an open industry effort. Teams interested in participating can apply through the same website hosting the report, suggesting that the group intends to expand beyond its founding contributors over time.

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

Native AA Debate, DES Explores Parallel zkEVM Execution, Affine Metering Targets Higher Throughput, Etherspot Powers Telegram Crypto UX

Alexandra — Thu, 30 Apr 2026 10:40:44 +0000

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

This week: Ethereum’s native account abstraction effort shifts into a structured multi-proposal phase, new research explores parallel zkEVM execution and higher throughput models, and Etherspot brings seamless gasless UX to Telegram-native crypto applications.

Native Account Abstraction Debate Moves Into a Dedicated Breakout Process
Delegated Execution Sharding Explores a Hyper-Parallel zkEVM Path
Etherspot Powers Blockgram’s Gasless, Keyless Crypto Experience on Telegram
Research Post Proposes Affine Metering for Higher Ethereum Throughput

Please fasten your belts!

Native Account Abstraction Debate Moves Into a Dedicated Breakout Process

Ethereum contributors held the first dedicated Native Account Abstraction breakout on April 22, shifting the discussion from headliner selection to a broader comparison of competing proposals and implementation paths. The session followed the decision not to make EIP-8141: Frame Transactions a Hegotá headliner, while still keeping account abstraction as an active priority for future fork work. The agenda explicitly covered proposal updates, adoption strategy, mempool design, statelessness and VOPS implications, privacy, and post-quantum security.

The discussion showed clear differences in priorities across stakeholders. Wallet developers focused on practical deployment concerns such as efficiency and hardware wallet support, while other participants emphasized post-quantum readiness and reducing centralization around transaction flow. The breakout also reviewed newer proposals alongside Frame Transactions, including EIP-8202: Schemed Transaction, EIP-8223: Contract Payer Transaction, and EIP-8224: Counterfactual Transaction, indicating that Ethereum’s native AA debate is no longer centered on a single design.

Frame Transactions remained the most detailed proposal in the room, but the summary makes clear that several major issues are still open. The next work items include aligning with Base, Arbitrum, and OP on performance and cost concerns, defining canonical verifiers, resolving the ERC-20 sponsorship model, and addressing statelessness compatibility questions. In parallel, the authors of EIP-7906 were tasked with building a proof of concept to show how transaction assertions could work both independently and alongside Frame Transactions.

The key takeaway is that Ethereum’s account abstraction effort is now moving through a more structured research and coordination phase rather than a single winner-takes-all proposal process. That likely makes near-term progress slower, but it also broadens the path for combining multiple ideas into a native AA design that can satisfy wallets, L2s, privacy use cases, and post-quantum migration requirements.

Delegated Execution Sharding Explores a Hyper-Parallel zkEVM Path

Ethereum Research contributor Conall O’Reilly proposed Delegated Execution Sharding (DES) as a theoretical execution-layer design that could push Ethereum toward much higher scalability by combining parallel transaction execution with recursive zk-proof aggregation. The post frames DES as an extension of ideas already being explored around Lean, post-quantum priorities, and recursive proof systems, arguing that the same logic used to parallelize validator-signature proving on the consensus side could eventually be adapted for execution as well.

The core idea is to split a block’s transactions into separate “execution columns” made up of transactions whose state effects do not collide. Those columns could then be executed in parallel by different committees, with each committee producing zk-proofs for its assigned work. A block proposer would then aggregate those proofs into a higher-level proof covering the full block. In that model, execution would no longer be bottlenecked by a single machine needing to run the entire state transition directly in real time.

The post positions this as a way to move beyond today’s scaling limit, where decentralization still depends on any ordinary node being able to re-execute the full chain. DES instead assumes untrusted parallel execution across many nodes, with validity preserved through succinct proofs rather than direct recomputation. The proposal also suggests that future gas pricing could reflect how parallelizable a transaction is, making access to heavily contested state more expensive and encouraging designs that reduce shared-state contention.

Etherspot Powers Blockgram’s Gasless, Keyless Crypto Experience on Telegram

Blockgram has partnered with Etherspot to integrate Account Abstraction into its Telegram-native crypto platform, aiming to remove much of the friction that still makes Web3 difficult for mainstream users. According to the announcement, the integration brings gasless transactions, smart accounts, and transaction batching directly into a chat-based experience on Telegram.

The setup is designed to simplify three major pain points in crypto onboarding. First, users no longer need to manage seed phrases or private keys in the traditional way, as Blockgram uses smart contract accounts through Etherspot’s Modular SDK. Second, users can pay gas fees in any ERC-20 token through Etherspot’s Arka Paymaster, removing the need to hold ETH just to get started. Third, Etherspot’s Skandha ERC-4337 Bundler enables multi-step actions to be bundled into a single on-chain transaction, reducing approval friction.

Blockgram describes the result as a “gasless, seedless execution terminal” built inside Telegram. The case study positions this as a way to make crypto interactions feel closer to Web2 messaging flows, while still preserving decentralization and self-custody. For users, the stated benefits include one-click approvals, simpler onboarding, and a chat-native way to send, receive, and manage crypto.

More broadly, the integration highlights how Account Abstraction infrastructure is being applied to consumer-facing products beyond standard wallets and DeFi interfaces. In this case, Etherspot’s stack is the core layer that allows Blockgram to hide blockchain complexity behind a familiar messaging experience, turning Telegram into a more usable crypto interface for a wider audience.

Research Post Proposes Affine Metering for Higher Ethereum Throughput

Anders Elowsson argues that Ethereum could materially improve execution-layer throughput by combining a variable PTC deadline, a single unified calldata price, and what he calls affine metering. The proposal is designed around ePBS timing constraints: as calldata usage rises, the PTC deadline shifts later, and as calldata usage falls, the unused propagation window is converted into extra execution time. In this model, calldata and execution are no longer treated as loosely connected resources. Instead, they share a direct linear tradeoff inside the slot.

The post’s core claim is that this design could let Ethereum use a much larger share of each slot for execution, roughly doubling throughput and the gas limit under the illustrated assumptions. The argument depends on replacing EIP-7976’s split calldata pricing model with a single calldata price, so that calldata is charged in proportion to the propagation burden it creates. That makes the timing model cleaner and avoids the limited scaling gains that come from letting transactions buy some calldata too cheaply.

A major criticism of EIP-7976 in the post is that its large price differential creates room for gameability. Transactions heavy in execution could effectively “auction off” their cheaper calldata allowance, while the network still has to deal with the real byte footprint. Under affine metering, every calldata byte is priced consistently, which removes that distortion and simplifies gas accounting.

The post also argues that this framework remains compatible with a future multidimensional fee market such as EIP-7999. In that version, calldata could still be treated as its own resource, while the variable PTC deadline would continue to track raw byte consumption or an equivalent constant-multiple unit.

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

Wallet-Led Privacy Paymasters, GasLiteAA, Privacy Path for Frame Transactions, ETHGas & etherfi $3B Blockspace Deal

Alexandra — Thu, 23 Apr 2026 10:37:49 +0000

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

This week: Wallet-led privacy paymasters, TEE-based gas sponsorship reduces ERC-4337 overhead, frame transactions evolve with stronger security and privacy paths, and a $3B Blockspace deal signals institutional demand for execution markets.

Draft ERC Proposes a Wallet-Led Privacy Paymaster Capability for Gas Payments
GasLiteAA Proposes TEE-Based Gas Sponsorship to Cut ERC-4337 Overhead
EIP-8141 Update Simplifies Frame Transactions and Tightens Security
Ethereum Research Maps a Privacy Path for Frame Transactions
ETHGas and etherfi Announce $3B Blockspace Market Deal

Please fasten your belts!

Draft ERC Proposes a Wallet-Led Privacy Paymaster Capability for Gas Payments

A new draft ERC on Ethereum Magicians proposes privacyPaymaster, a wallet capability that would let applications request privacy-preserving gas payment while keeping all funding logic under user and wallet control.

The proposal is built around EIP-5792 capabilities. Instead of letting a dapp choose an external paymaster service, the wallet would handle provider selection, gas estimation, authorization, and transaction assembly internally. The dapp would only signal intent through a capability request, while the wallet decides whether and how to use a configured privacy paymaster.

The draft argues that gas payment still acts as an identity leak even when users protect the value-transfer side of a transaction. Existing models such as paymasterService depend on application-selected external services, which can introduce metadata leakage, correlation risks, censorship, and liveness dependencies. In contrast, this design makes the wallet the sole authority over privacy-preserving gas funding.

The capability supports two modes. If optional is set to false, the wallet must use a privacy paymaster or reject the request. It cannot silently fall back to normal gas payment. If optional is true, the wallet should use a privacy paymaster when available, but may proceed with standard gas payment if the capability cannot be satisfied. An empty capability object is explicitly invalid and must be rejected.

The draft is execution-model agnostic. It describes how the same wallet-level behavior could map to ERC-4337, EIP-7702, or a future EIP-8141 flow, while keeping provider details, balances, and internal user state hidden from applications.

GasLiteAA Proposes TEE-Based Gas Sponsorship to Cut ERC-4337 Overhead

GasLiteAA presents a new approach to ERC-4337 paymaster validation by moving complex gas sponsorship logic off-chain into Trusted Execution Environments (TEE), while still anchoring correctness on Ethereum through lightweight cryptographic attestations. The paper argues that current ERC-4337 paymasters become expensive as validation logic grows, and positions GasLiteAA as a way to preserve compatibility with Ethereum L1 without adding a separate execution layer.

The design combines several components: deterministic routing so each userOp is assigned to a specific bundler, a Merkle-tree commitment for user state, a Bundler Manager with staking and slashing, and an on-chain verifier that checks TEE-generated proofs before state updates are finalized. A key part of the architecture is atomicity: if on-chain execution fails, the proposed off-chain state transition is invalidated, avoiding state drift between the off-chain paymaster logic and Ethereum mainnet. The workflow diagram on page 5 shows this split clearly, with the TEE handling state computation off-chain and the EntryPoint, Paymaster, and State Manager finalizing execution on-chain.

In testing, the authors report meaningful efficiency gains. At 1,000 userOps under the most complex rule set, GasLiteAA reduced total gas from 158.48M in the on-chain baseline to 82.15M, while keeping latency near 0.1 seconds. The paper also benchmarks a ZK alternative and finds that proof generation can exceed 937 seconds and 26 GB of memory, making the TEE route materially more practical for real-time, high-frequency account abstraction use cases.

EIP-8141 Update Simplifies Frame Transactions and Tightens Security

Pedro Gomes, Founder & Director at WalletConnect, highlighted a major update to EIP-8141, describing it as the proposal’s biggest revision so far, with changes aimed at simplifying the spec, tightening security, and making implementation details more explicit.

One of the main updates is a cleaner separation between mode and flags. Instead of packing execution mode, approval scope, and batching into one field, the proposal now keeps mode limited to execution type while a separate flags field handles scope and batching. The update also introduces a new FRAMEPARAM opcode (0xb3), separating frame-level queries from transaction-level queries and making the model easier to reason about. In parallel, MAX_FRAMES was cut from 1,000 to 64, paired with a new per-frame gas cost, reflecting a more conservative approach to journal depth and receipt overhead.

The revision also makes several protocol interactions more precise. EIP-7702 behavior is now explicitly defined, so frame transactions do not modify delegation indicators and delegated accounts follow delegated-code semantics instead of the default path. EIP-7997 is now a formal dependency as deploy frames are tied to the deterministic factory predeploy. Approval scopes have also been converted into named constants, improving readability across the proposal.

Security hardening is another major part of the update. The changes include high-s signature rejection for secp256k1, a domain separator for P256 addresses, and new sections covering deploy-frame frontrunning, sender state-read amplification DoS, and cross-frame data visibility during validation. The canonical paymaster is also now clearly limited to secp256k1 signers only, excluding ERC-1271 and contract-signature support for now.

For developers who want to see how the proposal could look in practice, a set of frame transaction examples has also been published in a dedicated examples repo, covering end-to-end usage patterns and helping make the updated design more concrete. In addition, developers can find further information at https://eip8141.io as well as a fully interactive EIP-8141 prototype here: https://alexanderchopan.github.io/grantr/prototype/grantr-prototype.html.

Ethereum Research Maps a Privacy Path for Frame Transactions

Ethereum Research contributor Nero_eth argues that frame transactions could eliminate relayers for privacy withdrawals, but only if Ethereum’s mempool, FOCIL enforcement, and node validation rules are adjusted to support them. The post treats EIP-8141 as a given and focuses on how privacy-preserving transactions could pass through the network without depending on centralized sponsors or extra censorship surfaces.

The core idea is that a privacy withdrawal could validate itself inside a VERIFY frame, while the withdrawal flow itself covers execution costs. In that design, invalid proofs or replayed proofs would fail before payment approval, meaning no gas is charged and no external relayer is needed. The write-up uses Tornado Cash and Railgun-style withdrawals as the motivating example and argues this would let privacy protocols internalize gas payment instead of relying on off-chain relayer infrastructure.

The post then argues that privacy transactions currently fail three separate gates under default assumptions: public mempool admission, FOCIL eligibility, and node capability. The main blockers are the current VERIFY gas cap, FOCIL’s bounded validation budgets, and the fact that lighter node models such as VOPS and AA-VOPS do not track privacy-pool storage like roots and nullifiers. Under those defaults, privacy withdrawals are excluded from every standard path to censorship resistance.

To address that, the article proposes a canonical privacy pool model, recognized by code hash, plus higher VERIFY gas allowances for canonical contracts, a shift toward the validation-index FOCIL approach, and looser state-access rules for canonical privacy pools.

ETHGas and etherfi Announce $3B Blockspace Market Deal

ETHGas and ether.fi have announced a three-year commercial agreement that will commit $3 billion in ETH to ETHGas’ High Performance Staking service, with the stated goal of building more institutional-grade markets for Ethereum blockspace. The announcement frames the deal as infrastructure for forward pricing and execution guarantees, arguing that Ethereum still relies mostly on real-time blockspace auctions without tools for pre-purchase or predictable execution.

According to the release, ether.fi will allocate roughly 40% of its current ETH holdings to ETHGas’ HPS service and will use ETHGas’ preconfirmation platform exclusively during the term, subject to performance thresholds. ETHGas says this validator depth is needed to support a forward market where validators can pre-sell future block inclusion rights and buyers such as rollups, traders, solvers, and applications can secure execution in advance.

The companies position the deal around a broader institutional thesis. ETHGas argues that as more settlement activity moves on-chain, Ethereum needs instruments that look closer to commodity-style forward markets, with clearer pricing and risk management around its core resource: blockspace. ether.fi, for its part, presents the partnership as a way to expand yield opportunities for staked ETH while improving execution certainty for users.

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

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