EIP-8202: Scheme-Agile Transactions
Authors: Giulio Rebuffo (@Giulio2002), Ben Adams (@benaadams) Status: Draft | Category: Core (Standards Track) Created: March 22, 2026 Requires: EIP-2, EIP-155, EIP-1559, EIP-2718, EIP-2780, EIP-4844, EIP-7702, EIP-7976 Latest spec: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8202.md
At a Glance
What it is. A new EIP-2718 transaction type (0x05), SchemedTransaction, that pairs a single execution payload with a typed authorizations list for scheme-agile sender proofs (secp256k1, P256, Falcon-512) and a typed extensions list for flat protocol features (blobs, set-code delegations).
Problem it solves. Gets post-quantum signatures and passkeys onto L1 as a fixed, protocol-defined menu of signature schemes, without building a general account-abstraction system around them.
Why an EIP-8130 reader should care. EIP-8130 also needs signature-scheme agility, but solves it with a canonical authenticator contract set that nodes allowlist and a companion ERC governs over time. EIP-8202 instead bakes the scheme choice directly into the protocol as a scheme_id enum, with Falcon-512 shipped in the initial merged spec rather than deferred to a future authenticator addition. The two proposals disagree on whether scheme-agility belongs in an extensible contract registry or a fixed protocol enum. EIP-8130 additionally carries a full account-abstraction system (actors, scopes, policies, sponsorship, 2D nonces) that EIP-8202 does not attempt.
Overview
EIP-8202 defines SchemedTransaction, a single canonical envelope: one EIP-1559 fee header, one (to, value, data) execution payload, and two typed attachment lists. authorizations carry scheme-agile sender proofs; extensions carry orthogonal protocol features. The design deliberately forbids recursive transaction composition: one execution payload only, no frames, no nested execution contexts, no new account model.
This puts EIP-8202 at the narrow end of the account-abstraction design space. It does not introduce actors, scopes, authenticated call policies, gas sponsorship, or portable account creation, the areas where EIP-8130 spends most of its spec surface. EIP-8202's ambition is narrower: let any transaction use any protocol-registered signature scheme, including a post-quantum one, without adding contract execution to validation.
Core Design
Single execution payload. Every transaction has exactly one (to, value, data) call or create. No frames, no phases, no batching primitive.
Authorization list. authorizations is a list of typed [role_id, scheme_id, witness] tuples. Only ROLE_SENDER is currently defined; ROLE_PAYER is reserved but undefined, so EIP-8202 has no gas-sponsorship mechanism yet. Three initial schemes ship in the merged spec:
SCHEME_SECP256K1 (0x00)- standard ECDSA, same address derivation as legacy EthereumSCHEME_P256 (0x01)- P256/secp256r1 for passkeys, requires the EIP-7951 P256 precompileSCHEME_FALCON512 (0x02)- Falcon-512 post-quantum signatures, the first native PQ scheme defined at the transaction layer
A new scheme is added by registering a new scheme_id; no envelope change is needed, though implementing the verification logic itself is still a protocol change requiring a hard fork. The original pre-merge design used an ephemeral secp256k1 scheme with Merkle-committed one-time keys for hash-based PQ safety; the merged version replaced it with direct P256 and Falcon-512 schemes, a shift toward direct PQ cryptography over hash-based approaches.
Extension list. extensions carries typed [extension_id, extension_payload] entries. EXT_BLOB (0x01) carries EIP-4844 blob fields. EXT_SET_CODE (0x02) carries EIP-7702-style set-code authorizations, but replaces (y_parity, r, s) with (scheme_id, witness), making delegation itself scheme-agile.
Envelope:
0x05 || rlp([
chain_id, nonce,
max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
to, value, data,
authorizations, extensions
])No access list is included; the design cites EIP-7928 and EIP-7981 as reasons transaction-level access lists are being deprecated.
Mempool Strategy
EIP-8202's validation stays close to Ethereum's existing transaction processing:
- secp256k1: identical to current validation. Ecrecover, nonce check, balance check, no EVM.
- P256: a single P256VERIFY precompile call, deterministic cost.
- Falcon-512: Falcon signature verification, deterministic cost.
Because composition is flat and there is no arbitrary EVM in validation, there are no banned-opcode lists, no validation gas caps, and no prefix simulation. The spec states this directly: it "intentionally forbids recursive transaction composition" to avoid "drifting into frame-transaction validation complexity."
This is a stricter validation model than EIP-8130's. EIP-8130 also avoids simulating arbitrary wallet bytecode, but it does so by checking authenticator identity against a node allowlist, then dispatching a STATICCALL to that authenticator contract (or, for the reserved K1_AUTHENTICATOR sentinel, a direct ecrecover). A chain may enshrine canonical authenticators at a fixed gas cost, but the authentication step is still a contract call into an audited allowlist member, not a closed-form cryptographic check. EIP-8202 has no contract-call step in validation at all, at the cost of needing a new EIP and hard fork for every additional scheme.
Key Differences from EIP-8130
| Aspect | EIP-8202 | EIP-8130 |
|---|---|---|
| Composition model | Flat: one execution payload plus typed extensions | Typed account_changes plus two-level call phases (atomic within a phase; phases commit independently in sequence) |
| New opcodes | None | None (uses the Account Configuration Contract, a Nonce Manager precompile, and a Transaction Context precompile) |
| Tx type | 0x05 | 0x79 (AA_TX_TYPE); 0x7A is not a separate type, it is a payer-signature domain-separation byte |
| Signature agility mechanism | scheme_id enum, registered directly in the protocol | Canonical authenticator contract set, allowlisted by nodes, extensible via a companion ERC |
| PQ strategy | Falcon-512 shipped natively at merge (scheme_id 0x02) | No PQ authenticator in the initial canonical set (k1, P256, WebAuthn/passkey, delegate); PQ would arrive as a future canonical authenticator via the companion-ERC process |
| Validation model | Purely cryptographic: ecrecover or precompile call, no contract execution | Bounded contract execution: STATICCALL to an allowlisted authenticator, or an enshrined fixed-cost equivalent |
| Mempool complexity | Minimal: deterministic crypto cost only | Low to moderate: one actor_config SLOAD plus an allowlisted-authenticator call; no simulation of non-canonical code |
| Gas sponsorship | ROLE_PAYER reserved but undefined | Full payer model: payer/payer_auth fields, SELF_PAYER/SPONSOR_PAYER scope grants, domain-separated sender/payer signature hashes |
| Atomic batching | Not supported (single execution payload) | Two-level call phases: atomic within a phase, later phases skipped on an earlier phase's revert, completed phases persist |
| Account model | None; operates over existing addresses | Full account-configuration system: actors, scopes (SENDER/POLICY/NONCE/SELF_PAYER/SPONSOR_PAYER), per-actor expiry, account lock |
| Account creation | Not addressed | CREATE2-derived creation with initial_actors, portable across EVM chains |
| Nonce model | Standard nonce field | 2D nonce_key/nonce_sequence, including a nonce-free mode with replay_id dedup via a fixed-capacity replay buffer |
| EIP-7702 relationship | Requires EIP-7702; EXT_SET_CODE makes 7702 delegations scheme-agile | Does not require EIP-7702 (dropped from requires after early drafts); code-less EOAs auto-delegate to DEFAULT_ACCOUNT_ADDRESS instead |
| New-scheme cost | New EIP plus hard fork per scheme, but no envelope change | New authenticator contract plus companion-ERC governance to reach the canonical/allowlisted set; non-canonical authenticators can be deployed permissionlessly but are not usable on the AA validation path |
Activity
- 1 PR: ethereum/EIPs#11438, opened by Giulio2002, merged April 22, 2026. Advanced EIP-8202 from PR-only to a numbered Draft on
master. - 6 EthMagicians posts at ethereum-magicians.org/t/eip-8202-schemed-transaction/28044.
- Key participants: Giulio2002 (author), SirSpudlington (raised duplication concerns against EIP-7932 and EIP-8197), bbjubjub (flagged an EIP-7702 interop gap for new EOAs), shemnon (EIP-8197 author, argued EIP-8202 lacks flexible transaction bodies and signature-substitution protection).
- Separately, in the cross-proposal "Frame Transactions vs. SchemedTransactions" thread (ethereum-magicians.org), Giulio2002 has argued that contract-dispatch validation carries real gas overhead relative to a direct signature check. That specific dispute targets EIP-8141's VERIFY frames, not EIP-8130, but it signals the same skepticism EIP-8202's authors would likely apply to any contract-call-based authentication model, EIP-8130's authenticator dispatch included.
Strengths
- Narrow, shippable PQ path: Falcon-512 is a first-class scheme at merge, not a future extension point. A reader who only wants "PQ signatures on L1" gets there without adopting a new account-abstraction system.
- No contract execution in validation: ecrecover or a precompile call only. Deterministic cost, no allowlist to maintain, no authenticator contracts to audit.
- Stops transaction-type proliferation: blobs, set-code, and signature scheme all stay inside the same
0x05envelope via typed lists rather than minting a new tx type per feature combination. - Existing EOAs keep their address:
SCHEME_SECP256K1reuses legacy address derivation, so migration is optional rather than forced.
Weaknesses
- No account-abstraction feature set: no actors, no scopes, no call policies, no portable account creation. A reader wanting what EIP-8130 offers (session keys, sponsor-only keys, delegate authenticators, account lock) gets none of it from EIP-8202 alone.
- No gas sponsorship yet:
ROLE_PAYERis reserved but undefined, versus EIP-8130's fully specifiedSELF_PAYER/SPONSOR_PAYERmodel. - New schemes require a hard fork: EIP-8130's companion-ERC authenticator registry can add a scheme without touching consensus rules for the base transaction type; EIP-8202 cannot.
- Scheme-agility overlap: community feedback (SirSpudlington) notes functional overlap with EIP-7932 (crypto-agility registry) and EIP-8197 (CATX), a fragmentation risk shared by any scheme-agility proposal, EIP-8130's authenticator set included.
- Early stage: one merged PR and 6 discussion posts. Merged to
masterApril 22, 2026, but with limited review depth relative to EIP-8130's PR history.
Continue with Competing Standards for the comparative analysis, or return to the Home page.