Ethereum Pectra EIP-7702 EOA Sweeper Delegations & Chain-ID Zero Replay Analysis

Executive Summary: When Externally Owned Accounts Acquire Persistent Bytecode

On May 7, 2025, Ethereum activated the Pectra (Prague-Electra) network upgrade, introducing EIP-7702 (Set EOA Account Code) via EIP-2718 Transaction Type 0x04. Engineered to bridge traditional Externally Owned Accounts (EOAs) into ERC-4337 account abstraction (enabling legitimate transaction batching, passkey verification, and gas sponsorship without migrating addresses), EIP-7702 altered a ten-year invariant of the Ethereum Virtual Machine: EXTCODESIZE on an EOA is no longer guaranteed to be zero, and an EOA can delegate complete execution authority over its own msg.sender identity via a single off-chain secp256k1 signature.

Within seventy-two hours of mainnet activation, Crime-as-a-Service (CaaS) drainer syndicates led by Inferno Drainer, Pink successors, and automated mempool sweeper operators deployed standardized malicious delegation targets across Ethereum, BNB Smart Chain, Base, and Arbitrum. Empirical chain telemetry collected across the first six months post-Pectra revealed that over 85% of all mainnet EIP-7702 authorizations pointed to automated sweeper or drainer contracts, accounting for more than $85 million in cumulative retail and whale portfolio losses (DT-INC-2025-002).

Byte-Level Mechanics of Type 0x04 & MAGIC (0x05) Authorization Tuples

Unlike a standard transaction (which must be funded with ETH gas and broadcast by the signer), EIP-7702 separates authorization signing (performed off-chain by the victim authority key) from transaction execution and gas payment (performed on-chain by any third-party relayer or drainer bot!).

An EIP-7702 authorization tuple contains four fields: [chain_id, address, nonce, y_parity, r, s]. The victim signs the keccak256 digest of a single-byte domain-separation prefix (MAGIC = 0x05) concatenated with the RLP-encoded target tuple:

authorization_digest = keccak256(0x05 || rlp([chain_id, delegation_contract_address, account_nonce]))

When the drainer's relayer bot bundles this signed tuple inside authorization_list of a Type 0x04 transaction and pays the L1/L2 gas fee:

1. The EVM recovers the authority EOA address via ecrecover(authorization_digest, y_parity, r, s).
2. The EVM verifies chain_id == 0 || chain_id == block.chainid and checks that nonce matches the victim EOA's current transaction nonce, incrementing the victim's nonce by 1.
3. The EVM writes a 23-byte Delegation Designator directly into the victim EOA's code field (using the 0xef prefix reserved under EIP-3541 so normal CREATE deployments can never forge it):

   EOA.code = 0xef0100 || <20-byte delegation_contract_address>
   

4. From that microsecond forward, every call directed at the victim's EOA executes the bytecode of delegation_contract_address via DELEGATECALL-equivalent semantics where address(this) and msg.sender on outbound sub-calls equal the victim's own EOA!

Four Adversarial Attack Vectors Observed in DT-INC-2025-002

1. Atomic Multi-Asset Portfolio Drain (Inferno Batch Sweeper): Before Pectra, an ERC-20 phishing page had to prompt the victim for separate Permit signatures per token (or rely on prior Permit2 infinite allowances) and still could not touch native ETH without persuading the user to broadcast a value-bearing transaction. With EIP-7702, the relayer attaches Inferno's batch sweeper contract to the victim's EOA and invokes execute(Call[]) in the exact same transaction, transferring native ETH, USDC, USDT, WBTC, stETH, and staked LP receipts simultaneously because msg.sender inside every token contract transfer call is the victim's own EOA!
2. Omnichain chain_id = 0 Replay: Whenever a victim signs an authorization tuple containing chain_id = 0 (most devastating on fresh or low-nonce vaults where nonce = 0 across multiple L2s), drainer bots immediately replay the identical (y_parity, r, s) signature on every EIP-7702-enabled EVM chain (Ethereum, Base, Arbitrum, Optimism, BNB Smart Chain, Unichain) where the account's nonce matches.
3. Storage Collision & Uninitialized Smart-Account Upgrade Traps: Several early post-Pectra wallet implementations deployed EIP-7702 smart-account templates whose initialize(address owner) function lacked binding cryptographic commitment to the EOA's own signature, allowing MEV front-runners watching the mempool to sandwich the 0x04 setup transaction and register themselves as the delegated account's passkey guardian.
4. Post-Compromise Persistent Sweeper Lockout (receive() Hook + Nonce Pre-Signing): When an attacker compromises a hot-wallet seed or .env private key, they immediately delegate the EOA to a sweeper contract whose receive() external payable function forwards 100% of incoming msg.value to the attacker, and pre-sign 50 consecutive future authorization tuples (nonce + 1 through nonce + 50) in private Flashbots/builder bundles so manual user revocations are instantaneously overwritten when vesting or staking rewards unlock!

Smart-Contract Broken Invariants & Wallet Firmware Blind Spots

DT-INC-2025-002 exposed critical engineering blind spots across both DeFi Solidity contracts and retail wallet signing interfaces:

1. Collapse of Legacy require(msg.sender == tx.origin) & extcodesize == 0 Guards

For nearly a decade, hundreds of Solidity developers wrote require(msg.sender == tx.origin, "No contracts") or inline assembly if gt(extcodesize(caller()), 0) { revert(0, 0) } under the mistaken belief that enforcing EOA-only callers prevented atomic flash-loan or multi-call manipulation. Under EIP-7702:

• When a delegated EOA initiates a Type 0x04 or Type 0x02 transaction calling its own delegated batch-execution logic, msg.sender == tx.origin evaluates to true on the top-level sub-calls while executing arbitrary loop/reentrancy contract logic!
• Conversely, naive contracts rejecting callers with extcodesize(msg.sender) > 0 broke legitimate smart-wallet users whose EOAs held the 23-byte 0xef0100... delegation designator. Protocol engineers must replace all tx.origin and extcodesize heuristics with explicit EIP-1153 transient-storage reentrancy locks (TSTORE / TLOAD).

2. Why JSON-RPC eth_sign & Outdated Firmware Facilitated 0x05 Phishing

Because an EIP-7702 authorization digest (keccak256(0x05 || rlp([chain_id, address, nonce]))) is a raw 32-byte elliptic-curve hash lacking the EIP-191 \x19Ethereum Signed Message:\n prefix, well-engineered wallets (Rabby, MetaMask latest builds, Trezor Safe 7, and Ledger updated Ethereum apps) strictly prohibit external dApps from requesting wallet_signAuthorization via standard window.ethereum provider APIs, restricting account-delegation upgrades exclusively to internal wallet settings menus against a hardcoded allowlist of audited smart-account implementations (Safe, Kernel, Ambire, MetaMask Delegator).

How, then, did Inferno Drainer capture $85M+ in post-Pectra delegations?

1. Unpatched Wallet Forks & Mobile In-App Browsers: Regional mobile wallets and older desktop extension builds still exposed permissive raw-hash signing (eth_sign) or custom RPC methods without filtering prefix byte 0x05, allowing phishing pages to request an EIP-7702 tuple disguised as a "Gasless Security Verification."
2. Malicious Browser Extensions & Clipboard/Seed Infostealers: Attackers harvesting hot-wallet vaults (Lumma, BeaverTail) immediately converted stolen keys into persistent 0xef0100 sweepers across 10+ chains via chain_id = 0 to automate extraction of illiquid staked positions (Pendle PTs, EigenLayer restaked withdrawals, and vested token airdrops) the exact block cooldowns expired.
3. Developer .env & Foundry Script Mishaps: Engineers testing vm.signDelegation on mainnet forks with real funded deployment keys inadvertently committed or broadcast wildcard chain_id = 0 tuples against unverified test contracts lacking msg.sender == address(this) access modifiers!

3. Storage Dirtying Risks Across Delegation Upgrades (ERC-7201 Namespaced Storage)

Even when delegating an EOA to a legitimate smart-account contract and later switching to a different wallet vendor's EIP-7702 contract, the EOA's underlying persistent storage trie is never wiped when EOA.code changes! If Wallet Vendor A stores uint256 guardianThreshold at storage slot 0 and Wallet Vendor B stores address sessionKeyOwner at storage slot 0, re-delegating without ERC-7201 (Namespaced Storage Layout) causes catastrophic cross-implementation storage-slot collisions analogous to Bybit's proxy slot 0 overwrite. Never delegate an EOA to any contract that fails to enforce ERC-7201 hashed storage namespaces and explicit cryptographic re-initialization nonces.

Evolution of EVM Wallet Drainer Primitives (2020 - 2026)

Forensic Inspection & Safe Emergency Revocation Procedure

If you suspect an EOA has signed a suspicious post-Pectra message or exhibits unauthorized sweeps, do NOT send ETH to that EOA to pay gas! Follow this deterministic four-step containment protocol:

1. Inspect EOA Code Designator via Local/Trusted RPC:

   cast code 0xYOUR_EOA_ADDRESS --rpc-url https://ethereum-rpc.publicnode.com
   # Healthy standard EOA returns: 0x
   # Compromised EIP-7702 EOA returns 23 bytes: 0xef0100<20-byte-sweeper-address>
   

   Repeat this check across Ethereum, Base, Arbitrum, Optimism, and BNB Smart Chain.
2. Determine Whether the Private Key Itself Is Compromised: If you never leaked your seed phrase or private key (meaning you only signed a phishing prompt on a hardware wallet or Rabby), revoking the delegation restores clean EOA custody. If your .env or hot-wallet seed leaked, the attacker can re-sign new 0x05 tuples indefinitely; treat the address as permanently burned and request protocol teams migrate unvested claims if supported.
3. Execute Sponsored Zero-Address Delegation Revocation (address(0)): Per the EIP-7702 specification, signing a new authorization tuple whose target address equals 0x0000000000000000000000000000000000000000 clears the EOA's 0xef0100... code pointer back to empty 0x! Construct the address(0) revocation tuple offline using Foundry (cast wallet sign-auth 0x0000000000000000000000000000000000000000) at the infected EOA's current nonce, then submit and pay gas for the Type 0x04 transaction (cast send --auth <signed_hex>) from a completely separate, clean gas-payer EOA via a private builder RPC (https://rpc.flashbots.net) so mempool sweeper bots cannot front-run your nonce!
4. Bundle Claim + Sweep + Revocation Atomically for Compromised Vesting Keys: In the worst-case scenario where your raw private key was stolen and awaits an upcoming token unlock, submit an atomic multi-transaction private Flashbots / Titan Builder bundle where Transaction 1 (paid by Sponsor EOA) overwrites EOA.code to 0x0000...0000 (or your own rescue contract) and claims/transfers the unlocked tokens to a fresh hardware cold wallet within the exact same block index (block.number), denying public mempool visibility to the attacker's sweeper daemon.

Wallet Architecture & dApp Integration Hardening Checklist

Both wallet developers and smart-contract engineers building on post-Pectra EVM networks must enforce explicit protocol boundaries to neutralize DT-INC-2025-002 attack classes:

1. Block External 0x05 Signing Over window.ethereum (EIP-1193): Browser and mobile wallets must never expose arbitrary MAGIC (0x05) digest signing or unrestricted eth_sign raw-hash primitives to untrusted web origins. Account-code delegation (SET_CODE) should only be initiated inside privileged wallet chrome UI against audited, reproducibly compiled smart-account contracts (ERC-7579 / Safe / Kernel) verified by bytecode hash.
2. Reject chain_id = 0 Wildcard Authorizations by Default: Hardware wallet Secure Element parsers (Trezor, Keystone, BitBox02, Ledger) must explicitly decode 0x04 authorization lists on-device, render a high-severity warning screen whenever chain_id == 0 appears, and require explicit per-chain (chain_id == 1, 8453, 42161) confirmation unless the user manually unlocks advanced developer settings.
3. Mandate ERC-7201 Namespaced Storage & Cryptographic Initializers: Any smart-account implementation designed as an EIP-7702 delegation target must store state exclusively at ERC-7201 collision-resistant slots (keccak256(abi.encode(uint256(keccak256("namespace")) - 1)) & ~bytes32(uint256(0xff))) and require an EIP-712 domain-bound owner signature inside initialize() so mempool front-runners cannot hijack uninitialized delegations.
4. Audit Existing EOAs Quarterly Across All L2s: Operators migrating legacy hot wallets or developer deployment keys should run automated eth_getCode sweeps across every active EVM chain via private or Tor-routed RPC endpoints to verify zero unexpected 0xef0100 designators remain attached. If an historical developer key ever signed experimental Pectra testnet or mainnet authorization tuples with chain_id = 0, rotate operational treasury balances immediately into a fresh hardware-backed Safe or air-gapped vault rather than relying solely on nonce exhaustion, because future EVM-compatible Layer-2 rollups launching with account nonce zero can still replay archived wildcard signatures years after initial signing.