Where the Proposal’s Case Against 8141 Is Weak
1. The Gas Comparison Is Rigged by Choosing the Worst AA Path
The proposal compares SchemedTransactions against “smart wallet overhead” of 30,000–48,000 gas, but this is the overhead of a *generic* ERC-4337 UserOperation going through the EntryPoint contract with full bundler infrastructure. That’s not the right comparison for EIP-8141 Frame Transactions.
EIP-8141 Frame Transactions are a **native transaction type with a validation frame** — they’re not ERC-4337 UserOps. The validation frame executes in a constrained context (no state changes permitted, limited opcodes) and is closer in spirit to how clients handle intrinsic validation today than to arbitrary contract dispatch. The proposal lumps “Frame Transactions” and “ERC-4337 + smart wallet” together as if they’re equivalent overhead. They’re not. The 30,000–48,000 gas “smart wallet tax” figure is substantially inflated when applied to a natively-validated Frame Transaction, and the proposal never really justifies applying that overhead number to 8141 specifically.
2. The “Abstraction Is Illusory” Argument Proves Too Much
The proposal argues that Frame Transactions don’t deliver crypto-agility because every real scheme still needs a precompile, so the frame just becomes an indirection over precompiles that were necessary anyway. But this cuts both ways:
SchemedTransactions also need a precompile (or equivalent native client code) per scheme. When scheme_id `0x02` for Falcon-512 needs to be implemented, client teams across Geth, Nethermind, Besu, Erigon, and Reth all have to implement Falcon verification natively. That’s the same coordination cost as adding a precompile arguably harder, because it’s embedded in core transaction validation logic rather than a discrete, testable, independently-deployable module.
The actual difference is *where* the per-scheme work lands: precompile (8141 path) vs. hardcoded client dispatch (SchemedTransaction path). Neither avoids per-scheme implementation work. 8141 arguably has better separation of concerns.
3. “Ships Faster” Is Asserted, Not Demonstrated
The proposal claims SchemedTransactions ship faster because they introduce less complexity. But the ACD delay cited in March 2026 for EIP-8141 was specifically about **mempool rules** and those mempool rules are a solvable engineering problem that client teams are actively working on. SchemedTransactions aren’t actually in a client release either. The “faster to ship” claim is comparing a known hard problem (mempool tracing rules for 8141) against an assumed-easy problem (native scheme dispatch for SchemedTransactions), without evidence that the latter is actually simpler to get through ACD and into a fork.
4. The DoS / Mempool Argument Is Overstated for 8141
The proposal raises mempool DoS as a major concern for Frame Transactions: arbitrary EVM validation means nodes must trace transactions before knowing if they’s safe to propagate. This is real but it’s also **the exact problem EIP-7702 and ERC-4337 already solved in practice**. The mempool rules for constrained validation frames (no SLOAD of arbitrary slots, no calls to untrusted contracts, bounded gas) are well-understood from the 4337 mempool spec. 8141 frames are more constrained than full UserOps. The DoS surface is smaller than the proposal implies, and the solutions are known.
Where 8141 Is Genuinely Better
1. Composability and Forward Compatibility
SchemedTransactions hardcode the relationship between signature scheme and transaction type. When SL-DSA-87 (a higher security level Dilithium variant) becomes desirable in 2028, or when a new NIST round produces a better PQ scheme, SchemedTransactions require a new scheme_id and a new hard fork to register it. The community has to coordinate on `scheme_id = 0x03`, `scheme_id = 0x04`, etc.
With 8141, new signature schemes are deployable by adding a precompile and updating the VERIFY frame, the transaction format itself doesn’t change. The composability with blob transactions, delegate transactions, and future payload types (as LukaszRozmej noted) is also real: 8141 can cleanly separate “what authorization scheme” from “what transaction payload”, whereas SchemedTransactions have to define a new intersection for every (scheme × payload type) combination.
The EIP-7932 standardized registry approach (mentioned by @SirSpudlington in the thread) makes this even stronger.
2. Programmable Validation Enables Real Use Cases SchemedTransactions Can’t Touch
The proposal dismisses this by saying EIP-7702 already covers the practical AA use cases. But there are meaningful cases where programmable validation at the transaction level matters and 7702 doesn’t fully solve:
- **Threshold and multi-party signatures**: A k-of-n Falcon multisig is a VERIFY frame; with SchemedTransactions you’d need a smart wallet and pay the overhead anyway
- **Hybrid classical + PQ schemes**: During the transition period, requiring both an ECDSA *and* a Falcon signature on high-value transactions (defense in depth against both classical and quantum adversaries) is trivially expressible in a VERIFY frame; SchemedTransactions have no mechanism for this
- **Scheme migration flows**: Accounts that need to transition from one PQ scheme to another without losing funds require some programmable logic, a VERIFY frame can express “accept either scheme A or scheme B during the migration window”; SchemedTransactions can’t
These aren’t exotic edge cases. Hybrid classical/PQ is actually the NIST-recommended transition approach. SchemedTransactions have no answer for it.
3. The ORIGIN Semantics Change Is a Minor Concern, Not a Fatal One
The proposal raises `ORIGIN` opcode semantic changes as a complexity risk. This is real but it’s a well-understood migration path. The number of contracts in production that rely on `ORIGIN == CALLER` as a security check is small and shrinking (it’s been a known anti-pattern for years). This is not a principled architectural objection, it’s an implementation detail with a clear migration path.