The Four-Minute Twin: Address Poisoning on Base, Measured

The Scheme

An automated operation watches real USDC payments on Base, generates an address matching the recipient's first and last four characters, and uses zero-value transferFrom calls in cheap batches to plant that twin in the payer's history. The bet is that the next repeat payment is copied from history instead of a verified contact.

Twenty Minutes. One Busy Photocopier.

On 20 October 2026, between 16:01:57 and 16:21:55 UTC, the desk read every USDC transfer event on Base across 600 consecutive blocks, numbers 52,861,385 to 52,861,984. That window held 62,009 USDC transfers. 2,101 of them moved exactly zero USDC, landing in the history of 1,650 different wallets.

A transfer of nothing is not a payment. It is a calling card. A zero entry can have legitimate explanations; zero alone is not a conviction. But a recipient dressed to resemble someone the payer already used is rather more interesting. In those matched cases, the entry is the product: a calling card slipped into a place you normally trust. The photocopier is not printing money. It is printing somewhere for your money to go.

Method note: we queried the official USDC contract on Base through a public node, then compared each zero-value transfer with the real, non-zero USDC payments made by the same wallet in the same window. Anyone with an RPC endpoint can rerun the same block range and get the same events. No wallet owner was contacted or identified.

The Signature That Was Not Yours

The trick separates two things a transaction list can make look identical: who submitted the transaction and which addresses appear inside a token’s Transfer event. The submitter signs the transaction. A token event can still name another address as the apparent sender. A row with your address in it is not, by itself, evidence that you signed anything.

ERC-20 requires zero-value transfers to be treated as normal transfers and to emit the Transfer event. In Circle’s published implementation, a zero-value transferFrom can pass the amount-versus-allowance check even when the allowance is zero, subject to the contract’s other checks. This is not permission to move a positive balance. It is enough to write the zero-value entry. No secret key has to be stolen for that step. Published code explains the mechanism; we did not establish the active implementation at the historical blocks or decode the call path of every sampled event.

Whether an explorer or wallet displays, labels or suppresses the event depends on that service. If it includes the event in token history, the apparent recipient can sit beside the real one. The lure depends on treating that display as a trusted recipient list. The blockchain records the event accurately; the dangerous inference is that a recorded recipient must be one you chose.

We do not publish a real payer or recipient from the sample, even masked. The visual mechanism needs no victim exhibit: two different full addresses can share the displayed prefix and suffix while differing in the hidden middle. At four hex characters on each end, only eight of forty hex characters are being compared. The other thirty-two do not disappear. The screen merely declines to introduce them.

This is not a cryptographic collision, a duplicate private key or an attacker taking over the genuine address. It is a collision in the abbreviated display. Same dinner jacket at the door; entirely different gentleman inside.

The Arithmetic Behind the Queue

There is another way to read our sample that a headline count misses. The 2,101 zero-value events are 3.39% of the 62,009 USDC Transfer events: about one in thirty. Across the recorded 19 minutes and 58 seconds, that is roughly 105 zero-value entries per minute. These are calculations from our window, not a new dataset or a daily forecast. And they count all zero-value events, not only the tailored subset.

The 247 transactions carried an average of 8.51 zero-value entries each. The biggest, at 217 entries, accounts for about 10.3% of the entire zero-value count by itself. That is why “number of transfers” and “number of transactions” must not be used interchangeably. One submission can write many lines. Counting every line as a separate attacker would turn one man with a printer into a convention.

Likewise, 1,650 distinct wallets is not 1,650 identified people. One person can use several wallets; one service can represent many people. Nor do 247 transactions establish 247 operators. Our distinctive finding is the combination of timing, visible-end matching and batching in the same bounded USDC sample. We make no claim that no one else has ever studied those features. The desk’s contribution is this particular measurement and its transparent denominators.

An Old Trick, Not a New Verdict

The trick itself is old. The peer-reviewed USENIX Security 2025 study by Tsuchiya, Dong, Soska and Christin measured 270 million poisoning attempts against 17 million victims over two years on Ethereum and BNB Smart Chain, with at least 83.8 million USD in confirmed losses.

What changes on a cheap Layer 2 is the economics of failure. Low submission costs can make repeated failed attempts economically tolerable. A large misdirected payment could change that calculation, but our sample supplies no success rate or profit estimate. Cheap attempts are not the same thing as a proven profitable campaign.

Industry telemetry points the same way. Webacy reported in April 2026 that poisoning events in its monitored wallets rose about fourfold between October 2025 and March 2026, and that Layer 2 networks such as Base account for a growing share. Our 20-minute snapshot is a single window, not a trend line, but it captures a busy window. It cannot establish that every hour looks like this.

Do Not Hire History as Your Accountant

Start from the recipient, not the last row. Obtain the address through an independently verified recipient channel and save it as a labelled contact or allowlist entry. A label you assigned after checking is useful; a name displayed by an unknown sender is not the same assurance. Transaction history is a record of events, not a guest list approved by you.

Compare the full destination. Check the complete address against that verified source on the correct network. Reading six characters in the middle can expose a simple imitation, but it is not a guarantee: attackers can select resemblance patterns. Do not substitute a longer glance for an independent source. The middle is where the costume often tears; the full address is still the identity.

Treat unexpected entries as untrusted. A zero-value or dust event can be suspicious without moving funds. Hiding spam can reduce the lure if the wallet supports it, but does not remove the event from the chain or certify the remaining rows. A zero event alone is not proof that your keys were compromised. Revoking approvals does not prevent someone emitting another zero-value event.

For a large transfer, test the verified destination. Send a small amount and ask the actual recipient, through the independently verified channel, to confirm receipt. Check the complete destination and transaction on BaseScan. Then reuse that exact saved destination. Sending a small test to the twin and seeing it onchain proves only that you sent the test to the twin. The dress rehearsal must have the right actor.

If you already paid the wrong address, preserve evidence. Keep the transaction record and correspondence privately; contact the sending service promptly and use our official crypto-theft reporting guide. Do not pay a recovery stranger to “unlock” the transfer. Our address poisoning prevention guide gives the step-by-step routine. For this case, verify the actual transaction and full recipient on BaseScan; a general risk label cannot authenticate the person you meant to pay.