EIP-8130 Account Configuration

Appearance

EIP-8175: Composable Transaction ​

AuthorDragan Rakita (@rakita)
Status/CategoryDraft, Core (Standards Track)
CreatedFebruary 26, 2026
RequiresEIP-2, EIP-1559, EIP-2718
Latest spechttps://github.com/ethereum/EIPs/blob/master/EIPS/eip-8175.md

Proposal status

EIP-8175 is a Draft, not an active Ethereum transaction type.

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 fixes sender signature schemes in the protocol and lets an EVM prelude decide sponsorship. EIP-8130 reserves native k1 and routes other direct authentication through canonical contracts. That makes EIP-8175 the useful "protocol schemes plus one designated sponsor contract" comparison.

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 fixed authenticator interface and EIP-8141's general VERIFY frames. EIP-8175 executes EVM code only when sponsorship is requested. EIP-8130 can execute a canonical authenticator contract for either sender or payer, so its interface is narrower but its contract-authentication path is not EVM-free.

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 changing and activating the protocol definitionA contract can be deployed freely, but direct AA authentication requires canonical-set adoption; the draft does not define that activation process
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 mergedNo PQ authenticator currently defined; a future one would need canonical-set adoption

Activity ​

EIP-8175 has three merged spec PRs (#11355, #11490, #11501) and one open draft PR (#11431, Falcon-512) as of August 20, 2026. The original PR merged March 10.

Discussion is split across the EIP's EthMagicians thread and a cross-proposal post-quantum comparison thread. The latter debated the cost of frame-based Falcon verification against an earlier EIP-8202 draft that still contained Falcon. Because Falcon was removed before EIP-8202 merged, those figures are historical design feedback, not a current spec-to-spec gas comparison.

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 protocol-spec change and activation to add a signature_type; EIP-8130 moves that decision to canonical-authenticator-set coordination instead.
  • 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 introduces EVM simulation into the sponsored path. EIP-8130 narrows that path to a canonical authenticator call, but does not eliminate EVM execution when the authenticator is a contract.

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