Rather than introducing new opcodes, account abstractions, or execution frame models, SchemedTransaction is a single new transaction type that reuses the existing EIP-1559 fields with only two changes: the legacy v, r, s fields are replaced by scheme_id and signature_data.
Execution frame–based approaches (e.g., composable transaction types) can be layered on top of SchemedTransaction later if needed. However, frame-based designs have unresolved issues around mempool validation — verifying nested frames before inclusion is expensive and introduces new DoS vectors. SchemedTransaction sidesteps these problems entirely: signature verification is a single, cheap, stateless check at the transaction envelope level, exactly like today’s ECDSA. This gives Ethereum immediate quantum resistance and native WebAuthn/passkey support without waiting for the frame model to mature.
4 Likes
Since we are introducing “new” EOAs, we should consider the interaction with EIP-7702: if I derive an address from my Falcon or P256 public key, I might want to delegate it to an EIP-7702 wallet later on. In the current state of the proposal I cannot do that. We could add an authorizations field to the new tx type that contains authorizations signed using a variant of the new scheme.
@SirSpudlington pointed to my EIP, EIP-8197, which does handle all TX types except for type 0, and has flexibility to add future tx bodies independent of the signature.
While directionally correct I feel schemed transactions don’t go quite far enough for a durable solution to this problem. Flexible transaciton bodies and structural protection against signature substitution attacks are what I think are needed, which CATX provides.
I have been following this proposal with some interest and at this point, you have re-invented EIP-7932.
Case in point:
scheme_id → ALG_TYPE- opaque
witness → opaque signature
verify_or_recover → verify + validate- “New values MUST be specified by a distinct EIP.” → “New algorithms … MUST be specified via a distinct EIP.”
As 7932 is specifically designed for handling signatures and there is a functionally identical version in EIP-8202, it would make sense to strip out the signature handling logic and use the helper functions in 7932. Embedding a custom version like this defeats the whole point of the 7932 registry (a standard that other EIPs build off of).
Adopting the registry can be done with quite literally minimal changes e.g. adding a check that Algorithm.size == len(signature), etc.