Address poisoning and pre-send verification: per-chain anatomy + the 5-second check against the 2026 attack surge

Ethereum's Fusaka upgrade (2025-12-03) cut blob/calldata gas costs roughly 6x and removed the economic brake on mass dust distribution — daily poisoning attempts on Ethereum jumped from 628K in November 2025 to 3.4M by January 2026 (BeInCrypto, sampled 2026-06-26). The single rule that works across TRC20, ERC20, Solana, and Bitcoin: compare the 6 characters in the MIDDLE of the destination address against a source-of-truth you did NOT get from your wallet history. Vanity-address brute-force can cheaply match the first 5-6 and last 4-6 characters of any target address — the December 2025 attacker matched 5 in front and 4 behind on the $50M USDT loss (Coindesk, 2025-12-20, sampled 2026-06-26). The middle is the part they cannot forge.

The 5-second pre-send check:

1. Middle 6 characters match a source you obtained outside your wallet history (counterparty signed message, official receive page, pre-saved whitelist).
2. Hardware wallet on-device display shows the same address as the host (Trezor and Ledger official guidance, sampled 2026-06-26).
3. First-corridor test of $20-50 before any send over a few thousand dollars (Crypto.com, Kraken, Effective Currency convergence, sampled 2026-06-26).

The remainder of this guide explains why each step matters and what differs between chains. If you read nothing else, the 5-second rule above is enough.

Address poisoning is not one attack. It is three related techniques that all converge on the same outcome: you copy a destination address from somewhere you trust, believing it is your counterparty, when it is actually an attacker's wallet built to look identical.

Mechanism 1 — Zero-value transferFrom poisoning (ERC-20 only). The ERC-20 standard does not require a non-zero allowance to call transferFrom(victim, attacker, 0). An attacker calls this on the USDT contract with the victim as source and a vanity-generated lookalike address as destination. The transaction succeeds, emits a real Transfer(victim -> lookalike, 0) event, costs the victim no gas, and block explorers index it as an outbound transfer from the victim's wallet (OpenZeppelin issue 3931, sampled 2026-06-26). Days later the victim sees the 'transfer' in history and copies the destination thinking it is their OTC desk. Named incident: January 2026, 4,556 ETH (~$12.4M) lost to a lookalike address 0x6d9052b2...e592e48 of an OTC deposit address pattern (the victim's intended counterparty was reportedly using a Galaxy Digital OTC address per Cyvers; Galaxy Digital itself was not the compromised or victim party) after 37 hours of systematic dusting (Blockchain.news / Cyvers, sampled 2026-06-26).

Mechanism 2 — Dust / dust-back poisoning (works on chains without the zero-value loophole). Attacker sends a real but tiny transfer — fractions of a cent in stablecoin or native — from a vanity-generated lookalike INTO the victim's wallet. The inbound transaction shows the lookalike in the victim's receive history. Named incident: Coin Metrics Issue 349 documents one wallet (0x455bf23ea7575a537b6374953fa71b5f3653272c) sending ~3 million dust transfers to over 1 million victim addresses for a total stablecoin value of just $5,175 — fractions of a cent per victim, but enough surface to plant the lookalike (Coin Metrics, sampled 2026-06-26).

Mechanism 3 — Pure vanity-generated lookalike address. The shared prerequisite for both attacks above. Profanity-style or modern GPU-accelerated generators derive a private key whose address matches the target's first N and last N characters within a feasible compute budget at consumer hardware costs (per CertiK / Halborn published analyses). Wallet UIs that abbreviate as 0xABCD...WXYZ show exactly the cheap-to-forge segments and hide the expensive ones. Named incident: December 2025, $50M USDT. Victim sent a 50 USDT test successfully, attacker dust-poisoned within minutes from a vanity-generated lookalike matching the first 5 and last 4 characters, victim copied the spoof from history 26 minutes after the test and sent ~$50M. Funds were swapped to ~16,690 ETH and ~16,680 ETH deposited into Tornado Cash in under 30 minutes (Coindesk, 2025-12-20, sampled 2026-06-26).

The attack volume in late 2025 and early 2026 is not a marketing scare. Independent sources converge on the same trend, and the catalyst is identifiable: Ethereum's Fusaka upgrade activated 2025-12-03 and cut blob/calldata gas costs roughly 6x, removing the economic brake on mass dust distribution (The Defiant, sampled 2026-06-26).

Honest caveat: where aggregated derivative-coverage figures (e.g. a circulated $83.8M aggregate attributed to Chainalysis) appear in third-party write-ups, they were not directly confirmed in the Chainalysis report at sample time and should be treated as derivative until cross-checked.

One framing detail that matters: Blockaid's 1-in-200 success rate means the absolute number of victims is far smaller than the attempt count suggests, but the average loss per successful drain is large enough that aggregate losses are still material — and the success rate goes up sharply on high-value transfers because attackers concentrate dust on wallets they have profiled as whales.

The reason every chain has different poisoning vulnerability is that every chain has different address-format guarantees. Here is what is actually in your address, what gets checked, and what happens when one character is wrong.

TRC20 (Tron) — 34 characters, starts with T

[0x41 prefix : 1 byte]
[20-byte payload = last 20 bytes of Keccak-256(secp256k1 pubkey)]
[4-byte checksum = first 4 bytes of double-SHA-256(prefix||payload)]
= 25 bytes total -> Base58 encode -> 34 visible chars (leading T)

Encoding: Base58Check (Tron Protocol documentation, sampled 2026-06-26). Why every Tron address starts with T: 0x41 forces the leading character into the T range mathematically. What a single-character flip does: cascades through Base58 decoding and breaks the 4-byte tail checksum. Collision probability ~1 in 4 billion. Any compliant wallet refuses to broadcast. Poisoning vulnerability: not from typo — from vanity-generated lookalikes plus dust-based history poisoning (Tron USDT has been a primary poisoning target since 2022).

ERC20 (Ethereum and all EVM chains) — 42 characters, 0x + 40 hex

[0x prefix]
[20 raw bytes = last 20 bytes of Keccak-256(uncompressed secp256k1 pubkey)]
-> 40 hex chars; EIP-55 overlays case as optional checksum
EIP-55 rule: for each hex char of lowercased addr,
  if the corresponding nibble of Keccak-256(lowercased addr w/o 0x) >= 8
  then UPPERCASE that char

EIP-55 specification, sampled 2026-06-26. Yields ~15 effective check bits. Random-typo miss rate ~0.0247%. What a single-character flip does: changes content, breaks case pattern, EIP-55-aware wallets warn or reject. EIP-1191 (ERC-1191) extends EIP-55 with chain ID. Critical caveat: case-insensitive all-lowercase addresses bypass EIP-55 entirely. Older clients accept them silently. Poisoning vulnerability: highest practical impact because EVM is where the zero-value transferFrom permissive semantics live.

Solana — 32-44 Base58 characters, no prefix

[32 raw bytes = full Ed25519 public key]
-> Base58 (NOT Base58Check) -> 32-44 visible chars
no version byte, no checksum byte, no error-correcting code

Encoding: Base58 (not Base58Check) of the raw Ed25519 public key (Coin.space documentation, sampled 2026-06-26). Error detection: none. Base58's alphabet eliminates visually ambiguous characters (no 0/O/I/l), but that is a typo-prevention property, not a checksum. What a single-character flip does: produces a different but still valid-looking 32-byte value. The runtime accepts it. Funds vanish into an address with no known private key — or, as has been documented, attackers pre-generate vanity addresses resembling common recipients so a typo can route to an attacker-controlled address rather than a dead one. Poisoning vulnerability: structurally the most vulnerable of the four. Hardware-wallet on-device verification matters more on Solana than anywhere else.

Bitcoin — four formats coexisting

P2PKH  (prefix 1):    [0x00 ver][RIPEMD160(SHA256(pubkey)) : 20B][4B checksum]  -> Base58Check
P2SH   (prefix 3):    [0x05 ver][20B script hash][4B checksum]                  -> Base58Check
Bech32 (prefix bc1q): HRP "bc" + "1" + [witness ver 0] + [20B or 32B program]
                      + [6-char BCH polymod checksum]  (BIP173)
Bech32m(prefix bc1p): same as Bech32 but polymod constant = 0x2bc830a3 (BIP350)
                      fixes a known Bech32 mutation flaw

What a single-character flip does: all four formats are checksummed. Single-char flip is virtually guaranteed to fail. Bech32 and Bech32m additionally guarantee detection of ALL up to 4-character substitutions for addresses up to 89 chars and can localize the wrong character (BIP173, sampled 2026-06-26). Poisoning vulnerability: typo risk is the lowest of the four chains; lookalike poisoning still applies because checksums do not verify ownership intent.

Each step is a do-this-now action. Run them in order. The full sequence takes under two minutes on a wallet you have used before, longer on a first-time send.

1. Source the address from outside wallet history: get the destination address from a place that is not your wallet's transaction history or autocomplete dropdown. Acceptable sources: counterparty's signed message, exchange's official deposit page reached via a manually-typed bookmark, a whitelist you maintain in a separate signed document. Unacceptable: anything you 'know' you 'sent to before' (this is exactly what the December 2025 victim believed).

2. Verify the middle 6 characters: read the 6 characters in the visual middle of the address. Compare to the source of truth. Brute-force vanity generation can cheaply match 5-6 in front and 4-6 behind; matching middle simultaneously is computationally infeasible at any realistic budget. MetaMask now expands the abbreviated display specifically to show middle characters (MetaMask Support, sampled 2026-06-26).

3. Bookmark the real domain: navigate to the receiving exchange or service via a bookmark you saved manually, not via search results. Phishing domains are a separate but adjacent attack vector that produces the same outcome — a wrong destination address.

4. Re-check the clipboard after paste: clipboard-hijacker ('clipper') malware silently replaces the address in your clipboard between copy and paste. After pasting, look at the field and re-verify the middle characters. Do not assume the paste matches the copy.

5. Confirm the address on the hardware-wallet screen: if you have a Trezor or Ledger, verify the address on the device screen, not the host screen. Trezor's guidance: 'Carefully compare the receive address you copy & paste with the one shown on your Trezor device. If they are different, your computer may be infected by malware.' Ledger's guidance is parallel — verify every character, not just first or last few (Trezor and Ledger support docs, sampled 2026-06-26).

6. Send a first-corridor test of $20-50: for any send over a few thousand dollars, or any first-time corridor (new chain pair, new counterparty), send a $20-50 test, wait for on-chain confirmation, verify the destination credited the intended account, then send the remainder. Crypto.com, Kraken, Effective Currency, and Coinbase all converge on this practice (Effective Currency Test Transfers, sampled 2026-06-26). Caveat: a successful test does NOT validate the address against poisoning — the December 2025 victim sent a 50 USDT test successfully and was poisoned in the 26 minutes between test and full send.

7. Confirm refundTo is complete on cross-chain swaps: if you are using a swap router or aggregator, fill the refund address completely, on the correct chain. Guide #1 covers the refundTo failure modes; the short version is that an empty or wrong refundTo field can route a failed swap's funds into an inaccessible address even when the destination address was correct.

The UpSwap (99b.io) widget has, by design, no surface that history-based poisoning can plant lookalike addresses into. Verified in source on 2026-06-26 across SwapWidget.tsx, Step1Quote.tsx, Step2Recipient.tsx, Step3Send.tsx, Step4Complete.tsx, and stores/swap.ts:

• No saved address book. The recipient field in src/components/steps/Step2Recipient.tsx has one state (recipient: string) and one paste handler. No autocomplete suggestions, no dropdown of past recipients, no contacts list.
• No autocomplete from past sends. The component re-renders the recipient input as empty on each new swap session unless the user manually persists the field through their own clipboard.
• No inbound transaction history. The widget is non-custodial and per-session: no wallet connect, no on-chain history fetch, no Transfer event indexing, no incoming-tx panel. There is no UI surface where a poisoned dust transaction or zero-value transferFrom event could appear and be misread.
• Persistence is bounded. src/stores/swap.ts persists ONLY recentOrderIds (last 5 order IDs for status tracking) via Zustand persist with partialize: (s) => ({ recentOrderIds: s.recentOrderIds }). Order IDs are opaque vendor references, NOT user addresses. The jurisdiction modal persists only a single acceptance flag.
• Format-level validation via src/lib/validation -> validateAddress with chain-specific validators (EVM, Bitcoin, Solana, Tron, TON, Sui, NEAR, Zcash, Cardano, Stellar, XRP, Dogecoin, Litecoin, BCH, and others across the 24+ supported chains). Invalid format blocks the Next button via disabled={!validation?.valid}. This catches structural typos against EIP-55, Base58Check, and Bech32 polymod — but it cannot catch Solana single-character flips (no checksum) or EIP-55-stripped lowercase ETH addresses.

The competitive framing is structural, not feature-based. Wallets like MetaMask, Trust Wallet, Trezor Suite, and Ledger Live need a history-based-poisoning detection layer because they have address history. UpSwap does not need that layer for the history-based-poisoning class because it does not have the surface. This is the same kind of structural property as a hardware wallet not having a software-signing path — a design pattern, not a claim of equivalent overall safety, and a hardware wallet structurally cannot sign without device confirmation in the same way.

Per-pair landing pages (covering 24+ chains, 111+ tokens, 166 combinations) SSR-inject a chain and token preset, which controls the fromChain/toChain selection only. The recipient address is still manually entered each session. The pre-send checklist in the section above applies on every send regardless of which surface you use.

The four incidents below cover the design space: the recent record loss, the recent whale loss, the historical record loss, and the historical inflection that industrialized the toolchain.

What each one teaches: the December 2025 case proves a successful test transfer does not validate the address against poisoning (the test went to the real address, the $50M went to a different address copied from history 26 minutes later). The January 2026 case proves systematic dusting over weeks is the new norm — 37 hours minimum between first dust and exploit. The May 2024 case proves the technique scales to nine figures and that public negotiation occasionally recovers funds (rarely). The September 2022 Profanity case is the inflection point: from that date forward, vanity address generation at scale became cheap enough that poisoning could move from targeted to industrial.

One last question before any large send: where did this address come from, and can I verify it from a different source than where I copied it? If the answer is 'from my wallet history' or 'from a chat that might be hijacked', stop and re-verify out-of-band. The 5-second pre-send rule at the top of this guide is the operational form of that question — built for situations where you do not have time to think about it. For pre-send alerts and chain-specific advisories before they reach exchange status pages, contact UpSwap support at @upswapservice on Telegram.