CZ blasts Etherscan for enabling address poisoning spam on block explorers
Former Binance CEO Changpeng “CZ” Zhao has called out Etherscan for displaying spam transactions tied to address poisoning scams, arguing that block explorers should be actively filtering such activity instead of exposing users to it.
The criticism surfaced after an Ethereum user, identified as Nima, reported receiving 89 email alerts in less than 30 minutes, all triggered by zero-value “poisoning” transactions following just two legitimate stablecoin transfers. The incident highlighted how aggressive and automated these scams have become – and how visible they are through popular blockchain explorers.
CZ: Block explorers must do more than just display data
In a post on X, CZ contrasted Etherscan’s approach with that of TrustWallet. According to him, TrustWallet already filters out these malicious zero-value transfers, while Etherscan continues to list them in user transaction histories. That, he argued, effectively normalizes dangerous noise that should never reach regular users.
He went further, stating that block explorers should not simply provide neutral access to all on-chain data, but should actively weed out clearly malicious transfers, especially when patterns are obvious and repeatable. For CZ, address poisoning spam falls squarely into that category and should be filtered at the interface level.
How address poisoning works – and why it’s effective
Address poisoning is a social engineering attack that exploits the way users interact with their own transaction history. Instead of hacking wallets or stealing keys, attackers flood a victim’s wallet history with transactions tied to deceptive addresses that closely resemble legitimate ones.
Technically, many of these attacks rely on the `transferFrom` function to initiate zero-value token transfers. Because every address starts with a 0-value approval by default, malicious actors can trigger transfer events without needing actual permission or funds. Those events then show up as if they were normal transfers, creating the illusion of genuine activity.
The twist comes from address spoofing: attackers design spoofed addresses that share the same beginning and ending characters as a real address the victim uses frequently. When the victim later scrolls through their history and copies an address from a previous transaction, they may accidentally choose the attacker’s lookalike address instead of the real one – sending funds directly to the scammer.
Nima’s case: 89 poisoning attempts in under half an hour
Nima’s experience underscores the scale at which these scams operate. After performing only two stablecoin transfers on Ethereum, his address was targeted by an automated campaign that generated 89 poisoning attempts in less than 30 minutes. Each attempt triggered a new alert, overwhelming his notifications and cluttering his transaction history.
He warned that “many will fall victim to this,” noting that the attacks were not only persistent, but also surgically timed to follow real on-chain activity. Whenever stablecoin or token movements are detected, bots can instantly begin targeting those addresses, allowing attackers to simultaneously harass thousands of users without any manual effort.
Etherscan’s response and the role of default settings
Etherscan has acknowledged the existence of such attacks and issued warnings explaining how address poisoning works and what users should watch out for. At the interface level, the platform hides zero-value transfers by default on Etherscan itself, reducing immediate exposure to spam.
However, related explorers such as BscScan and Basescan are more permissive: they still display zero-value transactions unless users manually enable a “hide 0 amount tx” filter. This discrepancy in default behavior leaves many users unnecessarily exposed. People who never tweak settings end up viewing a flood of irrelevant or malicious entries, increasing the odds of miscopying a poisoned address.
Critics argue that in security-sensitive environments, secure defaults matter more than optional filters. A single overlooked setting can be the difference between safety and a costly mistake.
Filtering vs. transparency: the ongoing debate
CZ’s remarks have reignited a long-standing debate about the responsibilities of block explorers. One camp insists that explorers must remain purely neutral data windows: they should display everything on-chain, with no opinionated filtering, and leave interpretation to users and third-party tools.
The opposing view, which CZ leans toward, is that user interfaces must evolve beyond raw transparency. With spam, scams and targeted attacks now forming a significant portion of on-chain events, interfaces that show “everything” can become weaponized against the very people who rely on them. From this perspective, hiding obvious attack patterns is not censorship, but basic user protection.
AI as a future filter for zero-value and micro transactions
CZ also suggested that filtering policies could become more complex as new forms of activity emerge – particularly micro and zero-value transactions between AI agents. In future machine-to-machine economies, vast networks of autonomous agents may exchange messages, proofs, or signals via zero-value transfers.
The challenge, he noted, will be distinguishing legitimate machine-generated traffic from spam and abuse. Hard filters that blindly block all zero-value transactions could interfere with real use cases. Instead, he proposed that AI itself could be employed to classify transfers and identify malicious patterns, allowing explorers or wallets to filter spam without harming utility.
Such systems could leverage behavioral analysis – for example, detecting synchronized bursts of lookalike addresses, repetitive patterns across many wallets, or improbable routing behaviors – to flag and suppress suspicious events before they ever reach end users.
Beyond address poisoning: routing and liquidity risks
Security concerns are not limited to address poisoning. Commentator Dr. Favezy highlighted a separate but equally alarming issue: poor routing decisions in decentralized finance. He cited a case where a swap originating from the 0x98 wallet effectively converted about 50 million dollars into just 36,000 dollars, implying catastrophic slippage due to inadequate route or liquidity selection.
This incident raised questions about how DeFi routing algorithms choose paths, which liquidity sources they prioritize, and how users are shielded from extreme execution risk. As trades grow in size and complexity, the cost of a single routing error can become enormous.
Dr. Favezy remarked that he hopes AI agents will eventually handle trade routing more intelligently – selecting the best liquidity sources, minimizing slippage, and avoiding situations where a poorly designed route can destroy nearly all value in a single transaction.
Why users are particularly vulnerable
Many crypto users rely on visual cues rather than full technical checks when moving funds. Long hexadecimal addresses are inherently hard to verify by eye, so people typically confirm only the first few and last few characters. Address poisoning exploits this exact behavior: attackers mimic those visible segments while changing the middle part that users rarely inspect.
In high-frequency trading or everyday use, people also tend to copy addresses from previous transactions rather than from secure address books or allowlists. When a block explorer or wallet interface presents both real and spoofed addresses side by side, the chances of picking the wrong one increase dramatically, especially if the interface does not clearly differentiate them.
Moreover, the psychological effect of seeing multiple “successful” past transfers to a spoofed address can create a false sense of trust, even if those transfers were all zero-value spam initiated by the attacker.
What wallets and explorers can do right now
While long-term solutions may involve AI and smarter infrastructure, there are several immediate steps interfaces can take to mitigate risk:
– Aggressive filtering of known poisoning patterns: Automatically hide zero-value transfers that match known exploit signatures, such as repeated zero-value `transferFrom` events following legitimate high-value transfers.
– Clear labeling of zero-value events: When shown, zero-amount transfers should be visually distinct and flagged as potential spam, not presented like normal transactions.
– Address verification tools: Wallets and explorers can prompt users to save “trusted addresses” and highlight mismatches when a new address only partially resembles a known one.
– Improved UX for copying addresses: Instead of encouraging copy-paste from generic history, interfaces can emphasize copying from verified address books, recent contacts, or signed requests.
– Contextual warnings: If an address appears for the first time immediately after a flurry of zero-value transactions, explorers could warn users before they interact with it.
These design decisions do not require censorship of on-chain data; they simply manage how that data is presented to protect users from foreseeable traps.
Education: the last line of defense
Despite technical safeguards, user education remains a critical defense. People need to understand that:
– Zero-value transfers can be malicious, not harmless clutter.
– Transaction history is not a trusted address book.
– Verifying the full address – or using QR codes, ENS-like names, or signed requests from trusted dApps – dramatically reduces risk.
– Sudden floods of “incoming” transactions after a large transfer are a red flag, not a sign of popularity or unexpected rewards.
Tool providers, exchanges and wallets can reinforce these lessons through in-app prompts, security checklists and default onboarding flows that explain both the convenience and the dangers of reusing historical addresses.
The growing importance of secure defaults
The confrontation between CZ and Etherscan reflects a broader shift in the crypto ecosystem. As on-chain activity grows more complex and adversarial, neutral tools are being pushed to become opinionated about safety. The difference between showing all possible data and curating what users see by default is no longer a minor UX choice – it directly impacts security.
Address poisoning attacks, like the one that hit Nima’s wallet with 89 spam attempts in under half an hour, demonstrate that attackers exploit not only protocol-level weaknesses, but also human habits and interface design. Whether through better filters, smarter AI, or more cautious defaults, the industry now faces mounting pressure to ensure that transparency does not come at the expense of user protection.