There is a category of loss that requires no phishing site, no seed phrase, no malicious signature request, and no exploited contract. It requires only that the string of characters you paste into the recipient field is not the one you meant. This is the least glamorous attack in the space and one of the most reliably profitable, precisely because everyone reading this already knows about it and pastes addresses anyway. The key is not the target. The clipboard is.

The Standard

There is no EIP that fixes this, because this is not a protocol bug. It is an operational security failure, and the right reference framework is MITRE ATT&CK, which catalogs adversary behavior in terms of tactics and techniques rather than vulnerabilities.

Two techniques matter here. The first is Clipboard Data (T1115), listed under the Collection tactic. ATT&CK describes adversaries who “collect data stored in the clipboard from users copying information within or between applications.” In the general enterprise context this is about scraping secrets someone copied. In crypto it mutates into something worse: the malware does not merely read the clipboard, it writes to it. A background process watches for a string matching the shape of a wallet address (a regex over 0x followed by forty hex characters, or the base58 and bech32 patterns of other chains) and silently substitutes an attacker-controlled address of the same shape. You copy the correct destination. You paste a different one.

The second is best understood through the Initial Access and Execution tactics, because clipboard hijackers are just payloads, and payloads need delivery. User Execution (T1204) covers the moment a user runs a malicious file or installer. Supply Chain Compromise (T1195), specifically compromise of software dependencies, covers the case where the clipboard watcher arrives inside a package you trusted. The clipboard is the objective; the rest of ATT&CK is how the watcher gets onto the machine that owns the clipboard.

Address poisoning is a variant that does not require any malware at all, and ATT&CK frames it as social engineering under the Impersonation umbrella. The attacker generates a vanity address whose first and last few characters match one you have recently transacted with, then sends you a dust transaction (or a zero-value transfer, or a fake token event) from that lookalike. It appears in your history. Later, when you go to repeat a payment, you copy the address from your own transaction list, glance at the ends, and send funds to the impersonator. No code ran on your machine. Your own habit of truncated verification was the exploit.

The standard, plainly stated: the address you authorize must be the address you intend, and neither your clipboard nor your transaction history is a trustworthy source of truth for what you intended.

Where It Breaks Down

The failure is almost never technical sophistication. It is the interaction between human perception and interface design.

Truncated address display. Every block explorer, every wallet, and every dApp renders addresses as 0x1234...abcd. This is a usability decision that trained an entire industry to verify eight characters out of forty. Vanity address generation against eight characters is trivial on commodity GPUs. Matching the first four and last four is cheap enough that address poisoning is run as a spray campaign against millions of addresses. The interface itself taught the victim to check exactly the part the attacker controls.

Clipboard as unvalidated input. Wallets accept a pasted string and, at best, run a checksum. EIP-55 mixed-case checksums catch typos and corruption, but a clipboard hijacker does not produce a corrupted address. It produces a valid attacker address with a correct checksum. The checksum was designed to detect accidental error, not adversarial substitution, and it succeeds perfectly at the job it was given while doing nothing for the job you needed.

Zero-value and fake-token poisoning. On EVM chains, the Transfer event in ERC-20 is emitted by the contract, and a malicious token can emit a Transfer event claiming a transfer from an address you control to the attacker’s lookalike, or fabricate an inbound transfer that never moved real value. Wallets and explorers that build your “activity” view from raw event logs will happily display these fabrications as real history. Your transaction list is not a ledger of things you did. It is a rendering of events a contract chose to emit, and contracts can lie.

Address book decay. People maintain address books but rarely audit them. A saved contact edited by malware, or seeded during a compromised session, persists indefinitely. You verified it once, months ago, and have trusted it on faith ever since.

Hardware wallet theater. The hardware wallet displays the destination address on its trusted screen, which is the entire point of the device. But it displays whatever the host software passed to it, and users approve after checking the same eight characters. The secure element faithfully signs a transaction to an address the human never actually read. The trust boundary works. The human standing at it does not.

QR codes and pay-URIs. Copying is not the only vector. A swapped QR image or a manipulated ethereum: URI (EIP-681) delivers the same substitution through a channel people scrutinize even less than clipboard text.

Doing It Right

Verify the full address, or verify none of it. Checking the middle. Checking four characters from the front and four from the back is security theater with a completion animation. If you are going to verify, read the entire string, or at minimum a contiguous run of ten or more characters from the interior where vanity generation gets exponentially expensive. Better: compare against a known-good source character by character, ideally out loud or against a printed reference.

Never source an address from your own history. Transaction lists are populated by attacker-influenceable event logs. Maintain addresses in a dedicated, audited allowlist that you control, and paste from there, not from the explorer view of your past activity.

Use allowlisted withdrawal addresses. Exchanges and institutional custody offer address allowlisting, often with a time delay before a new address becomes usable. Turn it on. The delay is not friction, it is the window in which a substitution becomes visible before it becomes final.

Send a probe transaction for anything material. For large transfers, send a trivial amount first, confirm it arrived at the intended party through an out-of-band channel, and only then send the rest. Yes, it costs a second fee. Compare that to the alternative.

Builders: stop truncating in security-critical contexts. For a UI that displays where funds are going, render the full address, or make the full address one deliberate action away, and consider surfacing the middle bytes rather than only the ends. Detect and flag inbound zero-value transfers and unrecognized token Transfer events rather than silently folding them into activity history. Warn when a paste target closely resembles a poisoning pattern against a recent counterparty.

Isolate the signing environment. A machine that touches material value should not also be the machine that installs random dependencies, runs unvetted binaries, or executes downloaded scripts. This is the ATT&CK T1204 and T1195 mitigation in operational terms: reduce the surface on which a clipboard watcher can ever land.

Prefer name resolution with on-chain verification. ENS and similar systems move the human-facing identifier off the raw hex, but resolve the name yourself and confirm the resolved target, because the resolution layer is one more thing that can be spoofed if you take it on faith.

The Bottom Line

The clipboard attack survives every cryptographic advance we ship because it does not attack cryptography. It attacks the two inches between your intent and your fingers, and that gap has not been patched in the entire history of computing. You will read this, nod, and paste an address checking only the first and last four characters, because the interface trained you to and the deadline is now. The attacker is counting on exactly that, and the attacker is usually right.

Verify the whole string, or admit you are just guessing with extra steps.

More: Issues · Field Notes · RTFM