How Address Poisoning Cost One Firm $2 Million

An investment firm sent $2 million in USDC to the wrong address. Not a typo, not a compromised key, not a phishing site: an operator copied a line from the company's own transaction history, and the line belonged to somebody else.

The funds were converted to DAI within minutes. Nothing about the transfer was reversible, and nothing in the workflow flagged it, because from the wallet's perspective the transaction was entirely normal.

How address poisoning works

Address poisoning starts with a payment you did not ask for. In this case it was 0.0002 USDC, sent to the firm's wallet from an address whose first and last characters matched those of a counterparty they dealt with regularly.

The attack targets a habit, not a system. Nobody reads a forty-two character string end to end. People check the opening characters, glance at the closing ones, recognise the shape, and copy. The middle is where the difference lives, and the middle is exactly what interfaces hide.

Once the poisoned entry sits in the ledger of past transactions, the attacker's work is done. The victim performs the theft themselves, the network confirms it, and no appeal exists.

Why it worked on professionals

Bofur Capital was not an inexperienced holder. It had a working relationship with the genuine counterparty and had sent to that address before. That familiarity was the vulnerability: the address looked known, the operation looked routine.

The preparation is what makes this case instructive. The poisoned entry was planted roughly twenty hours before the large transfer. The attackers were watching the wallet, waiting for a moment when a fresh decoy would sit near the top of the history and get picked up first.

This is targeted work, not spray-and-pray. Large wallets are public: balances, counterparties and payment rhythms are all visible, so an attacker can shortlist candidates and then simply wait.

The scale of it

Address poisoning has stopped being a curiosity. Analysts tracking USDT dust transfers recorded a 612% increase over three months, with the surge following a network upgrade that made the economics more favourable.

Earlier research covering July 2022 to June 2024 gives a sense of the base rate: roughly 17 million poisoning attempts, at least 1.3 million affected users, and a minimum of $79.3 million in losses.

The same work found that these attacks occur over 1,300% more often on chains with low fees. The logic is arithmetic - cheap transactions mean more wallets can be seeded for the same budget, and address poisoning scales with the size of the net.

Individual losses run high outside the headline cases. One investor sent more than 500,000 USDT to an attacker, following the identical path: open history, copy line, paste, confirm.

Four variants of the same idea

The classic version uses a dust payment: the attacker spends a fraction of a cent so that their address appears in your transaction list.

The second uses zero-value transfers. Token standards allow a transfer of zero units to be initiated on behalf of another address, so an entry appears showing that you apparently sent funds to the attacker. Cost to the attacker: nothing.

The third is computational. Attackers generate an address matching the target not only at the edges but across several interior characters, which costs real processing power and is reserved for targets worth the expense.

The fourth hides the payload in metadata. A token arrives whose name contains a lookalike address or a link, and the victim copies the string straight out of the token name. Technically that is phishing rather than address poisoning, but the entry point is the same list.

What unites them is that none require access to your keys. The attacker needs one thing only: for you to copy the wrong line.

Transaction history is not an address book

For address poisoning to work, one assumption has to hold: that a history view is a list of vetted counterparties. It is not. It contains everyone who has ever sent you anything, including people you have never heard of.

Interfaces make this worse. Most wallets and explorers truncate addresses to something like six characters, an ellipsis, and four more. That format is what makes substitution viable, because matching edges is enough to earn a human's trust.

There is a second trap in the search box. Type the opening characters of a familiar address, get a match, take the result. A poisoned entry surfaces in that search alongside the real one, and sorting by recency often puts the fake on top.

So the rule is blunt: history is for reading, never for copying. Addresses should come from an address book, a QR code, or a message received through a channel you have verified separately.

Technical defences

Use an address book. Save verified counterparties once, label them clearly, and initiate transfers only from those saved entries. This alone removes most of the exposure.

Send a test transaction. Before any large transfer, move a token amount and have the recipient confirm receipt. It costs cents and it has saved eight-figure sums.

Compare the whole string when manual entry is unavoidable. Checking in blocks of four characters starting from the middle is faster than it sounds and defeats edge-matching entirely.

Use a signing device with a screen. The address shown on the hardware display is the last point where a substitution can still be caught, provided you actually read it.

Enable withdrawal allowlists. Most exchanges and many wallets can restrict outgoing transfers to pre-approved addresses; for a company this should be mandatory configuration rather than an option.

Filter incoming clutter. Some wallets can hide zero-value transfers and tokens from unknown senders. It is not protection in a strict sense, but a clean history is one where a decoy cannot sit next to the real thing.

Process defences

Technical controls fail when the workflow is built for one person. In most corporate losses of this kind, the same individual prepared the payment and approved it.

Separate the roles. Whoever enters the address and whoever authorises the send should be different people, and the address should travel between them through a shared directory rather than a screenshot.

Multisignature achieves the same outcome mechanically: a second signature means a second pair of eyes on the destination string.

Introduce a delay. Large transfers should not execute immediately after the address is pasted. A five-minute pause for re-verification breaks the exact scenario these attacks depend on, because the decoy relies on being fresh in memory.

If dust has already arrived

Nothing has happened yet. Receiving a small unsolicited payment grants the sender no rights over your funds and cannot move anything.

Do not interact with the tokens. Do not forward them, do not try to swap them, and do not open links embedded in a token name - that path leads to a drainer, not to a cleanup tool.

Mark the sender as spam if your wallet supports it, and hide the entry. Then check whether the decoy has landed near your genuine counterparty in the list, because proximity is what produces the error.

If dust keeps arriving, treat it as a signal that your address is on a target list. Rotate to a new receiving address and keep the old one for history only - address poisoning depends on a specific string, and changing it discards the attacker's groundwork.

If the transfer has already gone

Move fast, but keep expectations realistic. Record the transaction hash and the destination, and contact any centralised service in the path immediately.

Stablecoins offer a narrow opening: issuers can freeze balances at law enforcement request. That requires a police report and, in practice, a sum large enough to justify the process.

File the report regardless of the odds, with hashes, amounts, timestamps and screenshots. Even when funds are unrecoverable, that documentation matters for accounting, insurance and any future case built from multiple victims.

And ignore anyone offering recovery for an upfront fee. After every publicised incident those messages arrive within days, and they are the same industry working the next stage.

The short version

Address poisoning breaks no cryptography and touches no keys. It exploits one human shortcut: trusting a familiar-looking beginning and ending.

The defences are cheap and boring - an address book instead of a history list, a test transfer before anything large, and a second person on the approval. The firm that lost $2 million had none of the three.