Someone poisoned your wallet: how a $0 transfer steals your next payment

Have you ever paid someone this way: you need to send funds to a counterparty you deal with regularly, you don't feel like digging up the address again, so you open your wallet's transaction history, find the last transfer you sent them, copy the address, paste, confirm.

There is nothing wrong with the instinct. Almost everyone does it, because an address is 42 characters of noise that nobody can memorize, and "copy it from a transfer I already made" feels like the safest option available.

Address poisoning is a scam built specifically to feed on that habit.

How it works

Step one: the attacker watches your wallet and sees who you have been paying. This takes no skill at all — on-chain data is public, anyone can read it.

Step two: the attacker generates an address whose first few and last few characters match your real counterparty exactly. The thirty-odd characters in the middle are completely different, but that doesn't matter, because nearly every wallet UI shortens addresses to something like 0x742d…f44e. The characters you actually look at are the ones the attacker matched.

Step three: the attacker sends a zero-value transfer from that lookalike address to your wallet. It costs you nothing and requires no approval from you — anyone can send anything to any address on-chain. But it accomplishes one thing: it inserts a row into your transaction history that looks like you and that address have dealt with each other.

Then the attacker waits. Waits for your next payment to that counterparty. Waits for you to open your history out of habit. Waits for you to see an address whose first and last characters check out — copy, paste, confirm.

The money goes to the attacker. On-chain transfers are irreversible, and there is no support line to call.

Why this is worse for agents

A human has one layer of protection left: you hesitate. You might look twice. You might send a small test amount first.

An agent doesn't hesitate.

An AI agent paying on your behalf usually receives nothing more than an address string. It won't feel that something is off about a familiar-looking address, and it won't spend an extra second on it just because the amount is large. If its payee came from transaction history, from chat context, or from a poisoned data source, it will pay — in a few hundred milliseconds.

This is exactly the thing we keep saying about agent payments: they happen far too fast to regret. The judgment has to happen before the payment, not in a post-mortem afterwards.

The counterintuitive part: the poisoned party is not the bad guy

There is one thing about poisoning that is easy to get wrong, and it deserves its own section.

Many risk tools work on a simple rule: any funds relationship with a bad address makes you suspicious. Under that rule, once you have been poisoned, your address now has a "transaction relationship" with a scammer, and your risk score goes up.

That is wrong, and it is wrong in a way that hurts people. You received nothing. You didn't even know it happened. You are the victim, not an accomplice. A system that flags victims isn't just inaccurate — it turns away exactly the people who need help.

So in our taint tracing, this case is pulled out and handled separately: an incoming transfer of zero value contributes zero risk score. Not a fraction of a point. And we say so in the result: "This is a zero-value incoming transfer — no funds were received. This is very likely address poisoning. Don't copy addresses out of your transaction history."

Same data. One system uses it to penalize you; the other uses it to warn you. The difference isn't algorithmic sophistication — it's whose side you're on.

Three things you can do right now

One: never copy a payee address out of your transaction history. This is the one piece of advice that actually works. Keep addresses in your wallet's address book, or fetch them again from the counterparty's official channel. Twenty extra seconds beats losing the whole payment.

Two: don't check only the beginning and the end. If you must verify by eye, verify the middle characters — an attacker can match the ends, not the middle. Or just compare the full string.

Three: put a check in front of your agent's payments. If you're writing software that pays automatically, the payee address should be screened before the funds move. That's not friction for a human; it's one line of code for a program.

What we built (and how to check it yourself)

Paste an address into our address check. If we find zero-value incoming transfers in its history, we tell you plainly that the address may have been poisoned — and we do not penalize it for that.

Deep tracing spells out every tainted path: how many hops, how long ago, how large a share, how many points it contributed. Zero-value transfers are marked separately and labeled "0 points." We don't hand out black-box scores; every point has to be explainable.

What we can and can't do

Being clear about limits matters more than sounding capable:

We can see it. We can't stop it. No third party can block a validly signed on-chain transfer — not us, not anyone. What we can do is tell you about the address before you (or your agent) hit confirm. Actually stopping a payment requires that the funds move through a session key with an on-chain spending limit and payee allowlist — then a payee outside the list is rejected at the contract level.

We only see the transfers we've collected. Nobody has the complete on-chain dataset, and we don't either. "No poisoning found" is not the same as "definitely not poisoned."

We put both of those sentences in the product, and we're putting them here too.