# Mempool Strategies for EIP-8141

## Overview

EIP-8141 frame transactions are deliberately flexible at the protocol level. The transaction format itself places very few constraints on what validation and gas payment logic can do — it simply provides the primitives and leaves policy up to the execution layer.

This means the mempool has a great deal of choice in deciding what kinds of frame transactions it will accept and propagate. Different strategies trade off simplicity, security, and permissionlessness. This document outlines three progressively more ambit
ious approaches, each of which is a valid public mempool policy for EIP-8141.

A restrictive policy is fine at launch. The mempool rules can be loosened later. We currently prefer strategy no. 2 and it is fully defined in [this PR](https://github.com/ethereum/EIPs/pull/11415).

## Shared Validation Rules

All strategies use the same baseline rules:

- **Validation must be locally stable.** A transaction cannot depend on the same state as other transactions.
- **Storage reads are limited to `tx.sender` during validation.** Helper contracts may be called, but they are subject to the same rule.
- **Unstable or unsafe opcodes are banned** during validation, including block-dependent values, transaction-dependent values, state writes, balance reads, and other context-sensitive operations, with narrow exceptions for deterministic deployment and the standard `GAS -> *CALL` pattern.
- **Nodes simulate only the validation prefix in mempool**: as soon as `payer_approved` flips `true`, transaction is considered includable. This is additionally bounded by `MAX_VERIFY_GAS`. Another possibility is to allowlist accounts in the future -- with this it would be possible to avoid simulation entirely and implement the checks natively. At this time we only present it as an idea and not a proposal.
- **Only one pending frame transaction per sender** is allowed in the public mempool. This matches ERC-4337 and EIP-7702 mempool behavior.
- **External calls are allowed** only to existing, non-delegated contracts, and called code must obey the same storage/opcode restrictions.
- **Account deployment is allowed** via an initial `deploy` frame using a known deterministic deployer.
- The hard problem is **paymasters**: one paymaster can sponsor many users, which reintroduces shared dependencies. There are different approaches to handle this outlined below.

## Strategy 1: Self-Relay Only

**Policy:** only self-funded transactions are accepted in the public mempool.

**Supported prefixes:**
- `self_verify`
- `deploy -> self_verify`

**Properties:**
- simplest implementation
- full signature abstraction, i.e. full account abstraction
- minimal DoS risk
- sponsored transactions still work, but **only through bundlers/private flow**

This is more of an initial policy or specifically chosen if we intend to be very conservative.

## Strategy 2: Canonical Paymaster Support

**Policy:** support self-funded transactions plus sponsored transactions through a **standardized canonical paymaster**.

**Supported prefixes:**
- `self_verify`
- `deploy -> self_verify`
- `only_verify -> pay`
- `deploy -> only_verify -> pay`

**How it works:**
- sender approves execution
- canonical paymaster approves payment
- paymaster is recognized by exact runtime code match

**Why it is safe:**
- paymaster funds can only leave through gas payment or delayed withdrawal
- nodes reserve pending balance per paymaster instance
- this prevents one paymaster from overcommitting funds or cheaply invalidating many transactions

**Properties:**
- moderate complexity
- low DoS risk
- **native public-mempool sponsorship without a reputation system**

This is a mostly full-featured policy with native sponsorship.

## Strategy 3: Full ERC-7562

**Policy:** allow arbitrary paymasters and other entities, gated by **staking and reputation**.

**How it works:**
- staked entities get more flexible validation behavior, using banned opcodes and storage, etc
- nodes track reputation and throttle or ban misbehaving entities

**Properties:**
- highest flexibility, i.e. arbitrary paymaster contracts accepted
- highest implementation and operational complexity
- DoS risk is managed economically rather than structurally

This is likely a later-stage policy when we need flexible paymaster logic without joint agreement on what that logic should be.

## Comparison

| Strategy | Alt crypto algos | Any wallet code | Key rotation | Batching | Paymaster in public mempool | Complexity | DoS risk |
|-|-|-|-|-|-|-|-|
| 1. Self-relay only | ✓ | ✓ | ✓ | ✓ | ✘ | Low | Minimal |
| 2. Canonical paymaster | ✓ | ✓ | ✓ | ✓ | ✓ (canonical) | Moderate | Low |
| 3. Full ERC-7562 | ✓ | ✓ | ✓ | ✓ | ✓ (arbitrary) | High | Low |

Even strategy 1) gives a broad range of desired AA outcomes, including support for PQ crypto algorithms. It's mostly a spectrum of how much support should paymasters have in the public mempool and what constraints are reasonable to impose on them.

## Recommendation

Start with **Strategy 2**. It is spec'd in this PR: https://github.com/ethereum/EIPs/pull/11415

It preserves the main benefits of EIP-8141 — custom validation, account deployment, and native gas sponsorship — while keeping the security model simple and auditable. Strategy 1 is a good fallback for a very cautious release. Strategy 3 is a possible future extension.