EIP-8202: Scheme-Agile Transactions
| Authors | Giulio Rebuffo (@Giulio2002), Ben Adams (@benaadams) |
| Status | Draft, Core, Standards Track |
| Created | March 22, 2026 |
| Requires | EIP-2, EIP-155, EIP-1559, EIP-2718, EIP-2780, EIP-4844, EIP-7702, EIP-7976 |
| Canonical spec | EIPS/eip-8202.md |
Draft proposal
EIP-8202 is merged into the EIPs repository as a Draft. It is not an activated Ethereum transaction type. “Current” below means current proposal text.
At a Glance
What it is. A proposed EIP-2718 transaction type (0x05) with one execution payload, a typed authorizations list for sender schemes, and a typed extensions list for blobs and set-code authorizations.
What its current scheme set is. Two entries: ordinary secp256k1 and SCHEME_EPHEMERAL_K1, which commits a sequence of single-use secp256k1 public keys in a Merkle tree.
Why an EIP-8130 reader should care. Both proposals separate the transaction envelope from a particular signature encoding. EIP-8202 registers schemes directly in consensus and performs no authenticator contract call. EIP-8130 resolves an account actor through a canonical authenticator contract and adds a much broader account model: scopes, policy managers, sponsorship, account creation, and portable actor changes.
Overview
The envelope is flat:
0x05 || rlp([
chain_id, nonce,
max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
to, value, data,
authorizations, extensions
])Exactly one ROLE_SENDER authorization is required. ROLE_PAYER is reserved and forbidden in this version, so the draft has no gas-sponsorship mechanism. Unknown role, scheme, and extension IDs are invalid rather than ignored.
The proposal intentionally has one call-or-create payload. It does not define frames, batching, actors, account policies, or a new wallet account model.
Current Signature Schemes
| ID | Name | Address and witness model |
|---|---|---|
0x00 | SCHEME_SECP256K1 | Standard ECDSA; preserves legacy keccak256(pubkey)[12:] address derivation |
0x01 | SCHEME_EPHEMERAL_K1 | Address is `keccak256(0x01 |
Ephemeral secp256k1
The user derives 2^20 secp256k1 keys and commits their public-key hashes in a depth-20 Merkle tree. Transaction nonce i must use leaf i. The witness contains:
- the 32-byte Merkle root;
- a 65-byte recoverable ECDSA signature; and
- a 640-byte Merkle proof.
The public key is recovered from the signature rather than encoded separately, giving the draft's 737-byte total. Under its EIP-7976 uniform calldata floor, the draft calculates 43,008 gas more calldata than a 65-byte ECDSA witness, plus a 5,000-gas scheme surcharge.
The proposal calls this quantum-safe because a private key recovered after use is invalid at the next nonce, while deriving the unrevealed next public key from its Merkle leaf requires a Keccak-256 preimage attack. Its Security Considerations still identifies a mempool race: an attacker capable of breaking ECDSA within a block time could steal the currently pending nonce.
What happened to P-256 and Falcon-512?
They are not in the current draft. PR #11438's original description advertised P-256 and Falcon-512, and both appeared during the PR's 27-commit development history. The final merged version removed them and retained only secp256k1 plus ephemeral secp256k1. P-256 and Falcon-512 now appear as examples of future schemes.
New values range from 0x00 to 0xFF, but the draft requires every new scheme_id to be specified by a distinct EIP. The envelope stays stable; consensus verification and client activation still change.
Extensions
| ID | Extension | Purpose |
|---|---|---|
0x01 | EXT_BLOB | Carries EIP-4844 blob fields |
0x02 | EXT_SET_CODE | Carries EIP-7702-style authorizations using (scheme_id, witness) instead of hardcoded ECDSA fields |
The set-code extension makes each authorization scheme-agile and includes scheme_id in its signed message. Set-code effects retain EIP-7702's non-rollback behavior.
Validation and Mempool Shape
The current schemes use deterministic cryptographic work rather than contract execution:
- secp256k1 uses standard recovery and a zero scheme surcharge;
- ephemeral k1 uses recovery plus 20 Keccak-256 Merkle steps and its witness surcharge;
- nonce and balance checks otherwise resemble ordinary transaction processing.
This gives a smaller validation call graph than EIP-8130's contract-authenticator path. It also gives up account-level extensibility: a new algorithm needs a new scheme definition and client implementation instead of a deployable contract.
Key Differences from EIP-8130
| Aspect | EIP-8202 | EIP-8130 |
|---|---|---|
| Formal status | Draft, not activated | Draft, not activated |
| Transaction type | 0x05 | 0x79; 0x7A is payer-signature domain separation |
| Authentication | Protocol scheme_id dispatch | Canonical IAuthenticator selected by address, with native k1 special case |
| Current non-classical path | Single-use Merkle-committed secp256k1 keys | No PQ authenticator in the canonical set |
| New scheme | Distinct EIP plus client implementation | Deploy freely; direct AA use requires canonical-set specification and client adoption |
| EVM during authentication | None for the two current schemes | STATICCALL for contract authenticators unless enshrined; native k1 |
| Execution | One call or create | Multi-phase calls plus typed account changes |
| Sponsorship | None; ROLE_PAYER reserved | Native payer fields and payer scope grants |
| Account model | None | Actors, scopes, policy managers, expiry, Account Lock |
| Nonces | Standard account nonce | Two-dimensional and nonce-free modes |
| Cross-chain account config | Not defined | Deterministic creation plus replayable multichain actor changes |
Activity
The proposal entered master through PR #11438, merged April 22, 2026. The final file has had no later commits as of August 20. The large difference between the PR's initial description and its final content is why checking only the PR summary produces the incorrect “P-256 and Falcon shipped” account that previously appeared on this site.
Strengths and Risks
Strengths
- Flat validation with no authenticator or wallet contract execution.
- Legacy secp256k1 addresses continue to work under the new envelope.
- Scheme and extension IDs avoid a new outer type for every feature combination.
- Ephemeral k1 gives the draft a concrete migration design without introducing a new signature primitive.
Risks and limitations
- A 737-byte witness and Merkle verification add substantial per-transaction overhead.
- The design creates a new address and has a finite
2^20-transaction key tree. - Its quantum-safety argument depends on single-use discipline, Keccak preimage resistance, and the attacker not breaking ECDSA within the mempool window.
- No batching, sponsorship, session-key scope, or portable account configuration is defined.
- New schemes still require consensus specification and client activation.
Continue with Competing Standards, or return to the Home page.