CZ: Block Explorers Should Filter Spam Transactions to Reduce Address Poisoning Risk
CZ: Block Explorers Should Filter Spam Transactions to Reduce Address Poisoning Risk
Address poisoning ( also called transaction history poisoning ) has quietly become one of the most persistent “ UI-layer ” threats across Ethereum and other EVM networks. Attackers don’t need to break cryptography or exploit smart contracts; they exploit human habits—especially the tendency to copy an address from recent transaction history after only checking the first and last few characters. For a clear walkthrough of how these scams work in practice, see Etherscan’s explainer on address poisoning attacks. (info.etherscan.com)
In early 2026, the scale of these campaigns is difficult to ignore. A Carnegie Mellon University CyLab study ( based on multi-year on-chain data ) documented hundreds of millions of poisoning attempts and emphasized that the root cause is usability: long hexadecimal addresses, truncation in interfaces, and unsafe copy-paste behaviors. (cylab.cmu.edu)
Against this backdrop, CZ recently reignited discussion around a simple idea: stop surfacing obvious spam transfers in the first place. While much of the public conversation focuses on wallet apps, the same UX principle applies to block explorers—because explorers are where users, support teams, analysts, and even wallet UIs often “ read ” transaction history.
Why address poisoning keeps working
Most address poisoning attacks follow a repeatable pattern:
- A scammer generates a lookalike address ( often matching the beginning and end of a real counterparty address ).
- They send a dust transfer ( tiny value, sometimes even a token event that looks like a transfer ) so the victim’s history becomes “ polluted ”.
- Later, the victim copies the wrong address from history and sends a real payment to the attacker.
Etherscan notes that these attacks are not limited to any single interface; they can appear across explorers, wallets, and other Web3 frontends. (info.etherscan.com)
CZ’s point: filtering spam is a UX fix, not a protocol change
CZ’s core argument is straightforward: if an interface can identify a poisoning pattern ( or a known poison address ), it should warn or block—and if a transaction is effectively worthless spam, it should be hidden by default to reduce the chance of a copy-paste mistake. Reports discussing his comments highlight two practical directions:
- Detect and block known poison destinations ( a “ blockchain query ” plus threat intelligence )
- Don’t display negligible-value spam transactions in history views (financefeeds.com)
This is where block explorers become part of the solution: many wallets and portfolio tools rely on explorer APIs and explorer-style activity feeds. If explorers present spam transfers with the same visual weight as real payments, they unintentionally amplify the attacker’s “ UI footprint. ”
Block explorers have filtered spam before—this is not new
The industry has already experimented with “ visibility controls ” at the explorer layer. For example, BlockBeats previously reported that Etherscan updated its default view to not display valueless token transfers as a response to poisoning-style scams, while still allowing users to re-enable visibility in settings. (theblockbeats.info)
This is an important precedent: filtering at the UI level does not change on-chain truth. It changes what is emphasized, what is collapsed, and what requires an extra click—exactly the kind of friction that can prevent costly mistakes.
The hard part: filtering without harming legitimate use cases
Critics of aggressive filtering often raise a valid concern: what if “ small transfers ” are legitimate?
In 2025–2026, this question matters more because the industry is trending toward:
- Lower fees and higher throughput on L2s and high-performance chains
- On-chain automation ( bots, keepers, intent solvers )
- AI agents that may rely on micro-payments or high-frequency settlement
CZ acknowledged a version of this tradeoff: if the future includes AI-to-AI microtransactions, blanket filtering based only on value could hide real activity—yet the same AI capabilities can also be used to classify spam more accurately when that future arrives ( i.e., smarter detection rather than simple thresholds ).
A reasonable middle ground for explorers is:
- Default-hide “ likely spam ”, not “ low value ”
- Provide a one-click “ Show hidden activity ” toggle
- Offer explainable labels ( why something was hidden: 0-value, spoofed token pattern, known poisoning cluster, high similarity score, etc. )
- Keep a raw logs / events view for power users and auditors
This preserves transparency while protecting the majority of users from the most common failure mode: copying the wrong address from a polluted feed.
What explorers and wallets should do ( practical checklist )
1) Stop truncating addresses by default in high-risk contexts
If an interface must truncate, it should support tap-to-expand, highlight differences, and show stable visual cues ( identicons, name tags, contact labels ).
2) Add “ similarity warnings ” at send time
The safest moment to intervene is before signing. If the destination is very similar to a recently used address ( but not identical ), the UI should force a deliberate confirmation.
3) Treat spam visibility as a security setting
“ Hide suspected spam ” should be enabled by default, with clear controls to review hidden items.
4) Use checksums everywhere possible
For Ethereum-style addresses, EIP-55 mixed-case checksum encoding helps detect typos and reduces certain classes of copy errors. See the ERC-55 ( EIP-55 ) specification. (eips-wg.github.io)
5) Maintain a local address book ( and encourage allowlists )
A saved contact entry is harder to poison than “ whatever appears last in history. ”
What users can do today to reduce address poisoning risk
Even if explorers and wallets improve filtering, users should assume poisoning attempts will continue—because sending dust is cheap, and attackers automate at scale. Here are habits that meaningfully reduce risk:
- Never copy a recipient address from transaction history unless you fully verify it.
- For large transfers, send a small test transaction first.
- Prefer trusted address sources ( your own address book, verified counterparties, QR codes from an authenticated channel ).
- Manually compare more than the first / last 4 characters—check the middle segment too.
- Use a signing workflow that forces you to verify the full address on a trusted display.
This last point is where a hardware wallet meaningfully changes the risk profile.
Where OneKey fits in this security model
Address poisoning is fundamentally a UI deception problem, so the most robust defense is to separate “ what you see on a potentially compromised screen ” from “ what you approve on a trusted screen. ”
A hardware wallet like OneKey helps by keeping private keys offline and requiring transaction confirmation on-device—so when your browser, dApp, or transaction history is polluted by spam transfers, you still have an opportunity to verify the recipient address and amount on the hardware screen before signing.
If you frequently interact with DeFi, send stablecoins, or manage operational wallets, combining:
- explorer / wallet-level spam filtering, and
- hardware-based on-device verification
is one of the most practical ways to reduce losses from address poisoning without sacrificing the self-custody benefits of public blockchains.
Further reading
- Etherscan: What is an address poisoning attack?
- CMU CyLab: Study on blockchain address poisoning at scale (cylab.cmu.edu)
- Ethereum standard: ERC-55 ( EIP-55 ) checksum addresses (eips-wg.github.io)
