Title: EIP-7702: staged type-0x04 parser is unreachable; authorization signing has no flow

[michwill]

The ethUstream parser gained a complete EIP-7702 state machine in c7da454
("add EIP-7702 style tx signing", May 2025) — processEIP7702Tx with all
fields including EIP7702_RLP_AUTH_LIST, and EIP7702 = 0x04 in the
txType_e enum. But that commit only touched app/ethereum/ethUstream.c/h,
and the single dispatch gate in app/core/core_eth.c::core_eth_process_tx
still admits only 2930/1559:

if (txType >= MIN_TX_TYPE && txType <= MAX_TX_TYPE) {
  // Enumerate through all supported txTypes here...
  if (txType == EIP2930 || txType == EIP1559) {
    keccak_Update(&g_core.hash_ctx, data, 1);
    g_core.data.eth_tx.ctx.txType = txType;
    ...
  } else {
    return ERR_UNSUPPORTED;   // <- type 0x04 lands here
  }
}

Both entry points (EIP-4527 QR eth-typed-transaction and USB
INS_SIGN_ETH_TX) funnel through this function, so as of v1.3.0 a type-4
transaction is rejected and processEIP7702Tx is dead code.

Three pieces seem to be missing for end-to-end 7702 support:

1. Wire the gate — accept txType == EIP7702 alongside 2930/1559 (same
   type-byte keccak_Update treatment). Looks like a one-liner given the
   parser is already there.

2. Display the authorization list — currently processAuthList just
   forwards to processAccessList, so the tuples are hashed into the digest
   but never stored in txContent_t/shown by ui_display_eth_tx. The
   delegate address is the security-critical field of a 7702 tx (it gets full
   control of the account), so it deserves first-class display — at minimum
   the address of each tuple, ideally chain id + nonce too.

3. Authorization-tuple signing — for an account on the Shell to delegate
   itself, the device must also sign
   keccak(0x05 || rlp([chain_id, address, nonce])) with the account key
   (for a self-sent type-4, nonce = tx nonce + 1). There's currently no way
   to request that signature: eth-raw-bytes (data-type 3) is always
   EIP-191-prefixed in core_eth_process_msg, and the UR CDDL has no
   raw-hash/authorization data type — so a Shell-held account cannot produce
   a 7702 authorization at all, via any wallet. This needs a protocol
   extension, e.g. a new sign-data-type carrying the authorization tuple
   (chain id, delegate address, nonce) so the device can render "Delegate
   account to 0x… on chain N" and sign the 0x05-domain digest. FWIW the
   same gap exists ecosystem-wide (Keystone's firmware has nothing yet;
   Add signHash for raw secp256k1 signing (needed for EIP-7702) open-wallet-standard/core#155 tracks the API-level equivalent), so
   whatever you design here would effectively be the reference.

[bitgamma]

the EIP-7702 implementation is a stub since the ERC4527 spec doesn't define a way to sign the authorization lists yet.

[michwill]

Ahhh I can see that. So there's just no agreement on how to transmit/sign type 4 transaction via QR codes?