When hackers target your "habits," how can you reduce the risk of address poisoning at the source?

In the Web3 world, many people's first thought about security is protecting private keys, seed phrases, and authorization permissions.

Of course these are important, but in actual use, there is another type of risk that doesn't stem from private key leaks or rely on contract vulnerabilities. It occurs during a seemingly ordinary operation: copying an address.

Address poisoning exploits exactly this. It doesn't profit by cracking systems, but through camouflage, interference, and deception, tricking users into transferring assets to the wrong address during what looks like a normal transaction process.

What makes this type of attack tricky isn't the technical difficulty, but that it precisely targets users' visual habits and path dependency in daily operations.

What is Address Poisoning?

Address poisoning refers to attackers generating a fake address that visually resembles a user's commonly used address, then mixing this address into the user's transaction history through zero-amount or micro-transactions.

When the user needs to transfer funds next time, if they "conveniently copy" the address from their transaction history without verifying every single character, they might mistakenly send assets to the attacker's prepared fake address.

Such attacks are not uncommon. Over the past two years, several public cases on-chain have demonstrated that address poisoning can cause real losses, and even habitual actions like "making a small test transfer before a formal one" may not be sufficient to avoid the risk entirely.

More critically, the Fusaka upgrade has significantly reduced gas fees, indirectly lowering the marginal cost of address poisoning attacks. According to Blockaid statistics, there were 3.4 million on-chain poisoning attempts in January 2026, a 5.5-fold increase compared to 628,000 in November last year, indicating an explosive growth in poisoning frequency.

Why is Address Poisoning So Easy to Fall For?

In principle, address poisoning isn't complex; what makes it hard to defend against is that it hits several natural weaknesses in user operations.

1. Addresses Are Not Meant for Manual Verification

An on-chain address typically consists of 42 characters. For most users, verifying every single character of a complete address is not a realistic, stable, or sustainable operation. Often, people just check the first few and last few characters, confirm it "looks right," and proceed. Attackers design their camouflage precisely around this habit.

2. Malicious Transactions Blend into Normal Transaction Noise

Address poisoning transactions often occur with extremely small amounts or even zero amounts, appearing no different from regular on-chain transfers. Once mixed into real billing records, it's very difficult for users to quickly distinguish between legitimate transactions and deliberately placed interference items just by looking at a long list of history.

3. Traditional Warnings Often Come Too Late

Many security reminders appear just before "confirming the transfer." But for address poisoning, the truly critical risk point usually occurs earlier — when the user decides to copy an address from their transaction history.

If risk identification and warnings only appear at the final step, the erroneous operational path has already been formed.

Facing Address Poisoning, Wallets Need More Than Just "Reminders"

The unique aspect of this risk is that it can't be completely solved just by users paying closer attention or being more cautious.

As the entry point for users interacting with the chain, wallets should assume more responsibility for pre-judgment and proactive protection, intercepting risks at earlier touchpoints rather than placing all the burden on the users themselves.

In imToken 2.19.0, we have further upgraded our security risk control capabilities specifically for address poisoning risks. The overall approach isn't just adding a single prompt, but positioning identification, filtering, alerts, and verification earlier in the user's actual operational flow.

Three Layers of Defense Against Address Poisoning

1. Hiding High-Risk Transactions to Reduce Bill Contamination

To address the issue of malicious addresses contaminating billing records with micro or zero-amount transactions, the new version enables the "Hide Risky Transactions" feature by default.

When the system identifies a high-risk poisoning transaction, it prioritizes filtering it from transaction records and related notifications, minimizing the chance of such distracting information entering the user's view.

The purpose is not just to make the interface cleaner, but more importantly, to reduce the probability of users accidentally copying a risky address from their history at the source.

2. Moving the Warning Forward to the Moment of Copying

The critical breakthrough point for address poisoning is not the transfer button itself, but the step of copying the address.

Therefore, when a user performs a copy operation from the transaction details page, the system adds a more explicit interactive reminder, guiding the user to perform a more complete verification of the address instead of relying only on the first and last characters.

Compared to only providing warnings before a transfer, this approach is closer to the node where the real risk occurs and is more effective at breaking the habitual "copy without thinking" path.

3. Continuously Marking Risks Across Key Pathways

Besides the transaction list and copy scenarios, the system also provides clear indicators and corresponding warnings for suspected risky addresses at key touchpoints like transaction details and pre-transfer verification.

The goal is not to increase annoyance, but to provide more timely and consistent risk feedback before the user takes the next step.

Technical Insight: Why Address Poisoning Requires "Dynamic Perception" Risk Control

Address poisoning doesn't exploit on-chain protocol vulnerabilities, but rather user operational habits and visual inertia. Attackers create fake addresses highly similar to real ones, then mix them into transaction histories via micro or zero-value transactions, tricking users into copying and transferring to the wrong address subsequently.

One key reason it's difficult to manage is that from the perspective of on-chain execution results, these transactions often appear "normal." There are no obvious protocol anomalies or traditional attack signatures. Therefore, relying solely on static blacklists or post-event warnings is often insufficient to cover the real risk.

imToken's response to this type of risk is not simply to affix a permanent "good" or "bad" label to an address. Instead, at key touchpoints like when users refresh transaction records, view details, copy addresses, or initiate transfers, the system dynamically identifies suspicious transactions by combining real-time on-chain data with the current interaction context. This drives the client to perform actions such as filtering, marking, strong alerting, or pre-verification.

Risk Identification Isn't Just About "Looks Similar"

The key to identifying poisoning isn't just string similarity, but how to combine multiple types of evidence for judgment in a noisy environment. Current identification logic primarily considers several types of signals:

Similarity Evidence

For an attack to succeed, the fake address first needs to visually "look similar enough." The system quantifies the structural characteristics of address camouflage to identify such high-similarity risks.

Cost Pattern Evidence

To spread at low cost, address poisoning often exhibits specific amount distributions and transaction patterns. The amount signal alone isn't decisive, but it can be used with other evidence to reduce misjudgment from a single factor.

Behavioral Timing Evidence

Some poisoning transactions closely follow a user's real transfer, attempting to leverage the user's post-operation inertia to quickly insert the fake address into the transaction record. The system evaluates such behavior comprehensively within specific time windows and contexts.

Why Use Unified Risk Decisions?

A single signal is often insufficient for high-confidence risk assessment. Therefore, the system comprehensively evaluates multiple types of evidence, outputs a unified risk result, and maps it to handling strategies at different touchpoints.

This design brings three main benefits:

• Reduced False Positive Noise: Weak signals do not trigger high-level actions on their own.
• Consistent User Experience: The same transaction receives a consistent risk assessment across different pages.
• Supports Review and Optimization: Each hit can trace back the basis for judgment, facilitating continuous iteration.

For non-custodial wallets, this type of risk control is particularly challenging.

Because address poisoning exploits user behavioral paths, not obvious on-chain anomalies; attack methods continuously change with different chains, assets, rhythms, and camouflage techniques. Without centralized control points, the effectiveness of protection relies more on the synergy between identification quality, product touchpoint design, and strategy iteration capabilities.

Therefore, imToken develops this capability as a continuously evolvable security engineering system, supporting strategy updates, version management, and effect observation and review, allowing defense capabilities to keep pace with evolving attack methods.

How to Upgrade Your Protection

If you are already using imToken, we recommend upgrading to version 2.19.0 as soon as possible.

To address address poisoning risks, the new version has the corresponding protection features enabled by default. No additional settings are required to benefit from more proactive risk identification and reminders.

Final Thoughts

Address poisoning reminds us that Web3 security doesn't only occur in the "most dangerous" moments, but can also hide in the most routine, familiar operations.

When risks begin to exploit human habits, security capabilities also need to evolve from "reactive warnings" to "proactive process protection." For wallets, the priority isn't just executing transactions, but helping users reduce misjudgment and the risk of operational errors at critical nodes.

This is precisely why imToken continuously upgrades its security risk control capabilities: to provide users with more timely and practical security protection while maintaining their self-sovereignty.