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 reaction to security is to protect private keys, seed phrases, and authorization permissions.

Of course, these are important, but in actual usage, there is a type of risk that does not come from private key leaks nor rely on contract vulnerabilities, but occurs during an ordinary operation: copying addresses.

Address poisoning exploits this very point. It doesn’t profit from hacking systems but uses impersonation, interference, and deception to make users transfer assets to the wrong address during seemingly normal transfer processes.

The reason these attacks are tricky isn’t because of high technical barriers, but because they precisely leverage users’ visual habits and path dependencies in daily operations.

What is address poisoning?

Address poisoning refers to attackers generating a fake address that looks highly similar to the user’s commonly used address, then mixing this address into the user’s transaction history through zero or very small transactions.

When the user needs to transfer assets next time, if they simply copy the address from the transaction history without carefully verifying each character, they might accidentally send assets to the impersonated address prepared by the attacker.

Such attacks are not rare. Over the past two years, multiple public cases have appeared on-chain, proving that address poisoning can cause actual losses, and even habits like “testing with small amounts before a formal transfer” may not be enough to avoid risk.

More seriously, because Fusaka’s upgrade significantly reduces gas fees, the marginal cost of address poisoning attacks has dropped sharply. According to Blockaid statistics, on-chain poisoning attempts reached 3.4 million in January 2026, a 5.5-fold increase from November last year (628k), showing a explosive growth in poisoning frequency.

Why is address poisoning so easy to fall for?

From a principle standpoint, address poisoning isn’t complicated; what makes it hard to defend against is that it hits several natural weaknesses in user operations.

1. Addresses themselves are not suitable for manual verification

A chain address typically consists of 42 characters. For most users, verifying each character is not a realistic, stable, or sustainable approach. Often, people only look at the first few and last few characters, confirming “that looks like that address” and then proceeding. Attackers design their impersonations around this habit.

2. Malicious transactions blend into normal transaction noise

Address poisoning transactions often involve very small amounts or zero value, appearing in form similar to regular on-chain transfers. When they merge into real transaction records, users find it difficult to quickly distinguish which are genuine interactions and which are deliberately inserted distractions just by visual inspection.

3. Traditional alerts often come too late

Many security warnings occur before “confirming the transfer.” But for address poisoning, the critical risk point is usually earlier—the moment when the user decides to copy an address from the history.

If risk detection and alerts only happen at the last step, the path of accidental operation has already been formed.

Wallets need to do more than just “remind” about address poisoning

This type of risk is special because it cannot be completely solved just by users being more cautious or paying a little more attention.

As the entry point for user interactions with the chain, wallets should undertake more proactive judgment and protective measures, catching risks at earlier touchpoints rather than leaving all the burden on users.

In imToken 2.19.0, we further upgraded our security risk control capabilities related to address poisoning. The overall approach isn’t just adding a single warning but embedding detection, filtering, reminders, and verification earlier in the user operation flow at more appropriate points.

Three layers of defense against address poisoning

1. Hiding high-risk transactions to reduce transaction pollution

To address malicious addresses polluting transaction records with small or zero amounts, the new version defaults to enabling the “Hide Risky Transactions” feature.

When the system detects high-risk poisoning transactions, it will prioritize filtering them out from transaction records and related notifications, minimizing such interference information from entering the user’s view.

The goal isn’t just to make the interface cleaner but also to reduce the chance of users copying risky addresses from history at the source.

2. Preemptive alerts at the moment of copying

The key breakthrough in address poisoning isn’t the transfer button itself but the copying address step.

Therefore, when users perform copy operations from transaction details, the system will add clearer interactive prompts, guiding users to verify the address more thoroughly rather than relying solely on matching the first and last characters.

Compared to only issuing warnings before transfers, this approach aligns more closely with the actual risk point and helps interrupt the habitual “just copy” path.

3. Continuous risk marking at critical points

Besides the transaction list and copy scenarios, the system will also mark suspicious addresses with clear labels and relevant alerts at key points like transaction details and pre-transfer checks.

This isn’t meant to increase disturbance but to provide more timely and consistent risk feedback before users take the next step.

Technical explanation: why address poisoning requires “dynamic perception” risk control

Address poisoning doesn’t exploit protocol vulnerabilities but leverages user operation habits and visual inertia. Attackers create highly similar fake addresses and use small or zero-value transactions to insert them into history, inducing users to copy or transfer to the wrong address.

A major reason it’s hard to manage is: from on-chain results, these transactions often appear “normal.” There are no obvious protocol anomalies or traditional attack signatures, so relying solely on static blacklists or post-hoc alerts often isn’t enough to cover real risks.

imToken’s response to such risks isn’t simply labeling addresses as “good” or “bad” permanently, but dynamically recognizing suspicious transactions at key points—such as when users refresh transaction records, view details, copy addresses, or initiate transfers—by combining real-time on-chain data and current interaction context, then driving client-side filtering, marking, strong reminders, or pre-verification actions.

Risk detection isn’t just about “looking similar”

The core of poisoning detection isn’t just whether strings are similar but how to combine multiple pieces of evidence to judge in a noisy environment. The current logic mainly considers these signals:

Similarity evidence

For an impersonation address to be effective, it must look sufficiently similar visually. The system quantifies structural features of address impersonations to identify high-similarity risks.

Cost pattern evidence

Address poisoning aims for low-cost spread, often showing specific amount distributions and transaction patterns. Amount signals alone aren’t decisive but can be combined with other evidence to reduce false positives.

Behavioral timing evidence

Some poisoning transactions occur immediately after genuine user transfers, trying to leverage user inertia to quickly insert impersonated addresses into transaction records. The system evaluates such behaviors within specific time windows and contextual conditions.

Why unify risk decision-making?

A single signal alone isn’t enough for high-confidence risk judgment. Therefore, the system combines multiple evidence types to produce a unified risk result, which then guides different handling strategies at various touchpoints.

This design offers three main benefits:

• Reduce false alarms: Weak signals won’t trigger high-level actions alone.
• Ensure consistent experience: The same transaction receives consistent risk assessments across different pages.
• Support review and optimization: Each detection can be traced back to its basis, facilitating continuous improvement.

For non-custodial wallets, this risk control capability is especially challenging.

Because address poisoning exploits user behavior paths rather than obvious on-chain anomalies; attack methods evolve with chain, assets, rhythm, and disguise techniques. Without centralized control points, protection effectiveness depends heavily on the quality of detection, product touchpoint design, and strategic iteration.

Therefore, imToken builds this capability into a sustainable security engineering system, supporting strategy updates, version management, and performance monitoring and review, ensuring defenses keep pace with evolving attack methods.

How to upgrade defense capabilities

If you’re already using imToken, it’s recommended to upgrade to 2.19.0 as soon as possible.

The new version has enabled relevant protections by default against address poisoning risks, providing more proactive risk recognition and alerts without additional setup.

In conclusion

Address poisoning reminds us that Web3 security isn’t only about the “most dangerous” moments but can also hide in the most routine and familiar operations.

When risks start exploiting human habits, security capabilities need to shift from “result alerts” to “process protection.” For wallets, it’s more important not just to execute transactions but to help users reduce misjudgments and operational errors at critical nodes.

This is also why imToken continuously upgrades its security risk control: to allow users to maintain control while receiving more timely and practical safety protections.