EIP-8130 Account Configuration

Appearance

EIP-8175: Composable Transaction ​

Author: Dragan Rakita (@rakita) Status/Category: Draft, Core (Standards Track) Created: February 26, 2026 Requires: EIP-2, EIP-1559, EIP-2718 Latest spec: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8175.md

At a Glance ​

What it is. A new EIP-2718 transaction type (0x05), ComposableTransaction, that bundles typed "capabilities" (CALL, CREATE) with a separated signatures list and an optional fee_auth field for programmable gas sponsorship, composed flat at the transaction envelope rather than through nested execution contexts.

Problem it solves. It targets the same territory as ERC-4337-successor proposals, general account abstraction and gas sponsorship, while trying to keep the validation surface small: sender authentication stays purely cryptographic (ecrecover or Ed25519), and only the optional sponsor path touches the EVM.

Why an EIP-8130 reader should care. EIP-8175 and EIP-8130 both try to keep AA validation predictable for nodes, but by opposite routes: EIP-8175 fixes the signature schemes in the protocol and lets an EVM prelude decide sponsorship, while EIP-8130 fixes nothing about signature logic in the protocol and instead gates it through a canonical authenticator allowlist. A reader evaluating EIP-8130's authenticator model should treat EIP-8175 as the "no authenticator contracts at all, just fixed schemes plus one designated sponsor contract" alternative.

Overview ​

EIP-8175 was originally pitched as a simpler alternative to EIP-8141's frame-based model, with no new opcodes, no execution frames, and no per-frame gas accounting. It has since grown to four new opcodes and a programmable fee_auth execution path, though it retains its core distinguishing idea: composition happens flatly at the envelope, not through EIP-8141-style nested frames.

The transaction carries a capabilities list (what to execute), a signatures list (who authorizes it, and in what role), and an optional fee_auth address (who sponsors it). Capabilities execute sequentially; if one reverts, the remaining capabilities are skipped rather than the whole transaction failing atomically.

Core Design ​

  • capabilities field: an RLP list of typed entries. CALL (0x01) is [cap_type, to, value, data]; CREATE (0x02) is [cap_type, value, data]. Capabilities run in order; a revert in one capability skips the rest without reverting prior capabilities' state changes.
  • signatures field: typed [signature_type, role, ...] tuples. Two schemes are defined at the protocol level: SECP256K1 (0x01) (standard ECDSA) and ED25519 (0x02) (RFC 8032, with address derived as keccak256(public_key)[12:]). Two roles exist: ROLE_SENDER (0x00) and ROLE_PAYER (0x01). An open PR from Giulio2002 proposes adding Falcon-512 (0x03).
  • fee_auth: when set to an address, that account sponsors the transaction. The protocol executes a "prelude call" to the fee_auth contract before capabilities run; that contract's code uses a new RETURNETH opcode to credit ETH to a transaction-scoped fee escrow. State changes made during the fee_auth prelude persist even if the main transaction later reverts.
  • New opcodes (4 total): RETURNETH (debit/credit ETH between a contract and its parent/escrow), SIG (load a signature at a given index), SIGHASH (push the base transaction hash), TX_GAS_LIMIT (push the transaction's gas limit).
  • Envelope: 0x05 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, fee_auth, capabilities, signatures]).

Mempool Strategy ​

Sender authentication is purely cryptographic, an ecrecover or Ed25519 check, with no EVM execution needed for the sender path itself. The fee_auth prelude does execute EVM code when sponsorship is used, which introduces some mempool simulation complexity, though it is bounded to a single designated contract rather than arbitrary account code. Its mempool complexity therefore sits in the middle: signature checks are stateless, but the fee_auth prelude requires bounded EVM simulation whenever sponsorship is used.

This sits between EIP-8130's allowlist-only model (nodes never execute wallet code, they check authenticator identity against a canonical set) and EIP-8141's arbitrary VERIFY-frame execution (nodes may need to simulate any account code the sender deploys). EIP-8175 only executes EVM code at all when a transaction opts into sponsorship, and even then the executed code is a single contract the transaction names up front.

Key Differences from EIP-8130 ​

AspectEIP-8175EIP-8130
Tx type0x05 (also claimed by EIP-8202, a cited conflict)0x79 (AA_TX_TYPE)
New opcodes4: RETURNETH, SIG, SIGHASH, TX_GAS_LIMIT0 (no EVM changes)
Sender auth modelFixed protocol schemes (SECP256K1, ED25519; Falcon-512 proposed)Authenticator contracts (IAuthenticator), dispatched via STATICCALL or native ecrecover for K1_AUTHENTICATOR, gated by a node-side canonical allowlist
Adding a signature schemeRequires a hard fork to add a new signature_typeRequires only registering a new canonical authenticator via the companion ERC, no hard fork for the tx format itself
Batching / compositionFlat capabilities list, sequential execution, non-atomic across capabilities (a revert skips remaining ones)Two-level calls phases: atomic within a phase, phases commit independently in sequence, completed phases persist through later phase reverts
Gas sponsorshipOptional fee_auth address; protocol runs a prelude call to that contract, which credits ETH via RETURNETHpayer / payer_auth fields; payer resolved via the same actor-config/authenticator system as the sender, requiring SELF_PAYER or SPONSOR_PAYER scope on the payer-side actor
Node validation cost for authecrecover/Ed25519 check for sender; EVM execution of one named contract only if sponsoredOne actor_config SLOAD plus, for non-K1_AUTHENTICATOR actors, a STATICCALL to a canonical authenticator; no wallet-code execution on the accepted path
New EOA addressesEd25519 EOAs derive new addresses; existing secp256k1 EOAs must migrate to use Ed25519No new addresses required; existing secp256k1 EOAs work unchanged via the K1_AUTHENTICATOR sentinel, and non-secp256k1 schemes are added via authenticator registration rather than a new address space
PQ pathNo hybrid classical+PQ signing; a Falcon-512 signature type is proposed but not mergedNew canonical authenticators (e.g. a future PQ authenticator) added via the companion ERC process without changing the transaction envelope

Activity ​

EIP-8175 has 5 total PRs against ethereum/EIPs: 4 merged and 1 open (the Falcon-512 addition from Giulio2002). The original PR, #11355, merged March 10, 2026. Active iteration ran February through April 2026.

Discussion is split across two threads: the EIP's own EthMagicians thread (https://ethereum-magicians.org/t/eip-8175-composable-transaction/27850, 12 posts) and a separate comparison thread, "Frame Transactions vs. SchemedTransactions for Post-Quantum Ethereum" (https://ethereum-magicians.org/t/frame-transactions-vs-schemedtransactions-for-post-quantum-ethereum/28056, 39 posts), where EIP-8175 is discussed alongside EIP-8141 and EIP-8202. In that thread, Giulio2002 claimed EIP-8141's VERIFY-frame PQ verification costs roughly 63,000 gas against roughly 29,500 gas for direct Falcon verification under EIP-8202, attributing the gap to a "smart wallet tax" of 30,000-48,000 gas for contract dispatch, storage, and EVM context; EIP-8141 defenders (ch4r10t33r) countered that the figure conflates ERC-4337 EntryPoint overhead with actual frame overhead. That specific cost dispute does not mention EIP-8130's authenticator-dispatch cost directly, but the same category of question applies to EIP-8130's STATICCALL-to-authenticator path for non-native schemes.

Strengths ​

  • No arbitrary account-code execution is required for the base sender path, keeping node-side validation close to today's cryptographic-only tx checks.
  • Capability composition is simpler to reason about than nested frame execution: a flat, sequential list rather than recursive call contexts.
  • fee_auth sponsorship is scoped to a single named contract per transaction, bounding what a node must simulate when sponsorship is used, in contrast to EIP-8141's arbitrary VERIFY-frame account code.
  • Ed25519 support gives a concrete non-secp256k1 signing path already merged into the spec, not just proposed.

Weaknesses ​

  • The tx-type number 0x05 conflicts with EIP-8202's own claim to 0x05, an unresolved allocation problem between two competing proposals.
  • New signature schemes require a hard fork to add a signature_type, the same rigidity EIP-8130 avoids by routing new schemes through authenticator registration instead of protocol-level type additions.
  • No hybrid classical+PQ signing path is defined, and the proposed Falcon-512 addition remains an open PR rather than merged spec text.
  • Ed25519 adoption requires EOAs to derive and migrate to new addresses, unlike EIP-8130's approach of layering new schemes onto existing account addresses via the authenticator/self-actor system.
  • The fee_auth prelude, while narrower than arbitrary VERIFY-frame execution, still introduces EVM simulation into the sponsored path, a validation-cost category EIP-8130 avoids entirely by keeping payer resolution to an actor_config SLOAD plus (at most) one authenticator STATICCALL.

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