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

Etherspot Website | X | Discord | Telegram | Github | Developer Portal