EIP-8175: Composable Transaction
Author: Dragan Rakita (@rakita) Status: Draft | Category: Core (Standards Track) Created: February 26, 2026 Requires: EIP-2, EIP-1559, EIP-2718
At a Glance
What it is. A new EIP-2718 transaction type (0x05) called ComposableTransaction that bundles multiple typed capabilities (calls, creates) with a separated signatures list and an optional fee_auth field for programmable gas sponsorship.
Problem it solves. Delivers native batching, gas sponsorship, and alternative-signature support at the transaction level, using flat composition at the envelope. Capabilities are listed alongside the transaction rather than executed through nested frames.
Why an EIP-8141 reader should care. EIP-8175 is the flat-composition counterpoint to frame-based AA. It is worth reading for the design question "do you need frames at all?" and for the fee_auth pattern that evolved in parallel to EIP-8141's canonical paymaster. Its scope has expanded over time, narrowing the complexity gap with EIP-8141.
Overview
EIP-8175 introduces a new EIP-2718 transaction type (0x05) called ComposableTransaction. It defines a flat list of typed capabilities (CALL, CREATE) with a separated signatures list and an optional fee_auth field for programmable gas sponsorship, all composed at the transaction envelope rather than via nested execution.
The spec initially positioned itself as "a simpler alternative to EIP-8141, with no new opcodes, no execution frames, no per-frame gas accounting." It has since evolved to include 4 new opcodes and programmable fee_auth execution, narrowing the complexity gap with EIP-8141 while maintaining the flat composition philosophy.
Core Design
Typed Capabilities: The capabilities field is an RLP list of typed entries. Two types are defined:
CALL (0x01):[cap_type, to, value, data]— message callCREATE (0x02):[cap_type, value, data]— contract creation
Multiple capabilities execute sequentially within one transaction. If any capability reverts, remaining capabilities are skipped.
Separated Signatures: The signatures field contains typed [signature_type, role, ...] tuples. Two signature schemes are defined:
SECP256K1 (0x01): Standard ECDSA(y_parity, r, s)ED25519 (0x02): RFC 8032 pure Ed25519(public_key, signature)— address =keccak256(public_key)[12:]
Each signature has a role: ROLE_SENDER (0x00) or ROLE_PAYER (0x01).
An open PR from Giulio2002 proposes adding Falcon-512 (0x03) as a post-quantum scheme.
Programmable Fee Delegation (fee_auth): When the fee_auth field contains an address, that account sponsors the transaction. The protocol executes a prelude call to the fee_auth contract before capabilities execute. The fee_auth code must use the RETURNETH opcode to credit ETH to a transaction-scoped fee escrow. State changes during fee_auth persist even if the main transaction reverts, enabling sponsors to maintain independent accounting (nonces, rate limits).
Signing Hash: Two-stage domain-separated computation. The signatures array is blinded (emptied) before hashing, then signature_type and role are mixed in. This permits independent signing and prevents cross-scheme/cross-role confusion.
Transaction Envelope:
0x05 || rlp([
chain_id, nonce,
max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
fee_auth, capabilities, signatures
])New Opcodes
| Opcode | Purpose |
|---|---|
RETURNETH | Debits ETH from current address and credits the parent context or fee escrow |
SIG | Loads a signature at index into memory, pushes sig_type to stack |
SIGHASH | Pushes the transaction base_hash to stack |
TX_GAS_LIMIT | Pushes the transaction gas_limit to stack |
These enable fee_auth contracts to introspect signatures and compute escrow amounts on-chain.
Mempool Strategy
Sender authentication is purely cryptographic: ecrecover or Ed25519 verification, no EVM execution. However, the fee_auth prelude does execute EVM code, introducing some mempool simulation complexity (though less than EIP-8141's arbitrary VERIFY frames since fee_auth is a single designated contract).
Key Differences from EIP-8141
| Aspect | EIP-8175 | EIP-8141 |
|---|---|---|
| Composition model | Flat: typed capabilities (CALL, CREATE) | Recursive: frames with modes (VERIFY, SENDER, DEFAULT) |
| New opcodes | 4 (RETURNETH, SIG, SIGHASH, TX_GAS_LIMIT) | 5 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM) |
| Tx type | 0x05 | 0x06 |
| Signature model | Separated signatures list with scheme types | Account code calls APPROVE in VERIFY frames |
| Validation model | Cryptographic sig verification + fee_auth EVM prelude | Programmable EVM in VERIFY frames |
| Gas sponsorship | Programmable fee_auth contract with RETURNETH escrow | VERIFY frame for sponsor, canonical paymaster |
| Fee_auth state persistence | Survives main tx revert | Frame-level: depends on frame mode |
| Mempool complexity | Medium: stateless sig verification, but fee_auth simulation needed | High: validation prefix, banned opcodes, gas caps |
| Atomic batching | Sequential capabilities, break on revert | Flags field bit 2 on consecutive SENDER frames |
| PQ strategy | Ed25519 native, Falcon-512 proposed | Arbitrary sig schemes in VERIFY frames |
| Hybrid classical+PQ | Not natively supported | Trivial: two VERIFY frames with different schemes |
| Programmable validation | No — fixed signature scheme set for sender | Yes — arbitrary EVM logic |
| Async execution | Partially compatible (fee_auth still needs EVM) | Incompatible |
| EOA support | SECP256K1 EOAs work natively; Ed25519 creates new addresses | Protocol-native default code for codeless accounts |
| EIP-7702 integration | Not addressed | No authorization list (PQ incompatible) |
Activity
- 5 PRs (4 merged, 1 open), active iteration from February through April 2026
- 12 EthMagicians posts at ethereum-magicians.org/t/eip-8175-composable-transaction/27850
- 39 posts in the related comparison thread Frame Transactions vs. SchemedTransactions
- Key participants: rakita (author), Giulio2002 (Falcon-512 PR, cross-pollination with EIP-8202), Helkomine, DanielVF
Strengths
- Programmable sponsorship through fee_auth: the prelude call with SIG/SIGHASH/RETURNETH gives sponsors in-EVM signature introspection and independent state (survives main-tx revert).
- Extensible capability model: new features added as new capability types without new tx types.
- Gas efficiency (proponent claim): proponents argue SchemedTransaction-style PQ verification (~29,500 gas for Falcon) is cheaper than smart-wallet dispatch through EIP-8141 (~63,000 gas), per the comparison thread.
Weaknesses
- Rapid scope expansion: the spec went from "no new opcodes, no execution frames" at Feb 26 submission to 4 new opcodes and programmable fee_auth EVM by April 9. The original simplicity pitch has eroded, and the pace of design changes raises maturity concerns.
- No programmable sender validation: sender auth is limited to fixed signature schemes. New schemes require a hard fork. Hybrid classical+PQ signing (NIST-recommended) is not natively supported.
- Existing EOA migration: Ed25519 addresses derive from public keys, producing new addresses. Users must migrate assets.
- Tx type conflict: competes with EIP-8202 for the
0x05tx type number.
Continue with Competing Standards for the comparative analysis, or return to the Home page.