TL;DR - Wallet screening flags an address as a contract or a wallet, but it can't see whether that wallet just delegated its execution to someone else's code under EIP-7702.
You screened the address last week. It came back clean: no sanctions hits, no mixer contact, a normal transaction history. Nothing about that check tells you whether the owner signed away control an hour ago.
What Is EIP-7702, and How Is It Different From an ERC-4337 Smart Account?
Ethereum shipped EIP-7702 as part of the Pectra upgrade, live on mainnet since May 7, 2025. It lets a normal externally owned account, the wallet type behind every seed phrase, temporarily run someone else's contract code without changing its address. The owner signs an authorization naming a target contract, submits one transaction, and the account's code field now points there. The private key still controls it. But every call to that address now executes the delegated contract's logic, instead of doing nothing, which is what a plain EOA normally does with incoming calls.
ERC-4337 solves a related problem differently. Instead of upgrading an EOA, it defines a genuine smart contract wallet, deployed through a factory contract and routed through a shared EntryPoint. More than 40 million of these smart accounts now sit on Ethereum and its rollups, according to Alchemy's account abstraction data. The wallet is a contract from the moment it deploys. The catch: it can hold a real, funded address before it deploys, computed in advance with CREATE2. You can send it money today, and it won't run any code until its first outbound transaction, whenever that happens.
A delegated EOA does flip a bytecode check to "contract." A funded but undeployed ERC-4337 account still reads as an empty, ordinary wallet.
How Did Attackers Turn a Signed Delegation Into a Draining Tool?
The delegation is just a signature, and phishing sites learned to collect it fast. A fake mint page or a fake wallet-drainer removal tool asks a user to "sign to verify" or "sign to fix a stuck approval." The signature is really an EIP-7702 authorization pointing the victim's own address at a sweeper contract. From that point on, any ETH or token that lands in the wallet gets forwarded out automatically, because the sweeper's code runs on every call the address receives, not only the ones the owner initiates.
A December 2025 academic study measured the damage at scale: more than 150,000 EIP-7702 authorization and execution events across roughly 26,000 addresses, tied to real theft of ETH, ERC-20 tokens, and NFTs. Most of the malicious delegations pointed at a handful of near-identical sweeper contracts, copy-pasted between campaigns. One signature is enough to hand over total control, and it stays that way until someone revokes it.
One signature on a phishing prompt is enough to redirect every future deposit; the address and its transaction history never change.
What Does Wallet Screening Actually Check Today?
Most screening tools, this one included, run a simple check first: does the address hold contract bytecode, or not? That single flag decides whether a dashboard shows a wallet icon or a contract icon, on top of the usual sanctions, mixer, and stolen-funds checks covered in what wallet screening actually looks at. It's a cheap, useful signal. It's also close to the entire extent of what most tools tell you about an address's structure.
Anyone can run that same bytecode check for free, calling eth_getCode against a public RPC endpoint or pasting the address into a block explorer. Screen the address with Plastron instead, and you get that same contract flag alongside sanctions, mixer, and stolen-funds exposure across Ethereum and six other chains, in one pass, rather than running several separate lookups by hand.
Why Can't a Standard Screening Check See an Active Delegation?
A 7702 delegation does flip that bytecode flag. Once the authorization lands, eth_getCode on the account returns a 23-byte marker, not the empty string a plain EOA returns, so a contract check does register a difference. What it doesn't do is tell you what the code actually authorizes.
The flag can't decode the delegation designator into a target address, and it doesn't check whether that target is a known drainer, a legitimate smart-wallet implementation, or something in between. Two accounts with an active delegation look identical to a binary check. Their real risk is nowhere close to identical.
The bigger problem is timing. Screening reports a snapshot. Sign a new authorization, and the exact same address you paid safely last month behaves completely differently tomorrow, with no transfer from a flagged counterparty anywhere in its history to force a re-score. The compromise lives in a signature, not a transaction the risk graph would ever flag on its own. It's the same contamination problem described in high-risk smart contract interactions, just arriving through a signed delegation instead of a deposit.
What Should You Check Before Sending Funds to a Smart Wallet?
Treat any address you haven't paid recently as unverified, smart wallet or not, and work through a short list before a transfer that actually matters.
Re-screen the address the same day you send funds, not from memory of an old, clean result.
Check eth_getCode directly when the amount justifies five extra minutes; a non-empty result on an address you know as an EOA is your signal to stop and ask why.
Confirm the payment request through a second channel, since a compromised owner will still answer messages normally.
Send a small test amount first to any wallet you don't fully trust, and wait for confirmation before sending the rest.
For everyday amounts, a fresh screen covers the sanctions, mixer, and stolen-funds side of the risk. For six figures or more, the extra five minutes checking the account's code directly is cheap by comparison.
Does an EIP-7702 delegation change a wallet's address?
No. The address stays exactly the same. Only the code field the EVM reads when something calls that address changes, which is what makes the shift invisible to anyone just skimming a transaction history.
Can a wallet pass a screening check and still be compromised an hour later?
Yes. Screening reports what the address's history looked like at the moment of the check. A new EIP-7702 authorization signed afterward doesn't show up as a transfer from a risky counterparty, so nothing forces a re-score until the next scan.
Do ERC-4337 smart accounts show up as contracts before they're funded?
No. A counterfactual ERC-4337 address can receive funds before it ever deploys, and until the first outbound transaction triggers deployment, a bytecode check on it returns the same empty result as a brand-new, unused EOA.
Is receiving money from a delegated address illegal?
No, delegation itself isn't illegal or inherently risky. The risk depends entirely on what the delegate contract does, and whether that contract, or the funds passing through it, connect to sanctioned or stolen-funds activity.
Disclaimer: This article is for educational and informational purposes only and is not legal, financial, tax, or compliance advice. Crypto carries risk; you act on this information at your own risk. Always do your own research and consult a qualified professional before making decisions. Views are the author's own and do not constitute financial, legal, or investment advice.
About Plastron
Plastron is a free, non-custodial wallet screening tool. It checks Ethereum and six EVM chains for AML and KYT risk — sanctions exposure, mixer contact, and stolen-funds proximity — and returns a risk report in seconds. It reads public on-chain data only: it never takes custody of funds and never asks for private keys.