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 practical use, there is a type of risk that does not stem 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 disguise, interference, and deception to make users transfer assets to incorrect addresses 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 again, if they simply copy the address from history without carefully verifying each character, they might accidentally send assets to the attacker’s prepared fake address.

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 small test transactions before a formal transfer do not necessarily mitigate the risk.

Even more severe, due to Fusaka’s major gas fee reduction upgrade, the marginal cost of address poisoning attacks has significantly decreased. According to Blockaid, the number of 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 typical on-chain address 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 the address” and then proceeding. Attackers design their disguises around this habit.

2. Malicious transactions blend into normal transaction noise

Address poisoning transactions often involve very small amounts or zero-value transfers, appearing visually similar to regular on-chain transfers. When these are mixed into real transaction records, users find it difficult to quickly distinguish which are genuine and which are deliberately inserted distractions just by eye.

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 history.

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

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

The uniqueness of this risk lies in the fact that it cannot be completely solved just by users being more cautious or paying more attention.

As the entry point for user interactions with the chain, wallets should undertake more proactive judgment and protective measures, intercepting 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-layer defense around address poisoning

1. Hide high-risk transactions to reduce transaction record pollution

To address malicious addresses polluting transaction records with small or zero-value transactions, 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 history and related notifications, minimizing such interference information from entering the user’s view.

The goal isn’t just to keep the interface clean but also to reduce the chance of users copying risk addresses from history in the first place.

2. Preemptively remind at the moment of copying

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

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 providing warnings before transfers, this approach aligns more closely with the actual risk point and helps break the habitual “copy with a single click” path.

3. Continuously mark risks at critical points in the chain

Besides the transaction list and copy scenarios, the system will also flag suspicious addresses and provide relevant alerts in key touchpoints such as transaction details and pre-transfer checks.

This isn’t meant to cause annoyance but to deliver more timely and consistent risk feedback before the user makes the next move.

Technical explanation: why address poisoning requires “dynamic awareness” 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, tricking users into copying or transferring to these addresses later.

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-factum alerts is often insufficient to cover real risks.

imToken’s response isn’t simply labeling addresses as “good” or “bad” permanently. Instead, at key interaction points—refreshing transaction records, viewing details, copying addresses, or initiating transfers—it combines real-time on-chain data and current context to dynamically identify suspicious transactions, driving client-side filtering, marking, strong reminders, or pre-verification actions.

Risk detection isn’t just about “look-alike” matches

The core of poisoning detection isn’t just whether addresses look similar; it’s how to combine multiple pieces of evidence in a noisy environment to make a judgment. The current logic mainly considers these signals:

Similarity evidence

For a fake address to be effective, it must look visually similar enough. The system quantifies structural features of address disguises to identify high-similarity risks.

Cost pattern evidence

To spread at low cost, address poisoning often shows 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, attempting to leverage user inertia to quickly insert fake 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 aggregates multiple evidence types to produce a unified risk assessment, which then guides handling strategies at different 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 uniform risk judgments across different pages.
• Support retrospective analysis: 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 activity, assets, timing, 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 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 against address poisoning by default, requiring no extra setup, providing more proactive risk detection and alerting.

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, familiar operations.

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

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