The ERC-4337 Blind Spot Most Screening Tools Miss

An ERC-4337 smart account's real owner sits inside a UserOperation's sender field, invisible to any screening tool that only checks a transaction's top-level from and to address.

On March 1, 2023, Ethereum's EntryPoint contract went live on mainnet, and every one of the four major bundler networks - Alchemy, Biconomy, Pimlico, and ZeroDev - has routed ERC-4337 traffic through it since. Coinbase Smart Wallet ships on it by default, and consumer apps built through Safe's 4337 module inherit the same architecture. The same EntryPoint contract runs unmodified on Base, Arbitrum, and Optimism, so this isn't an Ethereum-mainnet quirk. Most wallet-screening playbooks were written for plain externally-owned accounts, and they still assume the address in a transaction's from field is the wallet that signed it. For an ERC-4337 account, that assumption is wrong every single time.

What Makes an ERC-4337 Transaction Different?

A UserOperation isn't an Ethereum transaction. It's a signed request that a wallet app hands to a bundler - a relay operator like Alchemy, Biconomy, Pimlico, or ZeroDev - which bundles one or more of them into a single real transaction and submits it through a shared contract called EntryPoint. Open that transaction on a block explorer and the from field shows the bundler's address. The to field shows EntryPoint's address. The wallet that actually signed the request, and actually holds the funds, sits inside the calldata in a field named sender.

The address doing the paying isn't the address in control.

Why Does the Bundler Address Screen the Wrong Party?

Alchemy, Biconomy, Pimlico, and ZeroDev each process UserOperations for thousands of unrelated wallets through the same handful of bundler addresses. Flag a bundler and every one of its users lights up at once, or a screening tool ignores bundlers entirely and treats them as noise. EntryPoint makes it worse: one singleton contract, deployed once, shared by every ERC-4337 wallet on Ethereum. Block transactions to it and legitimate smart accounts stop working. Ignore it and nothing routed through it ever gets checked.

Screening the relay tells you nothing about who's riding on it.

Can a Sanctioned Address Hide Inside a Smart Account?

OFAC's sanctions list doesn't care whether an address is a private key or a smart contract - a sanctioned wallet stays sanctioned no matter which standard it transacts through. What changes with ERC-4337 is whether a screening tool can find that address at all. A paymaster can sponsor gas for a smart account that holds zero ETH of its own, so the wallet paying for the transaction and the wallet controlling it are two different addresses again. And because bundlers batch multiple UserOperations into one transaction, a flagged sender can ride alongside several clean ones inside a single on-chain event.

One bundle, one transaction hash, several unrelated risk profiles.

A single bundler transaction can carry several UserOperations from unrelated senders, each paying its own share of gas inside the same on-chain event. Screening software built around one-transaction-one-wallet logic checks that transaction hash once and moves on. It never opens the bundle to look at the senders stacked inside it, which is exactly where a sanctioned or mixer-linked address would sit.

What Should a Screening Tool Actually Check?

The fix is mechanical, not exotic: decode the handleOps call in the transaction's input data, pull out each UserOperation's sender field, and screen that address - plus the paymaster and factory addresses tied to it - instead of stopping at the bundler and EntryPoint. AMLBot's account-abstraction compliance guidance says the same thing directly: customer mapping has to use the UserOperation sender, not the top-level transaction.from.

You can pull that sender field by hand on Etherscan - open the transaction, find the handleOps input, and decode the tuple. It works, one address at a time, and it won't tell you if that sender has ever touched a mixer or a sanctioned exchange three hops back. Plastron's dataset already covers 3,901 labeled Ethereum addresses, including all 780 currently on OFAC's SDN list, and checks them the same way regardless of whether the address showed up as a plain wallet or as a UserOperation sender behind a bundler. Screen the address with Plastron to get that full exposure picture - sanctions, mixer contact, stolen-funds links - across Ethereum and six other chains in one pass.

FAQ

Is ERC-4337 the same as EIP-7702?

No. EIP-7702, live since Ethereum's Pectra upgrade on May 7, 2025, lets a regular externally-owned account temporarily act like a smart contract for one transaction. ERC-4337 is a separate, older standard - live since March 2023 - built around permanent smart accounts, bundlers, and EntryPoint. Plastron covered the EIP-7702 gap in a separate post; the two overlap in effect but not in mechanism.

Does this affect Safe multisig wallets?

Only when a Safe uses the Safe4337Module to accept UserOperations directly. A standard Safe multisig transaction still shows its actual signers in a conventional transaction, so the blind spot described here applies to the ERC-4337 path specifically, not to multisig itself.

Can a paymaster make a wallet harder to screen?

Indirectly, yes. A paymaster lets a smart account transact while holding zero ETH, which removes gas-funding patterns that some monitoring rules use as a proxy signal. It doesn't change the account's sanctions status, but it does mean the account can look inactive right up until it moves real value.

Which wallets actually run on ERC-4337 today?

Coinbase Smart Wallet ships on it by default. Safe's 4337 module, and infrastructure from Alchemy, Biconomy, Pimlico, and ZeroDev, power account abstraction inside a growing set of consumer and DeFi apps built on top of those providers.