Address poisoning on TON: the clipboard attack

Address poisoning is the quietest of the mass attacks against crypto wallet users, and in 2025 it arrived in TON in earnest. No phishing site, no social engineering, no seed-phrase compromise is required. The attacker simply sends a zero-TON transfer from a wallet whose address, at a glance, looks like one of your regular counterparties. A week later, when you copy the “familiar” address from your recent transactions, you copy the forgery. The signature goes through, the funds leave, the post-mortem starts. This piece is about what makes TON a particularly comfortable surface for this attack and what minimum set of habits closes it.

TL;DR

The attacker generates an address whose first and last 4-6 characters match a contact you transact with regularly and sends you 0 TON from it.
The point is not to steal then and there — it is to plant a “poisoned” address in your transaction history so the next copy-paste picks it up.
TON user-friendly addresses (UQ… / 0Q…, base64url, ~48 chars) are visually noisy: edge-only checks fail.
Defence: never copy from history, keep counterparties in an address book or behind TON DNS, verify the full string, especially on the Ledger screen.
For teams: multi-sig with allow-list, test transfers, out-of-band confirmation.

How address poisoning works

The scheme has three components, none of which require access to your wallet.

The first component is the vanity address. With brute force on CPU or GPU the attacker generates a TON address that matches, say, the first 4 and last 4 characters of an address you use regularly. The generator iterates through private keys and computes the corresponding wallet address until the pattern matches. On modern hardware a 4+4 collision lands in minutes; 6+6 takes hours.

The second component is the dust transaction. From the lookalike address the attacker sends you 0 TON or 0.000001 TON. Sometimes the comment is empty, sometimes it whispers “refund”, “test”, “cashback”. The whole thing costs the attacker a fraction of a cent in gas.

The third component is copy-paste psychology. Some time later you send funds to the same counterparty as before. You open Tonkeeper, hit the history tab, see a recent transfer with familiar edges — UQAB…6F2C — and copy from there. You compare the first and last characters against what you remember, they match, you hit Send. The money lands with the attacker.

Notice that no step in this chain requires a technical compromise of anything you control. The attacker uses you as the delivery mechanism — every mistake is made by you, while you believe you are following your usual routine.

Why TON addresses are particularly vulnerable

The raw TON address is workchain:hash (usually 0: plus a 64-character hex hash). Wallet UIs display the user-friendly format instead: 48 base64url characters with a UQ prefix (non-bounceable) or EQ/kQ (bounceable mainnet/testnet). Inside those 48 characters live the workchain, hash, and checksum, encoded against the base64url alphabet.

What that means for the human eye:

Mixed case and digits. base64url uses A-Z, a-z, 0-9, -, _. The eye fixes on capital letters and digits; everything else dissolves into visual noise.
The UQ/0Q prefix is identical across all non-bounceable addresses. Checking the first two characters tells you nothing. Real discrimination starts at character three.
Checksum is spread across the tail but cannot be verified mentally — you either trust the wallet to reject invalid input or you compare the full string.
48 characters lands precisely in the zone where edge-only checks already fail but full verification feels too tedious to do every time.

Compare with Ethereum, where addresses are 42 hex characters with a 0x prefix. EVM is vulnerable to address poisoning too, but on TON the cost of a slip is higher: wallets often render only the head and tail in history views, and the user sees exactly the characters the attacker pre-selected for them.

Workflow of the attack, step by step

To make it concrete, here is a typical sequence — no invented names or amounts, just the steps.

Day -7. You send $500 in USDT-jetton to your partner at an address starting with UQAB12 and ending in 6F2C. The transfer goes through; the wallet history remembers the address.
Day -6. The attacker watches your partner’s address on tonscan. They see an incoming transfer from you and conclude you are a recurring sender.
Day -5. The attacker runs a vanity generator and finds an address matching UQAB…6F2C on the same 4 edge characters. This takes anywhere from minutes to a few hours.
Day -4. From that address the attacker sends you 0 TON. A new entry appears in your Tonkeeper history: “Received 0 TON from UQAB…6F2C”.
Day 0. You need to pay your partner again. You open the wallet, hit history, see the most recent transfer with the familiar edges, and copy the address. It is the attacker’s.
Day 0 + 1 minute. You paste the address into the recipient field, see the same UQAB…6F2C, mentally tick the check, sign, confirm the amount on Ledger if you use one, and broadcast. $500 lands with the attacker.
Day 0 + 5 minutes. Your partner messages: “didn’t receive anything”. You open the wallet, look at the transaction, and notice the middle of the address is completely different. There is no refund.

For a week of work the attacker collected $500 against costs of tenths of a cent. If they spray dust across a thousand recurring senders, the ROI calculates itself.

Vanity generation: how the lookalike address is produced

A vanity generator is a tool that iterates over private keys and checks whether the resulting address matches a target pattern. For TON wallet v3/v4 the computation is fixed: key → publicKey → wallet contract hash → user-friendly string.

Search difficulty scales exponentially with the number of required characters:

4 edge characters — minutes on a modern CPU.
6 characters — hours on CPU, minutes on GPU.
4 prefix + 4 suffix — same order of magnitude as 6 contiguous characters because the effective match is 8 characters across both ends.
6+6 — tens of hours on a GPU array, economically justified only for high-value targets.

The tools are widely available as open source on GitHub under names like ton-vanity or ton-address-grinder. Their legitimate use is generating memorable project addresses (think a wallet starting with UQDEAD…). The same tools, with minor modifications, drive address poisoning — the task is identical, only the template changes.

The cost is minimal. A GPU-hour on a cloud platform runs $0.5-2. Gas for a dust transaction on TON is a fraction of a cent. One attacker with one GPU produces a pool of hundreds of lookalike addresses overnight and runs a mass dust spray the next morning.

Defence: never copy from transaction history

The minimum habit set that closes this attack almost entirely.

Never copy a recipient address from transaction history. This is rule one. Wallet history is not a contact book. The attacker controls what lands in your history (they can send you any dust they like) and does not control what lands in your address book (only you put things there).

Maintain an address book with human names. Tonkeeper has built-in Address Book support — add each recurring counterparty once with a meaningful label (“partner-USDT”, “payroll-cold”). On the next transfer, select from the book rather than scroll the history.

Use TON DNS / .ton domains. If your counterparty has a .ton domain bound to their address (say, partner.ton), use it. Tonkeeper and MyTonWallet resolve domains to the full address automatically, and substituting partner.ton with a visually similar domain demands a separate phishing operation — a different and much harder class of attack.

Compare the full address, not the edges. When you do have to copy from a fresh thread, verify the string character by character at least once. It is tedious, and it is the only 100%-reliable check.

Use a hardware wallet for material amounts. The destination address shown on the device screen before signing is your last guard. If the address on the Ledger display matches only at the edges, do not approve.

i
An address book is two minutes, once and for life

Adding three recurring counterparties to Tonkeeper takes about two minutes. After that, address poisoning against you is an economically pointless attack — the attacker has no idea what is in your address book, and their dust drifts in your history as unreadable noise.

What to do if you already sent to a lookalike

The worst part of address poisoning is near-zero reversibility. Once the transaction confirms on mainnet, the funds are with the attacker. Still, a minimum plan of action:

Record the transaction. Copy its hash from tonscan, save the link. You will need it for every later step.
Look up the attacker’s address on tonscan. Some attackers reuse the same wallet across many victims. If you see lots of small incoming dust from different senders and one large transfer from you, that is a public behavioural pattern worth reporting.
Report to Tonkeeper / MyTonWallet support. They flag known attackers as “scam” at the wallet level — your report helps the next would-be victim.
Submit an abuse form on tonscan. A flagged address shows up with a warning banner across all integrations.
If the amount is significant, contact the TON Foundation through official channels — major incidents sometimes get coordination with exchanges to freeze outflows.
Document the pattern for your team or community. Any published post-mortem reduces the attack’s effectiveness for everyone else.

The general first-aid algorithm is covered in the TON stolen — what to do guide.

Prevention for teams

For DAOs, foundations, and projects that run regular payouts, address poisoning is particularly dangerous: large amounts, many operations, error surface multiplied by every operator.

Minimum production setup:

Multi-sig 2-of-3 at minimum for outgoing transfers. A single signer cannot make the mistake alone.
Allow-list of recipients at the multi-sig or external registry level. An address joins the registry after an out-of-band check and two operator signatures.
Address source is not the last transaction. Recipient addresses come from CRM, the corporate registry, or a signed contract — never from a recent transfer.
Test transfer. Above a defined threshold, send 0.1 TON first, confirm receipt over a separate channel (voice call, work messenger, never the transaction comment), and only then send the main amount.
Operator rotation. No single person should hold the right to large outgoing transfers without a co-signer.
Monthly outflow audit. Reconcile outgoing transactions against the recipient registry — a simple SQL pull at script level.

Conclusion

Address poisoning is not an attack on the blockchain and not an attack on the wallet. It is an attack on a user habit, and the only remedy is to change the habit. Named contacts in the address book, TON DNS, full-string verification, multi-sig for serious amounts. None of this costs anything, none of it requires special software or technical training, and together they close the attack surface almost entirely. The price of attention is 30 seconds at wallet setup and 5 seconds per transfer. The price of inattention is the wallet balance.