EIP-7702 fundamentally changes EOAs by letting them carry and execute contract code. As a result, all legacy assumptions about EOAs are upended: checks like tx.origin == msg.sender or zero extcodesize no longer imply “true EOA” calls. Contracts that used these patterns for reentrancy or sandwich attack defenses can be bypassed, and token/ETH transfers to EOAs may trigger unexpected code execution. In practice, developers and security auditors must now treat delegated EOAs like contract accounts and remove any hardcoded EOA-only logic. In short, with account abstraction arriving, the Ethereum community must revise old trust assumptions and review smart contracts for these new risks.
Q1: What new capability does EIP-7702 give to an EOA?
A1: It can execute code by delegating to a smart contract.
Q2: After EIP-7702, how does the check require(tx.origin == msg.sender) behave?
A2: It can be bypassed by a delegated EOA (i.e. no longer safe)
Q3: What happens to extcodesize(address) for an EOA that has set delegation code?
A3: It returns >0, since the EOA now has code
Q4: Under EIP-7702, what can happen if you send ETH to a delegated EOA?
A4: It can invoke the delegate’s fallback function, potentially using extra gas or reverting
