EIP-8223: Contract payer transactions

Discussion topic for https://eips.ethereum.org/EIPS/eip-8223

EIP-8223 introduces a new EIP-2718: Typed Transaction Envelope transaction type — the sponsored transaction —
where gas fees are charged to the contract at tx.to rather than to the transaction sender. Authorization is
managed through a canonical payer registry predeploy at 0x13: the target contract explicitly registers a single
authorized sender, and the protocol checks this during validation with one storage read — no EVM code execution
required.

Core design:

  • Two-sided opt-in. The payer contract calls registry.authorize(sender) to register who can charge gas to it. The
    sender opts in per-transaction by choosing the sponsored transaction type. Neither side can be enrolled without
    explicit action.
  • Binding via tx.to. Sponsorship only activates when the transaction is directed at the payer contract itself. No
    additional transaction field is needed — tx.to serves as both the call target and the gas payer.
  • One-to-one authorization. Each payer authorizes exactly one sender. Combined with a one-sponsored-tx-per-sender
    mempool rule, this gives O(1) revalidation per payer when balances or registry entries change.
  • Static validation. Validation requires only account-trie reads (sender nonce/balance, payer balance, payer code)
    plus one SLOAD from the payer registry predeploy. No code execution, no arbitrary contract storage. Compatible
    with FOCIL inclusion lists and
    https://ethresear.ch/t/a-pragmatic-path-towards-validity-only-partial-statelessness-vops/22236 — a VOPS node only
    needs to additionally retain the storage trie for 0x13.
  • Real balance movements for EIP-7708. The payer funds the sender before gas escrow, the sender pays gas via
    standard EIP-1559 mechanics, and the sender returns the unused refund to the payer after execution. Every transfer
    is a real state change that emits an EIP-7708: ETH transfers and burns emit a log log. Receipts, effectiveGasPrice,
    and all gas-related logs work identically to EIP-1559 transactions.

Primary use case: Smart contract accounts (like Update ERC-7821: Remove Call Struct from Specification by McOso · Pull Request #883 · ethereum/ERCs · GitHub NFT-controlled accounts)
that pay their own gas when called, eliminating the need for the controller EOA to hold ETH or use a relayer.

Relationship to other proposals: This EIP is complementary to EIP-8141: Frame Transaction (Frame
Transaction) and EIP-8175: Composable Transaction (Composable Transaction), which provide more general
sponsorship through in-transaction code execution. EIP-8223 covers the narrower case where static validation is
sufficient, and its registry mechanism could also be expressed as a capability or frame mode within those formats
if they ship first.

Update Log

  • 2026-04-11: Initial draft

External Reviews

None as of 2026-04-11.

Outstanding Issues

  • 2026-04-11: Final SPONSORED_TX_TYPE value — 0x07 is provisional and may conflict with other draft EIPs targeting
    the same fork.
  • 2026-04-11: Final PAYER_REGISTRY_ADDRESS — 0x13 is the next available address after EIP-7997 (0x12) but depends
    on EIP-2537 and EIP-7997 both shipping in a prior fork.
  • 2026-04-11: Whether EIP-7702 delegated accounts should be permitted as payers — a delegation change on tx.to
    after a sponsored transaction enters the mempool changes the code that will execute without triggering
    revalidation under the current spec.
  • 2026-04-11: Whether the Authorized event in the payer registry predeploy should be kept or removed for
    consistency with other system contracts (EIP-4788, EIP-2935) that emit no events.