Address Poisoning: Why Seven of Forty Characters Were Enough to Divert $2 Million

On August 21, 2026, a transfer of 2,000,000 USDC left a wallet and landed at an address that matched the correct one in exactly seven of forty characters. Four characters at the front, three at the end. The remaining thirty-three were completely different. That precise cut is the entire attack, because wallets and block explorers usually show addresses in shortened form: a few characters at the front, a few at the back, three dots in the middle. Anyone who looks only at that short form sees the same thing on the fake as on the original.

The technique is called address poisoning. Address poisoning means that an attacker plants a fake but similar-looking address into your wallet's transaction history, so that you later copy it from there and send your money to it yourself. Nothing is hacked, no key is stolen, no signature is forged. The transfer is technically flawless and authorised by the owner. It simply goes to the wrong recipient, and on a blockchain that makes it final.

This article takes the August 21 case apart and then goes further than the reports published so far: we read out the full transaction history of the affected wallet and counted it. The result shows that the decoy address was not a one-off but part of a stock that accounts for a third of all counterparties this wallet has ever touched.

Address poisoning explained: how a fake wallet address gets into your history

The attacker needs no access to your wallet. They need only an entry in your history, because for most users that history is the most convenient source for a receiving address. Instead of fetching a forty-character string from a contract, an email or a slip of paper, you scroll back in the wallet app or the explorer, find the line with the last transfer to the same recipient and copy the address from there. That reach is the target.

There are two common ways to get into the history. The first is the dust transfer: the attacker sends you a tiny, economically meaningless amount from their fake address. A fraction of a cent is enough. That puts their address in your history without them having to know anything about you.

The second way is the fake transfer event. On Ethereum and comparable networks, anyone can publish their own token contract, and that contract may report whatever it likes. Such a contract emits an event that looks as though you had just sent a large amount to a particular address. A completed transfer that never happened appears in your history. The advantage for the attacker is obvious: an address you have supposedly already sent two million to looks more familiar than one that only sent dust.

Both routes cost the attacker almost nothing and can be repeated at will. They do not need to know when you will next transfer funds. They only need their entry to sit at the top of your list at that moment. Part of why this works so well on a network such as Ethereum is that any token contract can be published there without review.

The Bofur Capital case: 2 million USDC thirty minutes after the Compound withdrawal

The security firm PeckShield reported the incident on August 22, 2026 and attributes the affected wallet to the market participant Bofur Capital. That attribution comes from PeckShield, it cannot be confirmed from the blockchain data alone, and we carry it here as a third-party statement. The sequence of events, by contrast, is out in the open on the chain and can be verified. All times below are coordinated universal time.

On August 20 at 20:12:23, the wallet transferred 2,000,000 USDC to an address it had already used a month earlier. Eight minutes and thirty-six seconds later, at 20:20:59, a dust transfer of 0.0002 USDC arrived. The sender was an address that looked similar to the one just used. That same address had been topped up seconds earlier by a third party with 0.000801 USDC, in other words with just enough balance for this single decoy.

Over the next not quite two hours, two supposed transfers of 2,000,000 each to the same fake address also appeared in the wallet's history, at 20:41:11 and at 21:16:11. Both come from an external token contract and never took place. To anyone looking at the list the following day, the fake address therefore looked like one this wallet had only just sent millions to, several times over.

On August 21 at 16:01:23, the wallet withdrew 2,000,000 USDC from the Compound USDC contract. At 16:31:11, thirty minutes later, 2,000,000.000000 USDC went to the fake address. No second attempt followed and no correction. The amount then moved through a collection wallet, was swapped into DAI at 23:28:35 via the settlement contract of CoW Protocol and parked at 23:31:11 as 1,999,939.476314 DAI on a third address. There it sits, as of this analysis, unchanged.

Four characters at the front, three at the back: how similar the fake address really was

The decisive point is how little similarity this attack requires. The recipient address actually used and the fake one match in four characters at the start and three at the end. That is seven of forty characters. Thirty-three characters in the middle are different, many of them obviously so at first glance.

The reason that is still enough lies in the display. The usual short form in wallet apps, explorers and overview lists shows roughly the first six and the last four characters. That exact section is practically identical on both addresses. The thirty-three diverging characters sit in the part that the interface replaces with three dots.

Generating such an address is neither an art nor a feat of computation. The attacker runs through key pairs until one produces an address with the desired opening and closing characters. The more characters have to match, the longer it takes, but four at the front and four at the back are a matter of minutes on off-the-shelf hardware. That is also why the number of decoys is not limited by effort.

Dust transfer and fake transfer event: two techniques, one goal

In this case both techniques ran side by side, and that is the part missing from the reports so far. What was reported was the dust transfer of 0.0002 USDC. Alongside it, the chain holds several supposed million-dollar transfers from fake contracts, and those are what complete the picture in the history.

The difference matters in practice. Many users ignore a dust amount from an unknown address because they file it under advertising or spam. An entry that looks like your own million-dollar transfer, made only moments ago, reads like a receipt instead. Anyone looking for the last payment to the same recipient finds precisely that entry, and it sits higher in the list than the original.

Neither entry can be technically deleted from your own history. A blockchain forgets nothing, and an event from an external contract stays visible even when it is pure invention. Some interfaces hide suspicious contracts or flag them. You cannot rely on that, because detection varies in strictness from provider to provider.

Homoglyphs in the token name: why a fake ticker looks like USDC in the explorer

For the false entries to pass unnoticed, the token has to be right as well. The contracts used for this carry tickers that look like USDC, DAI or ETH in the explorer but are not. The trick is called a homoglyph. A homoglyph is a character that looks confusingly similar to another one but is technically a completely different character.

The data we read out contains several designs. One group of contracts uses Cyrillic letters: a Cyrillic Dze in place of the Latin S and a Cyrillic Es in place of the C, plus a U with an accent. What appears on screen is something you read as USDC. A second group slips invisible control characters between the letters, a zero-width joiner or a Mongolian vowel separator for instance. The ticker then looks exactly like the real one, but is not. A third group works with the simplest means available and writes a lowercase L instead of a capital I, which in many typefaces cannot be told apart. And some contracts do without any disguise at all and simply carry the correct ticker, because a token symbol does not have to be unique.

For you that means: the ticker next to an amount is no proof of which token was actually moved. The only reliable identifier is the contract address. USDC and DAI each have exactly one correct address, and every explorer displays it when you click on the token.

Our own survey: how many decoy addresses sit in a single wallet's history

This analysis was carried out by cryptoticker.io itself on August 22, 2026. Using the public interface of the Blockscout block explorer, we retrieved every token transfer event of the affected wallet, across six pages, then deduplicated and counted the records. We captured timestamps, amounts, the token's contract address and both sender and recipient.

Examined: 300 unique transfer events from the period between November 22, 2025 and August 22, 2026, among them 84 different counterparties. 165 of these events come from the genuine USDC or DAI contracts, 135 from other contracts.

Nine clusters, thirty-three addresses: the count in detail

We grouped all 84 counterparties by whether they match in the first four and the last four characters, which is exactly the section a shortened display shows. Result: 33 of the 84 addresses fall into nine such groups. Each of these groups contains at least two addresses that cannot be told apart in short form. Around a third of all counterparties this wallet has ever touched therefore belongs to a stock of look-alikes.

The largest group comprises eight addresses. The second largest five, the third largest four. Three further groups have three members each, two have two each. The group the August 21 theft came from holds three addresses, and a neighbouring group with the same opening but a different ending holds another three, among them the recipient address actually used.

The distribution says something about the method: for every recurring counterparty of this wallet, several decoys were evidently created rather than a single one. Anyone copying an address from the history is reaching into a stock in which the correct address is in the minority.

Limits of this survey

We do not know whether the same actor stands behind all nine groups; the grouping describes a pattern, not culpability. We do not know whether all 135 events from external contracts are attack attempts, because among them are recognisably ordinary advertising tokens with no connection to this technique. We do not know which wallet software the affected wallet used or how it displays addresses. We do not know whether and how many German investors were approached by the same groups, because places of residence cannot be read from blockchain data. And we do not know whether the funds can be recovered.

The Compound contract has look-alikes too: why even protocol addresses get faked

One side result of the count deserves attention of its own. This wallet's most frequent counterparty is the Compound USDC contract, through which it regularly deposits and withdraws. For this address as well, two others were found that are identical in the first four and the last four characters.

That extends the danger beyond the payment recipient. Anyone copying a contract address from their own history, to enter it into a wallet interface or to check that they are talking to the right protocol, can be misled in the same way. The countermeasure is simpler here than with a private recipient: contract addresses of known protocols are listed in their own documentation, and explorers mark verified contracts by name. For the Compound contract and the settlement contract of CoW Protocol that marking was present in our retrieval; for the look-alikes it was not.

Eight minutes after the real payment: when the decoy is set

The timing of the decoys was the most surprising detail in our analysis. The attack followed immediately on a real payment, and did so twice to the same pattern.

On July 21, 2026 at 14:37:11, the wallet transferred 2,000,000 USDC to its usual counterparty. At 14:45:23, eight minutes and twelve seconds later, a dust transfer of 0.0002 USDC arrived from an address with the same four opening characters. On August 20 this repeated itself: real transfer at 20:12:23, dust transfer at 20:20:59, a gap of eight minutes and thirty-six seconds.

It follows that the chain is being watched and that the decoy is only set once a real, recurring payment has become visible. That matters for the defence: the most dangerous spot in the history is the entry directly above the last real transfer, because it was placed where the next search will look. Anyone who regularly sends the same amount to the same place is a particularly rewarding target for this technique.

The thief gets poisoned in turn: what happened in the perpetrator's history 25 minutes after the theft

At 23:31:11 the stolen 1,999,939.476314 DAI sat at their new address. Twenty-four seconds later, at 23:31:35, a transfer of exactly the same amount appeared in the collection wallet's history, sent to an address that matched the one just used in the first four and the last four characters. The amount came from a fake contract whose ticker was made to look like DAI by an invisible control character.

It did not stop there. At 23:44:23 a genuine dust transfer of 0.0002 DAI arrived from another look-alike address. Three further fake transfers of the same amount to three different look-alikes followed during the night, along with entries from contracts passing themselves off as ETH, and on the morning of August 22 a transfer of zero from the genuine DAI contract. Within a few hours, at least four different addresses stood in the perpetrator's history, all beginning with the same four characters and ending in the same four as their own hiding place.

The episode is more than a footnote. It shows, first, how automated this technique is: a freshly filled large holding is evidently spotted and served within seconds, without anyone having to check whose it is. And it shows, second, that the attack needs to know nothing about its victim. It targets a habit, not a person.

Check the address instead of copying it: the steps that make the attack come to nothing

The good news about this technique is that it hangs entirely on a single habit. Anyone who does not take the receiving address from their transaction history is not exposed to address poisoning, no matter how many decoys sit in their list.

The first step is therefore the most important: take the address from the source it originally came from. That is the invoice, the withdrawal page of your exchange, your wallet's address book or the recipient's message. Your own history is not a source but a copy that anyone can write into.

The second step is the full check. Compare the entire string, not the short form. The most reliable way is to place the address from both sources side by side and go through it character by character, or to paste it into a search field and check that the address found actually has the expected history. A glance at the first and last characters delivers exactly what the attacker has budgeted for.

The third step concerns the middle. If you can only check a section, then deliberately check characters from the middle of the address rather than the edges. In our case thirty-three of the forty characters were different, and all thirty-three sat in the part nobody looks at.

Why the hardware wallet display is the last line of control

A hardware wallet shows the receiving address on its own screen before you confirm the transaction. That screen is not attached to the computer and cannot be rewritten by a manipulated interface. It is therefore the last place where a wrong recipient can be caught, and on most devices the full address can be scrolled through there. The comparison is worth making with large amounts in particular, and it costs a few seconds. Which devices implement this display and how is set out in our hardware wallet comparison.

Address book and whitelist: how to set a receiving address once

Recurring payments are, as the case shows, the preferred target. An address book is exactly what helps against that. Almost every wallet application and every larger exchange lets you store a receiving address once, give it a name and from then on select only that name. The copying step out of the history falls away completely.

At exchanges the same function is usually called a withdrawal whitelist. It has an additional benefit: new addresses often cannot be used until a waiting period of 24 or 48 hours has passed. Even if somebody takes over your account, they cannot send the balance to a fresh address straight away. Check whether your provider offers this lock-up period and whether it is switched on, because frequently it is not on by default.

The timing of the entry remains crucial. An address you carry over into your address book from a poisoned history is permanently wrong there, and the next mistake then happens automatically. Enter it from the original source, and check it in full once as you enter it.

Test transfer: when a small advance payment helps and when it only costs fees

A small advance payment to a new address is a sensible safeguard if the recipient can confirm receipt to you. You are then checking the result rather than the address, and that is the more robust test. At an exchange you see the credit in your own account; with a business partner you need a reply.

Without that confirmation the test transfer achieves little. The fact that a transaction was confirmed says only that the address exists. In an address poisoning attack the false address obviously exists, and it accepts the test amount just as readily as the large one. Anyone who then transfers without a reply has merely paid the same attacker twice.

Factor in the cost as well. On networks with high fees a test transfer can be expensive, while a full address comparison costs nothing. The order that works: check the address in full first, then additionally test with new recipients and large amounts.

Documenting the loss: which details to secure after a misdirected transfer

Once the money is gone, the blockchain will not change that. A confirmed transaction cannot be recalled, and nobody can reverse it. What counts now is documentation, and immediately, because interfaces change and overviews get re-sorted.

Secure the transaction hash, the full recipient address, the exact time, the amount and the contract address of the token moved. Secure the entry you copied the address from as well, with its timestamp, because that establishes the sequence of events. A screenshot adds to this but does not replace the identifiers. What is still practically possible afterwards and what is definitively lost, we have written up in our piece on crypto sent to the wrong address.

For the tax treatment of such a loss there is no clear, generally accepted line in Germany, and we deliberately do not set one out here. What you can do is create the basis: a complete and consistent record of all the transactions involved, which a tax adviser can work with. Portfolio and tax tools help with this because they hold addresses and transactions on file permanently.

Spotting address poisoning: what to take away

1. Never take the receiving address from your transaction history. Take it from the invoice, the withdrawal page or the address book. The history is the one place an attacker can write to, and that is precisely why they start there. Which wallets come with a usable address book is shown in our software wallet comparison.
2. Check the full address, with the emphasis on the middle. Seven of forty characters were enough in our case to make the short form look identical. With larger amounts, read the address off your hardware wallet display as well, because that screen cannot be manipulated; the devices at a glance are in the hardware wallet comparison.
3. Set up an address book and a withdrawal whitelist before you need them. Enter recurring recipients once from the original source and, where available, switch on the lock-up period for new addresses. Keep your addresses and transactions cleanly on file, for instance with one of the tools from our overview of tax and portfolio tools.

The evidence for this article is publicly verifiable: the report of the incident at The Crypto Times and the full transaction history of the affected wallet in the Blockscout block explorer, on which our count is based.

(As of August 22, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)