EIP-8141 Frame Transaction

Appearance

EIP-8223: Contract Payer Transaction ​

Author: Ben Adams (@benaadams) Status: Draft (PR #11509) | Category: Core (Standards Track) Created: April 11, 2026 Requires: EIP-1559, EIP-2718, EIP-7708

At a Glance ​

What it is. A sponsored-transaction type where gas is charged to tx.to, gated by a canonical payer-registry predeploy at address 0x13.

Problem it solves. Delivers narrow static gas sponsorship with no EVM execution in validation (one SLOAD plus a balance check), making the sponsorship path trivially FOCIL- and VOPS-compatible. A contract can register itself as the payer for a specific user, and the transaction's validation is bounded cryptographic plus two state reads.

Why an EIP-8141 reader should care. EIP-8223 is explicitly complementary, not competing. It covers the static-sponsorship slice that EIP-8141's canonical paymaster also addresses, and its author frames it as "infrastructure consumed by any future general solution." Reading it clarifies where the boundary between "general AA" and "narrow sponsorship primitives" lands.

Overview ​

EIP-8223 introduces a new EIP-2718 transaction type where gas fees are charged to the target contract (tx.to), gated by a canonical payer-registry predeploy at address(0x13). Unlike EIP-8141 and EIP-8175, which provide general-purpose sponsorship through in-transaction EVM execution, EIP-8223 covers the narrower case where static validation is sufficient: one SLOAD from the registry plus one balance check, no code execution during validation.

The proposal explicitly positions itself as complementary, not competing, to frame-based proposals. The PR description notes: "The payer registry predeploy is infrastructure consumed by any future general solution, not deprecated by it. The registry mechanism could also be expressed as a capability or frame mode within those formats."

Core Design ​

Payer Registry Predeploy (0x13): A system contract where any contract can call authorize(sender) to register a single authorized EOA for gas sponsorship. Storage layout uses direct-slot mapping for static validation compatibility.

Validation Flow (no EVM execution):

  1. Extract tx.to from the transaction envelope.
  2. One SLOAD from the registry at 0x13 to read the authorized sender for tx.to.
  3. Verify the sender signature matches the authorized sender.
  4. One balance check on tx.to to cover max_fee_per_gas * gas_limit.

Gas Flow: Real balance transfers (not escrow abstractions). The payer contract funds the sender, the sender pays gas via standard EIP-1559 mechanics, and unused gas refunds return to the payer. Every transfer emits an EIP-7708 Transfer log. Receipts, effectiveGasPrice, and gas-related logs work identically to EIP-1559.

Two-Sided Opt-In:

  • Contract side: an explicit registry.authorize(sender) call (never implicit).
  • Sender side: choosing the sponsored transaction type per transaction.

Binding via tx.to: Sponsorship only activates when the transaction calls the payer contract itself. No additional transaction field needed.

One-to-One (payer → sender), Many-to-One (sender → payers): Each payer authorizes exactly one sender (O(1) mempool revalidation). Many payers can authorize the same EOA, enabling one signer to control multiple self-paying accounts.

Key Rotation: authorize(newEOA) replaces the prior authorization atomically. The old key is instantly deauthorized. Account assets never move, only the controlling key changes.

Mempool Strategy ​

Validation is purely static:

  • Account-trie reads (standard).
  • One SLOAD from a known predeploy (0x13).
  • No EVM code execution.

This is strictly compatible with FOCIL inclusion lists and VOPS partial statelessness: a VOPS node only needs to additionally retain the storage trie for 0x13. No banned opcode lists, no validation gas caps, no prefix simulation.

Key Differences from EIP-8141 ​

AspectEIP-8223EIP-8141
ScopeGas sponsorship only, via static payer registryGeneral-purpose AA: validation, execution, sponsorship
New opcodesNone5 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM)
System contractsCanonical payer registry at 0x13Canonical paymaster (mempool policy only, not consensus)
Validation model1 SLOAD + balance check, no EVMProgrammable EVM in VERIFY frames
Signature schemessecp256k1 sender onlyArbitrary via account code
Sponsorship bindingVia tx.to (no extra field)VERIFY frame authorizing payer
Atomic batchingNot addressedFlags field bit 2 on consecutive SENDER frames
VOPS/FOCIL compatibilityNative (adds only 0x13 storage trie to VOPS baseline)Requires bounded state access discipline
Async executionCompatible (no EVM in validation)Incompatible
EIP-7702 interopComposable (EOA delegates, then authorizes sponsor)No authorization list

Use Cases Highlighted ​

  • Smart contract accounts that pay their own gas when called (controller EOA needs no ETH).
  • Key rotation without asset migration.
  • EIP-7702 + EIP-8223 composition: cold EOA-1 delegates to smart wallet code, then authorizes hot EOA-2. EOA-2 sends sponsored transactions with zero balance; EOA-1 retains master control.
  • Protocol-funded operations: protocol deploys a scoped smart account, funds it from treasury, authorizes an operator EOA. Handover is a single authorize(newOperator) call.

Activity ​

Strengths ​

  • FOCIL/VOPS-native: Only one additional storage trie (0x13) needs to be kept. Addresses the "choose 2 of 3" trilemma head-on for the sponsored-transaction subset.
  • No EVM in validation: Deterministic cost, trivial mempool implementation, compatible with encrypted mempools and async execution models.
  • Real balance transfers, not escrow: Uses standard EIP-1559 accounting and EIP-7708 Transfer logs. Nothing new to index.
  • Complementary framing: Explicitly scoped to static-sponsorship cases; does not attempt to replace frame-based general AA.

Weaknesses ​

  • Sponsorship only: Does not provide programmable validation, alternative signature schemes, or PQ support.
  • One sponsor per contract: One-to-one binding limits multi-tenant payer patterns without separate contracts per user.
  • Limited binding: Activation requires tx.to to be the payer contract, which constrains the transaction shape and conflicts with patterns where the target is a different application contract.
  • Very early stage: PR opened April 11, 2026. No review cycle, no community consensus yet.

Continue with Competing Standards for the comparative analysis, or return to the Home page.