CZ blasts Etherscan for showing address‑poisoning spam, reigniting debate over explorer security defaults
Changpeng “CZ” Zhao has publicly criticized blockchain explorer Etherscan for continuing to display zero‑value “address poisoning” transactions, arguing that such spam should be filtered out automatically to protect users from sophisticated wallet‑draining scams.
The former Binance CEO’s comments follow a recent incident in which a user, identified as Nima, reported receiving 89 email alerts about poisoning attempts within less than half an hour – all triggered after making only two stablecoin transfers on Ethereum. Each alert corresponded to a zero‑value transaction designed solely to pollute his transaction history with lookalike addresses.
CZ: “Block explorers should not show these spam transactions”
Reacting to Nima’s case, CZ posted that block explorers ought to take a more proactive stance:
– Explorers, he argued, should completely filter out malicious zero‑value transfers used in address‑poisoning attacks.
– He highlighted that TrustWallet already hides these transactions by default, making the attack less visible – and therefore less effective – for its users.
– In contrast, Etherscan and related explorers still display zero‑value transfers, leaving transaction histories cluttered with spoofed entries that can later trick users.
According to CZ, “Block explorers should not show these spam transactions. Should be simple to filter them out completely.” He added that while such filtering might slightly affect certain advanced use cases – including potential future micro‑transactions between AI agents – more intelligent systems, including AI filters, could eventually distinguish legitimate zero‑value transfers from spam.
How address poisoning works
Address poisoning is a social‑engineering attack built on a technical quirk: on‑chain transparency and human error.
The attacker’s method typically looks like this:
1. Zero‑value transfers via `transferFrom`
Attackers use token contracts’ `transferFrom` function to send tokens with a value of zero to a victim’s address. Because every address essentially starts with a default approval of zero, the contract can still emit a transfer event, leaving a visible entry on the blockchain.
2. Polluting the transaction history
These zero‑value transfers appear in the victim’s transaction history, just like regular transfers. They do not move any real funds, but they create a record designed to be visually confusing.
3. Address spoofing
The attacker crafts addresses that mimic legitimate ones. Typically, they match the beginning and ending characters of a frequent recipient address. At a glance, the fake address looks identical to the genuine one, especially in interfaces that truncate the middle section.
4. Exploiting copy‑paste behavior
Later, when the victim wants to send funds again, they often scroll through past transactions and simply copy a “familiar” address from the history. If the poisoned address appears in that list, the victim might copy the attacker’s address instead of the real one – and unknowingly send funds to the attacker.
Nima’s experience underscores how industrialized this process has become: 89 poisoning attempts in roughly 30 minutes, all triggered automatically after just two legitimate transactions. The scale suggests that attackers are monitoring token movements on‑chain and firing off automated poisoning attacks against any address that shows stablecoin or token activity.
Explorer defaults: Etherscan vs BscScan vs TrustWallet
Developer Xeift clarified that Etherscan does, in fact, hide zero‑value transfers by default in some contexts. However, related block explorers such as BscScan and Basescan handle things differently:
– On Etherscan, many zero‑value transfers are hidden unless a user chooses to expand or change the view.
– On BscScan and Basescan, users must manually click a “hide 0 amount tx” button to remove such entries from view.
This difference in default behavior is not trivial. When zero‑value spam is visible by default, unsuspecting users are more likely to encounter poisoned addresses in their activity feed. The more frequently they see such entries, the higher the probability they will copy the wrong address at some point, especially under time pressure.
CZ’s core complaint is not that Etherscan lacks the capability to hide these transfers, but that the default user experience still exposes many wallets to transaction‑history pollution. In his view, explorers should treat poisoning transactions as a category of malicious spam and filter them out aggressively, rather than expecting users to toggle protections manually.
AI, micro‑transactions, and the edge case problem
CZ also acknowledged a more nuanced challenge: not every zero‑value transaction is inherently malicious. In the future, as AI agents and autonomous contracts interact more frequently, they may use zero‑value transfers for signaling, coordination, or off‑chain accounting, especially in high‑frequency, low‑value workflows.
He warned that blanket filtering might interfere with such legitimate micro‑transaction patterns. However, he suggested that by the time AI‑driven agent networks become widespread, developers could deploy more advanced, AI‑assisted filters capable of distinguishing:
– benign zero‑value interactions (for example, protocol pings or settlement markers), from
– clearly malicious patterns, such as clusters of spoofed transfers appearing moments after a user moves stablecoins.
This raises an emerging design question: how can explorers and wallets balance user safety today with the flexibility needed for future automated systems? For now, CZ’s stance leans heavily toward user protection, arguing that most human users are far more likely to be harmed by poisoning than to rely on legitimate zero‑value transfers.
Beyond poisoning: routing and liquidity risks in DeFi
Security researcher Dr. Favezy highlighted that address poisoning is just one of several systemic risks users face when interacting with on‑chain finance. He pointed to a recent incident involving a swap from the 0x98 wallet, in which about 50 million dollars’ worth of assets ended up effectively converted into only 36,000 dollars.
The incident raised red flags about:
– Route selection: Poorly configured or malicious smart contracts can route trades through illiquid pools or exploitative paths, causing catastrophic slippage.
– Liquidity sources: Choosing the wrong liquidity provider can mean that a large trade moves the market against the user, or interacts with manipulated pools.
Dr. Favezy expressed hope that AI agents of the future would be capable of choosing optimal routes and liquidity sources, reducing the chance of disastrous swaps. In his view, smart routing is as critical to user safety as filtering spam transactions, because both deal with user interfaces that mask complex on‑chain realities.
Why explorer design now shapes real financial risk
Block explorers were originally built as neutral, transparent windows into the blockchain. But as billions of dollars in value flow through on‑chain systems, the interface decisions they make – what to show by default, how to label data, which warnings to highlight – now have direct financial consequences.
The address‑poisoning debate illustrates this shift:
– Neutral display vs curated safety: If explorers show every event without context, users face information overload and are forced to interpret complex patterns themselves.
– Opinionated safety layers: If explorers begin filtering known attack patterns, they effectively act as security middleware, taking responsibility for “editorial” decisions about what users should or should not see.
CZ’s criticism pushes explorers toward the latter role. His position implies that transparency should not mean presenting raw, unfiltered data at the cost of predictable, recurring user harm – especially when certain attack patterns, like zero‑value spoofing, are relatively easy to identify programmatically.
Practical takeaways for everyday users
While explorer and wallet design continues to evolve, individual users can already reduce their exposure to address‑poisoning scams by changing a few habits:
1. Never rely solely on transaction history for addresses
Instead of copying from the last transaction on Etherscan or a wallet’s activity tab, use your saved address book, ENS name, or a verified contact list.
2. Check more than the first and last characters
Spoofed addresses typically match the start and end of the real address. Always verify several characters in the middle as well.
3. Use wallets or settings that hide zero‑value transactions
Where possible, enable options like “hide 0 amount tx” or use interfaces that automatically suppress obvious spam.
4. Be skeptical of sudden floods of activity
If you see an explosion of zero‑value token transfers after a legitimate transaction, treat it as a strong indicator that your address is being targeted.
5. Favor wallets with strong built‑in security heuristics
Wallets that flag known scams, phishing tokens, or suspicious contract interactions provide an extra layer of defense beyond what explorers offer.
What explorers can realistically do today
Technically, filtering address‑poisoning spam is well within reach for most explorer platforms. They can, for example:
– Classify zero‑value transfers using heuristics such as timing (immediately after large transfers), repetition (many to the same address within minutes), and address patterns (similar prefix/suffix to recent counterparties).
– Group obvious spam into a collapsible section with a prominent warning banner instead of mixing it into the main activity feed.
– Maintain a reputation system for addresses and contracts that frequently generate poisoning transactions, allowing users to filter them more aggressively by default.
– Offer power users an “unfiltered view” while keeping a safer, curated default for the majority.
Such measures would preserve transparency for advanced users who need the raw data, while significantly reducing the risk that everyday users will fall prey to address poisoning.
The road ahead: AI‑assisted security layers
The intersection of CZ’s comments and Dr. Favezy’s concerns points toward the same future: security layers increasingly handled by intelligent agents rather than by human vigilance alone.
In a world where:
– AI agents manage portfolios, execute trades, and pay for services autonomously, and
– users interact less directly with raw blockchain data,
the burden of distinguishing legitimate from malicious on‑chain activity will likely shift further toward automated systems. These agents will need to:
– filter out obvious poisoning and phishing attempts,
– route trades through optimal and trustworthy liquidity paths, and
– adapt quickly as attackers discover new ways to exploit public transaction histories.
Until that future is fully realized, though, the responsibility is shared: explorers must adopt smarter defaults, wallets must incorporate protective heuristics, and users must resist the temptation to blindly trust their transaction histories.
Nima’s experience – 89 poisoning attempts in half an hour, triggered by just two stablecoin transfers – is a stark reminder that on‑chain transparency cuts both ways. The same visibility that empowers users and auditors also gives attackers a real‑time map of where to strike next. How quickly explorers like Etherscan respond to CZ’s call for stricter spam filtering will be an important test of how the industry balances openness with user protection.