EIP-8202: Scheme-Agile Transactions (Schemed Transactions)

---

Authors: Giulio Rebuffo (@Giulio2002), Ben Adams (@benaadams) Status: Draft | Category: Core (Standards Track) Created: March 22, 2026 Requires: EIP-1559, EIP-2718, EIP-2780, EIP-4844, EIP-7702, EIP-7976

At a Glance

What it is. A scheme-agile transaction type with a single execution payload, a typed authorization list (secp256k1, P256, Falcon-512 at launch), and a typed extensions list (blobs, set-code).

Problem it solves. Gets post-quantum signatures and passkeys onto L1 as a transaction-layer primitive, without account abstraction, without EVM in validation, and without competing for the general-AA design space. New signature schemes are added by registering a new scheme_id, with no envelope changes.

Why an EIP-8141 reader should care. EIP-8202 is the narrowest bet on this page: it solves only "PQ signatures on L1" and nothing else. If you believe general-purpose AA is too broad and a focused scheme-agile envelope will ship faster, EIP-8202 is the argument for that position.

Overview

EIP-8202 introduces a new EIP-2718 transaction type (0x05) called SchemedTransaction. Instead of adding new top-level transaction types for every feature combination, it defines a single canonical envelope with one EIP-1559 fee header, one execution payload, and two typed attachment lists: authorizations (scheme-agile sender proofs) and extensions (flat typed protocol features like blobs and set-code).

The core thesis is the opposite of EIP-8141's frame model: flat composition, not recursive composition. One execution payload, many orthogonal capabilities, no new opcodes, no frame modes, no nested execution.

Core Design

Single Execution Payload: Every transaction has exactly one (to, value, data) call/create. There are no frames, no multiple execution contexts, no mode flags.

Authorization System: The authorizations list contains typed [role_id, scheme_id, witness] tuples. Currently only ROLE_SENDER is defined. Each scheme registers a witness format, verification logic, address derivation, and gas surcharge. New signature schemes are added by registering a new scheme_id, with no envelope changes needed.

Three Initial Schemes (updated from original two-scheme design):

• SCHEME_SECP256K1 (0x00): Standard ECDSA. Same address derivation as legacy Ethereum, so existing EOAs can use the new tx format without address change.
• SCHEME_P256 (0x01): P256/secp256r1 for passkey/WebAuthn support. Requires EIP-7951 (P256 precompile).
• SCHEME_FALCON512 (0x02): Falcon-512 post-quantum signatures. First native PQ scheme defined at the transaction layer.

The original design included an ephemeral secp256k1 scheme (Merkle-committed one-time keys for PQ safety via Keccak-256 preimage resistance). The current PR description lists P256 and Falcon-512 as the second and third schemes, indicating a shift from the hash-based PQ approach toward direct PQ cryptography.

Extension System: The extensions list contains typed [extension_id, extension_payload] entries, unique by ID. Two initial extensions:

• EXT_BLOB (0x01): Carries EIP-4844 blob fields (max_fee_per_blob_gas, blob_versioned_hashes)
• EXT_SET_CODE (0x02): Carries EIP-7702 set-code authorizations, but with (scheme_id, witness) replacing (y_parity, r, s), making delegation itself scheme-agile

Transaction 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: Deliberately omitted; transaction-level access lists are being deprecated (EIP-7928 block-level, EIP-7981 cost increase).

Composability Without New Types:

• Plain secp256k1 tx = base + sender auth(k1)
• Quantum-safe tx = base + sender auth(ephemeral k1)
• Blob tx = base + sender auth(...) + blob extension
• Set-code tx = base + sender auth(...) + set-code extension
• All three combined = base + sender auth(ephemeral k1) + blob ext + set-code ext

Mempool Strategy

EIP-8202's mempool model is close to today's transaction processing:

• secp256k1: Identical to current: ecrecover the sender, check nonce and balance. No EVM execution.
• P256: P256VERIFY precompile call. Deterministic cost.
• Falcon-512: Falcon signature verification. Deterministic cost.

Because there are no frames and no arbitrary EVM validation, the mempool doesn't need banned opcode lists, validation gas caps, or prefix simulation. Validation is purely cryptographic.

The spec explicitly notes: "This EIP allows multiple orthogonal capabilities, but only one execution payload. It intentionally forbids recursive transaction composition. That avoids drifting into frame-transaction validation complexity."

Key Differences from EIP-8141

Aspect	EIP-8202	EIP-8141
Composition model	Flat: one execution payload + typed extensions	Recursive: multiple frames with modes
New opcodes	None	5 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM)
Tx type	0x05	0x06
Signature agility	scheme_id in authorization — scheme as a capability	Account code calls APPROVE — scheme as EVM logic
PQ strategy	Falcon-512 native (scheme_id 0x02), P256 for passkeys (scheme_id 0x01)	Arbitrary sig schemes in VERIFY frames
Validation model	Cryptographic only — no EVM during validation	Programmable EVM in VERIFY frames
Mempool complexity	Minimal: ecrecover + Merkle proof, deterministic cost	High: validation prefix, banned opcodes, gas caps
Atomic batching	Not supported (single execution payload)	Flags field bit 2 on consecutive SENDER frames
Gas sponsorship	ROLE_PAYER reserved but not yet defined	VERIFY frame for sponsor, canonical paymaster
EIP-7702 integration	EXT_SET_CODE extension (scheme-agile delegations)	No authorization list (PQ incompatible)
EIP-4844 integration	EXT_BLOB extension	Not addressed
Extensibility	New scheme_id or extension_id per EIP	Arbitrary within frame architecture
Async execution	Compatible (no EVM in validation)	Incompatible with async models
Account creation	Not addressed	DEFAULT frame to deployer contract
Future frame support	Explicitly noted as possible extension	Native

Activity

• 1 PR (ethereum/EIPs#11438), opened by Giulio2002, merged Apr 22, 2026. EIP-8202 now lives on master as a Draft.
• 6 EthMagicians posts at ethereum-magicians.org/t/eip-8202-schemed-transaction/28044
• Key participants: Giulio2002 (author), SirSpudlington (raised duplication concerns with EIP-7932/8197), bbjubjub (noted EIP-7702 interop gap for new EOAs), shemnon (EIP-8197 author, argued EIP-8202 lacks flexible tx bodies and signature substitution protection)
• Recent: The final merged spec lists three initial schemes (secp256k1, P256, Falcon-512) instead of the original two (secp256k1, ephemeral secp256k1), plus EIP-7951 in the requires list. Merging advances EIP-8202 from PR-only to a numbered Draft on master, the same status EIP-8141 holds.

Strengths

• Stops tx type proliferation: one envelope composes features (blobs + set-code + sig scheme all stay 0x05) instead of minting a new tx type per combination.
• Direct PQ path: Falcon-512 native at the transaction layer. P256 for passkeys. New schemes added as scheme_id values without envelope changes.
• Minimal mempool disruption: purely cryptographic validation. Deterministic cost, no EVM, async-compatible. Existing secp256k1 EOAs keep their address.
• Scheme-agile EIP-7702 upgrade: set-code authorizations become scheme-agile, so delegations can use non-ECDSA schemes.

Weaknesses

• No programmable validation or batching: fixed cryptographic check only. Complex policies (time-based, state-dependent, social recovery) cannot be expressed. Batching requires multicall wrappers.
• No gas sponsorship yet: ROLE_PAYER is reserved but undefined.
• Scheme-agility overlap: community feedback notes functional overlap with EIP-7932 (crypto agility registry) and EIP-8197 (CATX). Risk of fragmentation across multiple scheme-agility proposals.
• Early stage: 6 discussion posts and a Draft spec. Merged to master Apr 22 but still one PR deep on substantive feedback.

---

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