DEV Community: Alexandra

Post-quantum accounts for $0.07 with Kohaku, gasless AI agent payments, tokenized treasury on Ethereum

Alexandra — Thu, 18 Jun 2026 09:29:15 +0000

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

This week: the Ethereum Foundation’s Kohaku project shows post-quantum account protection can ship today for $0.07 with no hard fork; Quack AI’s Q402 turns EIP-7702 into gasless stablecoin payments for AI agents; Ant International parks corporate cash in Amundi’s tokenized money market fund on Ethereum; and a new thirdweb guide maps where ERC-4337 and EIP-7702 stand in 2026.

Kohaku Brings Post-Quantum Account Protection to Ethereum for $0.07
How EIP-7702 Enables Gasless Payments for AI Agents
Ant International Adopts Amundi's Tokenized Money Market Fund on Ethereum for Treasury
Account Abstraction in 2026: How EIP-7702 and ERC-4337 Are Transforming Ethereum Wallets

Please fasten your belts!

Kohaku Brings Post-Quantum Account Protection to Ethereum for $0.07

The Ethereum Foundation’s Kohaku project has shown that post-quantum account protection can be deployed on Ethereum today for roughly $0.07 — no hard fork required. The approach uses ERC-4337 smart accounts to swap in quantum-resistant signatures at the individual account level, and it is entirely opt-in.

The technical groundwork comes from Kohaku contributor Nico (Nicolas Consigny), who published “SPHINCS-” on ethresear.ch, a family of EVM-optimized variants derived from SPHINCS+. The key insight is that the EVM already has a cheap KECCAK256 opcode, so replacing the standard’s SHAKE256 with KECCAK256 lets the verifier run natively on-chain, without a precompile or protocol change.

A Solidity verifier lands at roughly 150,000 gas (the ~$0.07 figure) and ships with a Lean 4 formal proof via Verity, a potential path to FIPS compliance on Ethereum. Lighter variants are tuned for different signers: C13 targets laptops, while C11 and C12 are designed to run on a Ledger Nano S+ secure element.

Why does this matter? Today’s Ethereum accounts rely on ECDSA signatures, which a sufficiently powerful quantum computer could eventually break and use to forge transactions. Because Kohaku is opt-in and account-level, holders, especially institutions sitting on large positions, can quantum-proof wallets now without waiting for network-wide consensus.

The Foundation’s Post-Quantum Security team, formed in January 2026 under Thomas Coratger with backing from Justin Drake, targets full protocol readiness around 2029. Further out, a “leanSPHINCS” variant with ZK-friendly hashing and STARK aggregation could push verification down to roughly 3,000 gas.

How EIP-7702 Enables Gasless Payments for AI Agents

Here’s a familiar friction point: a wallet can hold $100 in USDC and still be unable to send $20, simply because it has no native gas token. For a single user, that’s an annoyance, but when an AI agent manages multiple wallets across several chains, funding each one with the right gas token turns automation back into manual treasury work.

Quack AI’s Q402 is a useful example of how EIP-7702 solves this in practice. It lets people and AI agents send stablecoins (USDC, USDT, RLUSD) gaslessly across ten EVM networks: the payer signs a structured EIP-712 payment intent, and a relayer submits the on-chain transaction and pays the network gas.

The account abstraction mechanics are the interesting part. EIP-7702 lets an existing EOA use delegated code without moving funds to a newly deployed smart-account address; the relayer submits a Type-4 transaction, and the delegated implementation validates the payment before transferring the token. Crucially, the relayer pays gas but gains no arbitrary authority over the wallet — the signed intent stays bound to a permitted implementation.

On top of that base, Q402 layers AA-native conveniences: dedicated agent wallets with spending caps, batch and recurring payments, and programmable “hooks” that can screen recipients, enforce spend limits, or require approvals before a payment settles. Every settlement produces a signed “trust receipt” for independent verification.

Ant International Adopts Amundi’s Tokenized Money Market Fund on Ethereum for Treasury

Ant International, the owner of Alipay+, has started using tokenized money market funds to manage its corporate treasury. It is doing so through specially issued digital share classes of the Amundi Money Market Fund — Short Term, where the EUR and USD tokens are issued on the Ethereum public blockchain.

This builds on years of groundwork. Ant has used blockchain for internal treasury management since 2019 via its “Whale” platform, enabling 24/7 cross-border transfers; now it wants to maximize returns on idle cash by parking it in tokenized MMFs once the money arrives.

The arrangement runs through Europe’s largest asset manager. Amundi oversees €2.4 trillion in assets, and the deal is effectively a Credit Agricole affair — the bank owns 68.3% of Amundi, while its securities-services arm CACEIS acts as transfer and tokenization agent, minting and burning the digital shares.

It’s another concrete signal that institutional treasury operations are moving onto public Ethereum and that tokenized real-world assets are maturing into practical cash-management tools rather than pilots. “Our goal is to build a future of instant, borderless money movement,” said Kelvin Li, General Manager of Platform Tech at Ant International.

Account Abstraction in 2026: How EIP-7702 and ERC-4337 Are Transforming Ethereum Wallets

A new thirdweb guide frames account abstraction as the biggest shift in Ethereum wallets since MetaMask first launched. The argument: ERC-4337 and EIP-7702 are together replacing the rigid externally owned account (EOA) model with programmable smart accounts that handle gas sponsorship, batching, session keys, and recovery natively.

A common misconception it clears up is that EIP-7702 replaces ERC-4337 — in reality, they are complementary. ERC-4337 provides the infrastructure layer (bundlers, paymasters, the EntryPoint, and account factories), while EIP-7702, shipped in last year’s Pectra upgrade, gives every existing EOA the protocol-level primitive to use that infrastructure without first deploying a new contract.

Together, the stack unlocks the experiences users now expect: email or social login with gas sponsored behind the scenes, multiple actions bundled into a single transaction, session keys that remove repeated wallet pop-ups, and recovery through guardians instead of seed phrases.

The adoption numbers back up the shift. The guide notes that smart account deployments have surpassed 30 million across Ethereum and its L2s, with paymaster-sponsored transactions now a significant share of activity on Base, Arbitrum, and Optimism.

The takeaway is a clear directive for developers: design around smart accounts from the start, because the EOA-first model, assuming every user has MetaMask and ETH for gas, is fading fast.

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

ERC-4337 Hits Final, Starknet Brings Private DeFi, Atomic Cross-Domain Proofs, RLUSD Goes Multichain

Alexandra — Thu, 11 Jun 2026 10:26:46 +0000

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

This week: ERC-4337 reaches Final status; Starknet brings private DeFi to mainstream wallets through its STRK20 framework; a wave of privacy proposals turns the past week into an AA "privacy week," led by the pERC20 token standard; researchers publish machine-checked proofs for atomic cross-domain state sync; and Ripple spreads RLUSD across 40+ chains via Wormhole.

ERC-4337 Reaches Final
Private DeFi Comes to Starknet with STRK20
pERC20 Proposes a Privacy-Native Token Standard
Mechanized Proofs for Atomic Cross-Domain State Sync
Ripple Brings RLUSD to 40+ Chains via Wormhole

Please fasten your belts!

ERC-4337 Reaches Final

ERC-4337, the standard that brought account abstraction to Ethereum without any consensus-layer changes, has moved to Final status. The change landed as a GitHub commit from co-author Yoav Weiss, merged by the EIP-Bot, flipping the spec from "Last Call" (deadline May 26) to "Final."

Final status means the specification is now considered stable and complete. The EntryPoint contract, UserOperation flow, bundlers, and paymasters that the entire AA ecosystem builds on are locked in as a finished standard.

Authored by Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso and Tjaden Hess, and first created back in September 2021, it's a quiet milestone for a standard that reshaped how the ecosystem thinks about Ethereum wallets.

Private DeFi Comes to Starknet with STRK20

Starknet laid out how private DeFi is coming to its ecosystem through STRK20, its privacy framework for ERC-20 assets. The pitch: shielded balances, private transfers, and private app flows that live inside the wallets and apps people already use, rather than forcing users into a separate privacy app with isolated liquidity.

Users can shield assets directly from supported wallets like Ready X and Xverse, then swap, lend, or stake while keeping balances private. An anonymizing contract does the heavy lifting - for a shielded USDC → ETH swap, it unshields into the contract, routes the trade through existing Starknet liquidity (via avnu and Ekubo), and returns a fresh private note, all in one atomic transaction.

The first phase covers in-wallet shielding and swaps, with private lending (Vesu), staking (Endur), and vault strategies to follow. Amounts moving through public liquidity stay visible, and anonymity depends on the size of the privacy set, but the design breaks the direct public link between a user's wallet and their DeFi activity. Each private transaction carries a flat 4 STRK fee.

pERC20 Proposes a Privacy-Native Token Standard

The past week turned into something of a "privacy week" across the AA ecosystem, with several proposals landing at once. Chief among them: EIP-8287 (pERC20), a draft standard for privacy-native fungible tokens on the EVM.

Unlike shielded-wrapper approaches, pERC20 tokens are private from issuance; there's no public balanceOf, no approve/allowance, and no public-to-shielded conversion step. Balances and transfer amounts live as encrypted UTXO notes (an Orchard-style ZK model), while totalSupply stays public so there's no invisible inflation. A compliance "frozen root" lets specific notes be blacklisted to satisfy regulatory requirements.

The proposal is complementary to EIP-8182's private transfer layer, and it sparked immediate debate: reviewers on Ethereum Research argued its Groth16 proof system isn't quantum-safe and pushed for an FRI/PLONK-based approach - a reminder that privacy and post-quantum concerns are increasingly being designed together.

Mechanized Proofs for Atomic Cross-Domain State Sync

A new Ethereum Research post tackles a problem every multi-chain and L2 designer quietly depends on but rarely states formally: when an asset exists on several domains at once, how do you guarantee that a state change on one takes effect on the others, simultaneously or not at all?

The author formalizes "atomic cross-domain state synchronization" and proves both safety (the resulting state is consistent across every connected domain) and liveness (synchronization actually completes under Byzantine faults, f < n/3) in Isabelle/HOL - a 3,215-line machine-checked artifact with zero gaps. The model is built from seven reusable "locales" covering message priority, deadlock-free locking, and fair leader rotation, among others.

The framing is grounded in real regulatory pressure, as FATF's Travel Rule and BIS-IOSCO settlement-finality standards both effectively require that an effect (a freeze, a liquidation) hit all domains at once. For AA and chain-abstraction builders, it's a rigorous look at what "atomic composition across rollups" actually demands.

Ripple Brings RLUSD to 40+ Chains via Wormhole

Ripple has expanded its RLUSD stablecoin to more than 40 blockchain networks through Wormhole's Native Token Transfers (NTT) framework, letting the token move natively between chains without relying on wrapped versions.

The rollout brings RLUSD to Ethereum L2s including Base, Optimism, Ink, and Unichain, plus the XRP Ledger EVM sidechain. Now around $1.7 billion in market cap and the 8th-largest stablecoin, RLUSD is being positioned as compliant, USD-backed liquidity for cross-border payments, institutional on/off-ramps, and tokenized real-world assets.

For chain-abstraction builders, more native (non-wrapped) stablecoin liquidity spread across more chains is exactly the kind of substrate that intent-based and cross-chain UX runs on.

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

Base Azul multiproofs, ERC-8211 smart batching, LI.FI Intents, Vitalik's Sci-Fi pivot

Alexandra — Thu, 04 Jun 2026 09:50:04 +0000

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

This week: Base ships its first independent upgrade with a TEE+ZK multiproof system and confirms native AA is next; Biconomy turns the ERC-8211 smart batching standard into a TypeScript SDK; LI.FI launches an enterprise intents engine for stablecoin and RWA flows; and Vitalik steps back from technical essays to write fiction.

Base Launches Azul, Bringing Multiproofs to Coinbase's L2
Biconomy Ships Smart Batching SDK for ERC-8211
LI.FI Launches Intents Engine for Enterprise Cross-Chain Flows
Vitalik Pivots to Fiction and Floats a "Trust Dependency" Framework

Please fasten your belts!

Base Launches Azul, Bringing Multiproofs to Coinbase’s L2

Base activated Azul on mainnet on May 28, its first network upgrade built entirely on its own stack. The headline feature is a multiproof system that pairs Trusted Execution Environment (TEE) proofs with Zero-Knowledge (ZK) proofs, advancing the Coinbase-incubated L2 toward Stage 2 decentralization.

Either proof type can finalize a withdrawal independently, but when both agree, finality drops to as little as one day, far faster than the typical multi-day optimistic rollup wait. Crucially, permissionless ZK proofs can override permissioned TEE proofs if the two conflict, a design Base says meaningfully improves censorship resistance.

The upgrade also makes base reth the sole execution client and introduces a new consensus client, phasing out older software. Node operators must migrate to the new stack to stay in sync.

For AA and chain abstraction builders, the more important signal is what comes next: Base confirmed its end-of-June upgrade will include native account abstraction, an enshrined token standard and Flashblock Access Lists. The largest L2 by activity moving toward native AA is a meaningful pull on the whole ecosystem.

Biconomy Ships Smart Batching SDK for ERC-8211

Biconomy released the Smart Batching SDK, a TypeScript library that makes the ERC-8211 “Smart Batching” standard usable without writing any Solidity. It targets one of the most persistent pain points in batched execution: static batches that break when on-chain state shifts between signing and execution.

The core primitive is runtimeBalance(), which resolves values at execution time rather than at signing. A swap-then-supply flow can swap USDC for WETH, then approve and deposit the exact amount received, even though that amount isn’t known when the batch is signed. Constraints like slippage guards are encoded into the batch itself and enforced atomically on-chain.

This unlocks patterns that were previously awkward or impossible with static batches: dustless full-balance sweeps, ERC-4626 vault migrations across share-rate drift, approve-with-cleanup flows, and predicate-gated cross-chain execution where a destination batch waits on a condition before a solver submits it.

For builders, this is the kind of tooling that turns multi-step DeFi UX into a single signed UserOperation, without forcing developers down to the contract layer.

LI.FI Launches Intents Engine for Enterprise Cross-Chain Flows

LI.FI launched LI.FI Intents, a modular execution engine that fulfills orders through a network of professional market makers, solvers, competing to provide the best execution. The launch targets enterprises bringing stablecoin payments, real-world assets, and compliant liquidity onchain.

For payments, the engine delivers exact-output execution: send 100 USDC and the recipient receives 100 USDC or USDT with zero slippage on 1:1 swaps. Flows are gasless, with solvers fronting execution on the destination chain and routing across all major chains, including non-EVM networks like Tron and Solana.

The compliance angle is the differentiator for institutions. Integrators get full control over solver selection, including access to KYB’d solvers, verified legal entities rather than anonymous counterparties, with OFAC screening built in. Regulated firms no longer have to choose between compliance and efficiency.

LI.FI Intents is already live across apps like Jumper and wallets like Rabby, built on the infrastructure behind 1000+ enterprise integrations. For chain abstraction builders, it’s a clear signal that intent-based execution is becoming the default interface for cross-chain UX.

Vitalik Pivots to Fiction and Floats a “Trust Dependency” Framework

On May 27, Vitalik Buterin announced he is pausing his long-form technical essays to write a science fiction novel exploring decentralized governance and DAOs. He shared the news on Farcaster, noting the first two chapters are already published on his personal site.

The same day, Buterin posted a concept that resonates directly with AA and wallet security work: that in an ideal world, all software and hardware would carry “nutrition labels” listing their full set of trust dependencies, what mathematics and whose honest behaviour, on what time scale, a system relies on for its guarantees.

For account abstraction, that framing is more than philosophical. Smart accounts, paymasters, bundlers, and cross-chain solvers each introduce their own trust assumptions, and making those explicit is exactly what standards like ERC-7730 clear signing and modular registries aim toward.

The pivot also lands amid ongoing Ethereum Foundation turbulence, following Buterin’s recent post on a leaner EF focused on censorship resistance, openness, privacy, and security, values that map closely onto the infrastructure AA builders depend on.

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-7928 parallelization, native privacy roadmap, EIP-8141 deep dive, EF restructuring

Alexandra — Thu, 28 May 2026 08:49:21 +0000

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

This week: EIP-7928 and how Block-level Access Lists bring parallel execution to Glamsterdam; Vitalik maps Ethereum’s near-term native privacy roadmap around AA, FOCIL, and keyed nonces; Alex Forshtat delivers a deep dive on EIP-8141 frame transactions at ETHPrague; and Vitalik publishes his perspective on a leaner, more focused Ethereum Foundation.

EIP-7928: Block-level Access Lists Bring Parallel Execution to Glamsterdam
Mapping Ethereum’s Near-Term Native Privacy Roadmap
EIP-8141 Frame Transactions: Deep Dive from ETHPrague
Vitalik Outlines a Leaner, More Focused Ethereum Foundation

Please fasten your belts!

EIP-7928: Block-level Access Lists Bring Parallel Execution to Glamsterdam

EF researcher Toni Wahrstätter published a detailed thread breaking down EIP-7928, the execution-layer headliner for Glamsterdam alongside ePBS. The proposal adds a Block Access List (BAL) to every Ethereum block — a list of every account and storage slot the block touches, plus post-transaction state diffs showing exactly what changed after each transaction.

With state diffs available upfront, client software no longer has to discover storage locations while executing. Everything needed can be prefetched into cache in parallel before execution begins, resolving transaction dependencies in advance and enabling true parallel execution across Geth, Nethermind, Besu, Erigon, Reth, and others.

The gains are already measurable. On 6-core machines, EL clients validate blocks up to 5x faster with BALs in place. Combined with ePBS decoupling the block from the payload, giving validators 2–4x more execution time, Glamsterdam will ship with a 200M gas limit, with 300M described as a realistic near-term follow-up. Snap sync also improves: BALs let nodes skip the healing phase entirely when catching up to the chain tip.

For AA builders, higher throughput and cheaper state access directly reduce the cost of batched UserOps, gasless flows, and cross-chain intents at scale. EIP-7928 is one of the clearest signs yet that Ethereum’s base-layer scaling is moving from theory into production.

Mapping Ethereum’s Near-Term Native Privacy Roadmap

Vitalik Buterin outlined three near-term steps to make privacy a native property of Ethereum. The post extends the cypherpunk reset he outlined in January and the privacy framing he introduced at the Web3 Festival in Hong Kong earlier this spring.

The first initiative combines account abstraction with FOCIL. Right now, private transactions pass through the public mempool where block builders can see and exclude them. FOCIL changes this by allowing a committee of validators to propose transaction inclusion lists that builders are required to honour — or risk having their block rejected. Combined with AA, private transactions gain first-class inclusion guarantees at the protocol level.

The second step is keyed nonces, proposed in EIP-8250. Ethereum’s current sequential nonce model creates a bottleneck when multiple private transactions need to execute in parallel from the same account. Keyed nonces let each spend use its own nonce domain, including one derived from a privacy nullifier, making transactions on different keys replay-independent.

The third is access-layer work, centred on the Kohaku privacy toolkit and private reads. This targets the metadata layer: hiding users’ wallet queries from centralised node providers so that RPC calls don’t leak which addresses a user is watching. Buterin framed all three as essential for giving ETH true “moneyness” and argued that L1 privacy could drive more activity back to Ethereum mainnet. None of the three are live yet.

EIP-8141 Frame Transactions: Deep Dive from ETHPrague

At ETHPrague 2026, ERC-4337 core developer Alex Forshtat delivered a technical deep dive on EIP-8141, shared this week by the @erc4337 account. The talk is the clearest walkthrough yet of why frame transactions represent an endgame account abstraction design rather than another incremental layer.

The core change: instead of a single top-level execution frame, a frame transaction contains multiple frames each with an explicit role modifier. The VERIFY frame, which must end with an APPROVE opcode, handles validation and signals to the protocol that if this frame reverts, the transaction cannot be included in a valid block at all. This separates validation from execution at the protocol level, replacing the fixed ECDSA + nonce + balance check with fully programmable logic.

For builders, the practical implications are significant. Frame transactions natively support gas abstraction via a canonical paymaster, atomic batching across multiple execution frames, passkey signatures, and full backward compatibility with existing EOAs — which receive a canonical default validation code automatically. EIP-8141 also provides a clean path to post-quantum signatures: the VERIFY frame decouples transaction authorization from ECDSA entirely, so accounts can adopt quantum-safe schemes without changing their address.

EIP-8141 currently holds Considered for Inclusion status for the Hegotá fork (H2 2026). Forshtat addressed the mempool DoS risk directly: a mempool validation strategy restricts storage reads during validation to the sender’s own storage and caps verification gas at ~100,000 units, with the canonical paymaster required for public mempool propagation. The full talk is worth watching for any team thinking seriously about the native AA transition.

Vitalik Outlines a Leaner, More Focused Ethereum Foundation

On May 24, Vitalik Buterin published a lengthy post on X addressing months of turbulence at the Ethereum Foundation, defending its restructuring and laying out his personal view of the EF’s long-term direction. The post came after eight senior EF contributors left or announced departures in 2026, five of them in May, including all three Protocol Cluster leads.

Buterin framed the EF’s mandate around what he called the CROPS dimension: censorship resistance, capture resistance, openness, privacy, and security. He argued that maximising throughput and speed at the expense of these properties leads to mediocrity, and that Ethereum should be “deeply impressive” on CROPS rather than competing on execution speed alone. He also noted that the EF holds only 0.16% of all ETH, far below the 10–50% typical for other blockchain foundations, and committed to reducing ETH sales to prioritise longevity.

On governance, Buterin confirmed that interim co-executive director Bastian Aue is leading the transition, that the board is expanding, and that his own influence within the EF will continue to decrease — which he described as the outcome he wants. He also pointed to AI-assisted formal verification as a near-term path to making Ethereum provably bug-free.

For the AA ecosystem, the CROPS framing matters directly. Privacy and censorship resistance, two of the five pillars, map precisely onto the work covered elsewhere in this issue: the native privacy roadmap, FOCIL, and EIP-8141’s design goals around uncensorable transaction inclusion and signature agility. The EF’s stated focus, whatever the organisational turbulence, remains aligned with the infrastructure AA builders depend on.

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

Glamsterdam interop milestones, clear signing launch, EIP-7851 redesign, quantum-safe MPC

Alexandra — Thu, 21 May 2026 11:02:41 +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 locks in Glamsterdam devnet milestones and a new Protocol cluster leadership at Soldøgn interop, the EF launches an open clear signing standard built on ERC-7730, EIP-7851 is redesigned around a new opcode that lets wallet code permanently burn ECDSA authority, and Silence Laboratories ships the first quantum-safe MPC infrastructure for institutional custody.

Ethereum's Glamsterdam Roadmap Takes Shape After Soldøgn Interop
EIP-7851: Code-Controlled EOA Delegation
Ethereum Foundation Launches Clear Signing Standard to End Blind Approvals
Silence Laboratories Launches First Quantum-Safe MPC Infrastructure for Digital Asset Custody

Please fasten your belts!

Ethereum’s Glamsterdam Roadmap Takes Shape After Soldøgn Interop

The Ethereum Foundation Protocol cluster published an update from a week-long core dev interop gathering in Svalbard, Norway, outlining the key milestones reached for the upcoming Glamsterdam upgrade. Teams focused on hardening and preparation across nearly all clients.

A 200M gas limit floor was established as a credible post-Glamsterdam target, derived from convergence of ePBS, BAL optimizations, and EIP-8037 repricing. ePBS is now stabilized with a multi-client Glamsterdam devnet running and the external builders pipeline tested end-to-end.

EIP-8037 was finalized, adopting a fixed cost_per_state_byte model with full repricing numbers delivered on bal-devnet-6. On the Hegotá side, FOCIL prototypes are functional, native AA requirements were scoped, and the multi-client devnet is the immediate next step.

The week also marked a leadership transition in the EF Protocol cluster. Will Corcoran, Kev Wedderburn, and Fredrik will take over from Tim Beiko, Barnabé Monnot, and Alex Stokes — Barnabé and Tim are moving on from the EF, while Alex Stokes will be on sabbatical. Together, they coordinated shipping Fusaka to mainnet in December 2025.

For AA builders, cheaper state access via EIP-8037 and a path toward native AA in Hegotá reduce the cost of running batched UserOps and gasless flows at scale. Beyond immediate upgrade work, Soldøgn participants also discussed Ethereum’s broader long-term account abstraction goals, including support for alternative signature schemes, native batching, key rotation and recovery, signature aggregation compatibility, relayerless sponsorship, and unified cross-chain account identities. Discussions also emphasized preserving Ethereum’s core constraints around public mempool compatibility, censorship resistance, bounded validation costs and minimizing complexity for L2s. The direction signals continued momentum toward more native protocol-level AA capabilities while maintaining compatibility with future roadmap items such as FOCIL, statelessness and zkEVMs. Glamsterdam devnets are now live.

EIP-7851: Code-Controlled EOA Delegation

We covered EIP-7851 in an earlier issue. The spec has since been significantly updated by Liyi Guo and Nicolas Consigny, and the new design is worth a close look for any team building on EIP-7702.

The proposal has been redesigned around a new EVM opcode, SETSELFDELEGATE. Rather than a separate system contract with a time-delayed deactivation, wallet code itself calls the opcode to rewrite the account’s delegation prefix from 0xef0100 to 0xef0101, instantly and permanently disabling the original ECDSA key’s authority.

The core invariant: once ECDSA authority is disabled, it can never be restored. However, the delegate address is not frozen; the wallet code can still call SETSELFDELEGATE to update the delegation target while staying ECDSA-disabled. It is the original key that is burned, not the ability to redelegate through code.

This is a cleaner design than the previous version. The old spec required EOAs to call a system contract and wait 7 days before deactivation finalized. The new approach puts control directly in the wallet code, with no delay and no separate scheduling step.

The post-quantum angle remains the same: permanently disabling ECDSA authority removes the signature scheme most exposed to future quantum computing threats, while smart wallet code can adopt quantum-safe signing from day one.

Ethereum Foundation Launches Clear Signing Standard to End Blind Approvals

An Ethereum Working Group of wallet developers, security firms, and the EF’s Trillion Dollar Security Initiative launched an open standard to end blind signing — a structural flaw behind billions in user losses, including the Bybit hack.

The standard centers on ERC-7730, a shared format for human-readable transaction descriptions. Anyone can submit descriptors to a public registry at clearsigning.org; accuracy is verified through independent attestations, and wallets decide which sources they trust.

The 1TS Initiative hosts the registry as a credibly neutral steward. Tooling, including Rust and TypeScript libraries funded through 1TS, is available to developers at clearsigning.org.

Contributors include MetaMask, Trezor, Fireblocks, WalletConnect, Keycard, ZKnox, Sourcify, Cyfrin, Zama, Argot, and independent contributors. Ledger is credited for initiating ERC-7730 and the early tooling, infrastructure, and educational efforts.

For EIP-7702 and ERC-4337 teams, batched transactions and UserOperations are the hardest flows for users to verify today. ERC-7730 descriptors let your contracts present human-readable summaries — a prerequisite for institutional adoption.

Silence Laboratories Launches First Quantum-Safe MPC Infrastructure for Digital Asset Custody

Silence Laboratories launched what it describes as the first quantum-safe MPC infrastructure for digital asset custody. The system combines ML-DSA, NIST’s 2024 post-quantum signature standard, with MPC, letting institutions begin migrating without replacing their existing custody setup.

The infrastructure is modular, integrating with existing governance frameworks rather than requiring a full rebuild. It also incorporates trusted execution environments such as Google Cloud Confidential Computing to isolate sensitive signing operations.

Launch partners include BitGo, ZenGo, EigenLayer, Networks for Humanity, and Bron Wallet as wallet builders, with Infosys as system integrator. The infrastructure is available immediately to select design partners.

Read alongside EIP-7851, a concrete post-quantum migration path is forming: migrate to EIP-7702, deactivate the ECDSA key via EIP-7851, and back the new signing authority with quantum-safe MPC. For wallet and AA teams starting to plan for key security, both deserve close attention.

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 Proof Verification, Ethereum’s Native AA Path, Cross-Protocol Parlays, 7702 Infrastructure Trends

Alexandra — Thu, 14 May 2026 08:18:09 +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 research explores native proof verification and the long-term case for protocol-level account abstraction, while new frameworks push cross-protocol execution and the 7702 Collective doubles down on infrastructure-led adoption trends for 2026.

Deep Dive on Ethereum Accounts Maps the Case for Native AA
Native Proof Verification Draft Targets Rollup Verifier Complexity
Exploring 7702 and 8141 for Prediction Market Parlays
7702 Collective Call Highlights Infrastructure Trends for 2026

Please fasten your belts!

Deep Dive on Ethereum Accounts Maps the Case for Native AA

A new long-form essay revisits Ethereum’s account model to explain why account abstraction remains such a persistent design goal. The piece starts from first principles, walking through elliptic curve cryptography, ECDSA, public key recovery, and the distinction between externally owned accounts and contract accounts before connecting those mechanics to Ethereum’s current UX constraints. Its central argument is that Ethereum’s account system still sits between two imperfect extremes: EOAs have autonomy but little programmability, while smart contract wallets are flexible but still depend on EOAs for protocol-level authentication.

From there, the article outlines the practical consequences. EOAs cannot natively batch actions, cannot express richer validation rules, and must always pay gas in ETH. Smart contract wallets solve many of those issues, but only through extra infrastructure or by relying on an EOA somewhere in the flow. The essay presents this as the root of Ethereum’s “account dilemma,” where user authentication, authorization, execution logic, and fee payment remain only partially abstracted.

The article then surveys the current design space. ERC-4337 is presented as the main out-of-protocol smart account framework, improving sponsorship and custom logic at the cost of added complexity and alternative mempool infrastructure. EIP-7702 is described more narrowly as an EOA enhancement mechanism that lets EOAs temporarily delegate execution logic.

The strongest emphasis, however, is on EIP-8141 frame transactions, which the author argues come closest to enabling protocol-native smart accounts by separating validation and execution into explicit transaction phases while preserving room for batching, sponsorship, and broader signature support.

The broader takeaway is that the account abstraction debate is not only about wallet UX. It is also about Ethereum’s future authentication model, public mempool design, post-quantum readiness, and how much flexibility the protocol should expose directly rather than outsourcing to application-layer infrastructure.

Native Proof Verification Draft Targets Rollup Verifier Complexity

A new Ethereum Research post proposes native proof verification, a design that would move more proof-checking logic into Ethereum’s L1 infrastructure instead of leaving rollups and ZK applications to maintain their own verifier contracts, adapters, dispatchers, and upgrade paths. The draft argues that today’s model is duplicated and governance-heavy, especially for systems that need to patch verifier bugs or upgrade zkVM stacks over time.

The core idea has two parts. First, it suggests generalizing EIP-8025, so Ethereum’s consensus-layer proof verification becomes program-agnostic, rather than limited to L1 execution proofs. Second, it proposes a new proof-carrying transaction type plus three opcodes, PROGRAMHASH, PUBVALUESHASH, and PROOFCOUNT, so smart contracts can access proof metadata directly. In that model, contracts would no longer verify raw proofs themselves, but instead check standardized proof identifiers and public-output hashes exposed by the protocol.

The post positions this as useful not only for rollups, but also for privacy systems, ZK coprocessors, identity applications, and ZK ML workloads that currently rely on bespoke on-chain verification stacks. It also sketches how this could simplify multi-verifier setups such as Taiko’s, and how native rollups could inherit L1 verifier updates automatically through client releases rather than contract-governance upgrades.

At the same time, the author flags a major open problem: program hash stability. If zkVM upgrades change the hash pinned on-chain, rollups could still be forced into governance-driven upgrades, undermining the proposal’s main benefit. Because of that, the post is best read as an ambitious architectural direction rather than a finalized path to adoption.

Exploring 7702 and 8141 for Prediction Market Parlays

Accountless published a research framework for “Frame-o-lays,” outlining how cross-protocol parlays could work across on-chain prediction markets using account abstraction. The piece argues that today’s parlay products are still siloed inside individual platforms such as Polymarket, Kalshi, SX Bet, and third-party wrappers, with no shared permission or execution layer that lets users combine legs across protocols in one unified wager.

The paper breaks the problem into standard parlay primitives like markets, outcomes, legs, stake, and settlement, then maps those against account-layer requirements such as permissions, gas, batching, and cross-protocol execution. Its main claim is that the real bottleneck is not only parlay design, but wallet and permission infrastructure. To make cross-protocol parlays practical, users need scoped delegation, batched execution, value limits, and gas abstraction across multiple contracts.

Two implementation paths are proposed. The first uses live standards available today, centered on EIP-7702, smart sessions, ERC-4337 and Permit2. This path is positioned as the practical near-term option for same-chain execution. The second uses EIP-8141 frame transactions, which the article describes as a cleaner long-term design for atomic cross-protocol execution once the proposal is available. In both cases, the framework targets same-chain parlays first, while explicitly leaving cross-chain atomicity, privacy, identity, and oracle coordination out of scope.

The author argues that if one permission flow can authorize atomic execution across multiple prediction protocols, the same pattern could extend to DeFi strategies, DAO actions, and other multi-step workflows. In that framing, the parlay is the product, but the permission layer is the real infrastructure.

7702 Collective Call Highlights Infrastructure Trends for 2026

A recent X Broadcasting, The Real State of Crypto Innovation: Looking into the 7702 Collective’s Report, brought together builders from across the ecosystem to discuss where Web3 infrastructure is heading in 2026.

The 7702 Collective’s published report presents account abstraction, modular infrastructure, and intents as the three main rails for adoption, arguing that crypto’s next growth phase will depend less on narratives and more on removing complexity for users and developers.

It also describes EIP-7702 as a key unlock for expanding smart account functionality to a much wider base of existing wallets, while chain abstraction is framed as the path toward making multi-chain activity invisible at the product level.

Another major theme is AI agents. The report argues that smart accounts, intents, and chain abstraction are starting to form the infrastructure layer these systems need to route payments, manage liquidity, and execute actions across ecosystems.

Overall, both the call and the report reinforce the same message: the next stage of crypto adoption will depend on standardization, interoperability, and turning infrastructure advances into real products.

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

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