EIP-8223: Contract Payer Transaction
Author: Ben Adams (@benaadams) Status/Category: Draft, Standards Track, Core Created: April 11, 2026 Requires: EIP-1559, EIP-2718, EIP-7708 Latest spec: EIP-8223 PR #11509
At a Glance
What it is. A sponsored-transaction mechanism where gas for a call is charged directly to the target contract (tx.to), gated by a single canonical payer-registry predeploy at address(0x13). There is no EVM execution in the validation path: one SLOAD reads the registry, one balance check confirms funds, and the sender's signature is verified.
Problem it solves. It gives contracts a way to statically sponsor gas for a registered EOA without any wallet-side validation logic, an escrow contract, or a relayer network, and without the mempool cost of simulating arbitrary account code.
Why an EIP-8130 reader should care. EIP-8130 already solves sponsorship through its own payer / payer_auth fields and SPONSOR_PAYER scope bit, resolved through the Account Configuration contract and a signed payer authorization. EIP-8223 solves the same narrow problem (contract pays gas for a sender) with a different, registry-based binding model and explicitly positions itself as infrastructure any general AA proposal, EIP-8130 included, could consume rather than compete with.
Overview
EIP-8223 introduces a new EIP-2718 sponsored transaction type (gas charged to tx.to), but unlike EIP-8130's AA_TX_TYPE (0x79) it carries no account-configuration machinery of its own; sponsorship is keyed off a predeploy and a two-sided opt-in. A contract that wants to sponsor gas for a specific EOA calls authorize(sender) on the registry at address(0x13), registering that EOA as the one address it will pay for. A sender who wants to use that sponsorship submits a transaction of the sponsored type addressed at that same contract. Binding is implicit in tx.to: sponsorship activates only when the transaction calls the payer contract itself, with no separate opt-in field on the transaction.
The design is deliberately narrow. It does not attempt programmable payment logic, per-call spending policies, or arbitrary account code in the validation path. It is closer in spirit to a hard-coded allowance than to a general payment authorization system.
Core Design
- Payer Registry Predeploy (
0x13): a direct-slot storage mapping. Any contract callsauthorize(sender)to register a single authorized EOA for gas sponsorship. No EVM execution is needed to read it; a node performs a plain SLOAD. - Validation flow (no EVM execution at all):
- Extract
tx.to. - One SLOAD from
0x13to read the authorized sender registered fortx.to. - Verify the sender's signature matches the authorized sender.
- One balance check on
tx.toconfirming it coversmax_fee_per_gas * gas_limit.
- Extract
- Real balance transfers, not escrow: the payer contract funds the sender, the sender pays gas through standard EIP-1559 mechanics, and unused gas is refunded to the payer. Every transfer emits an EIP-7708 Transfer log.
- Cardinality: one-to-one from payer to sender (a payer contract authorizes exactly one sender at a time) but many-to-one from sender to payer (a single sender can be authorized by many different payer contracts). Key rotation is atomic: calling
authorize(newEOA)replaces the prior authorization outright. - Two-sided opt-in: the contract must call
authorizebefore any sponsorship is possible, and the sender must choose to submit the sponsored transaction type. Neither side can force the arrangement on the other.
Mempool Strategy
Validation is purely static: account-trie reads plus one SLOAD from a known predeploy, with no EVM code execution whatsoever. There are no banned-opcode lists, no validation gas caps, and no prefix simulation to reason about, because there is no arbitrary code to simulate in the first place. This makes EIP-8223 strictly compatible with FOCIL inclusion lists and with VOPS partial-statelessness assumptions: a VOPS node only needs to additionally retain the 0x13 storage trie to validate sponsored transactions, since every other read is a plain account-trie access.
EIP-8223 does not decouple signature schemes from the protocol. It authenticates against a secp256k1 sender only and makes no claims toward post-quantum signature agility.
Key Differences from EIP-8130
| Aspect | EIP-8223 | EIP-8130 |
|---|---|---|
| Scope | Narrow: static gas sponsorship only | General: full account abstraction (custom auth, batching, gas sponsorship) |
| Sponsorship binding | Implicit via tx.to matching a registered payer contract | Explicit payer field + signed payer_auth, checked against SPONSOR_PAYER scope |
| Sponsor authorization store | Single-slot mapping at predeploy 0x13, one sender per payer | actor_config slot per actor in the Account Configuration contract, with scope bitmask |
| Validation-path execution | None: SLOAD + balance check + signature check only | STATICCALL to an authenticator contract for non-native schemes; native ecrecover for the K1_AUTHENTICATOR sentinel path |
| Sender authentication | secp256k1 only | secp256k1 native ecrecover, or any canonical authenticator (P-256, WebAuthn/passkey, delegate), with new schemes added via a companion ERC |
| Batching / calls | Not addressed; single call implied by sponsorship of tx.to | Two-level call-phase model (calls), atomic within a phase, phases commit independently |
| Signature-scheme agility | None; not a decoupling proposal | Canonical authenticator allowlist, extensible via companion ERC, quantum-safe-by-default account creation (DEFAULT_EOA_REVOKED set on create/import) |
| Mempool validation cost | Minimal: static reads only, no EVM | Predictable but heavier: authenticator-identity allowlist check, actor_config SLOAD, nonce/expiry checks, optional payer resolution |
| New transaction type | Yes, a sponsored EIP-2718 type (gas charged to tx.to), with no account-configuration machinery | Yes, AA_TX_TYPE = 0x79 |
| Positioning | Explicitly complementary: "infrastructure consumed by any future general solution, not deprecated by it" | Positioned as a complete general-purpose AA replacement |
Activity
EIP-8223 has a single PR: ethereum/EIPs#11509, opened by benaadams on April 11, 2026. As of July 15, 2026, it is very early stage: no merged changes, no review cycle, and no established community consensus yet. Discussion thread: EthMagicians: EIP-8223 Contract Payer Transactions.
Strengths
- Minimal validation surface: a single SLOAD and a balance check make the mempool cost of accepting a sponsored transaction essentially deterministic and cheap.
- Compatible with statelessness efforts: strict VOPS compatibility means it does not add meaningfully to witness or state-growth burdens beyond the registry trie itself.
- Clean two-sided opt-in avoids the escrow-management and pre-funding complexity of programmable sponsorship models.
- Narrow scope makes it easy to reason about and easy to ship independently of a broader AA standardization effort.
Weaknesses
- No programmable sponsorship logic: a payer contract can authorize exactly one sender at a time, with no spending caps, no per-call policy, and no batching.
- No signature-scheme agility; it offers nothing toward the post-quantum transition that motivates several of the general-purpose proposals.
- Very early stage, a single PR with no recorded review discussion yet, so its design has not been pressure-tested by the community in the way EIP-8130's authenticator model or EIP-8141's frame model have been.
- Because sponsorship binds to
tx.to, a contract can only ever sponsor calls to itself, not arbitrary third-party calls the sender might want funded.
Continue with Competing Standards for the comparative analysis, or return to the Home page.