How to reduce the risk of address poisoning at the source?

Article by: imToken

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 come from private key leaks or contract vulnerabilities, but occurs in an ordinary operation: copying addresses.

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

The reason this type of attack is tricky isn’t because of high technical barriers, but because it precisely leverages users’ visual habits and path dependencies in daily operations.

What is address poisoning?

Address poisoning refers to an attacker generating a fake address that looks highly similar visually 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 mistakenly send assets to the disguised 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 severely, due to Fusaka’s significant gas fee reduction upgrades, the marginal cost of address poisoning attacks has decreased substantially. 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

An on-chain address string usually consists of 42 characters. For most users, verifying each character is not a realistic, stable, or sustainable method. Often, people only look at the first few and last few characters, confirm “it looks like that address,” and then proceed. Attackers design disguises around this habit.

2. Malicious transactions can blend into normal transaction noise

Address poisoning transactions often involve very small amounts or zero-value transfers, which in form are indistinguishable from normal on-chain transfers. When they merge into real transaction records, users find it difficult to quickly distinguish which are genuine transactions and which are deliberately inserted interference 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 transaction 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

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

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 pressure on users.

In imToken 2.19.0, we have further upgraded our security risk control capabilities related to address poisoning. The overall approach is not to add a single warning but to embed 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 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 records and related notifications, minimizing the direct intrusion of such interference into the user’s view.

The goal is not only to make the interface cleaner but also to reduce the probability of users accidentally copying a risky address from history at the source.

2. Preemptively remind at the moment of copying

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

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

Compared to only issuing warnings before transfers, this approach is closer to the actual risk point and more effective at breaking the habitual “just copy” path.

3. Continuously mark risks at critical points in the process

Besides the transaction list and copy scenarios, the system will also provide clear labels and reminders for suspicious addresses in transaction details, pre-transfer checks, and other key interaction points.

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

Technical insight: 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 addresses that look very similar to real ones and use small or zero-value transactions to insert them into history, inducing users to copy or transfer mistakenly.

A major reason it’s hard to manage is: from the on-chain execution 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 to such risks isn’t simply labeling addresses as “good” or “bad” permanently. Instead, at key points like transaction refresh, detail viewing, copying addresses, or initiating transfers, it combines real-time on-chain data and current interaction context to dynamically identify suspicious transactions, driving the client to perform filtering, marking, strong reminders, or pre-verification actions.

Risk detection isn’t just about “whether it looks like it”

The core of poisoning detection isn’t just whether addresses are similar strings but how to combine multiple evidence types to judge amid complex noise environments. The current logic mainly considers these signals:

Similarity evidence

For an attack to succeed, the fake address must look sufficiently similar visually. The system quantifies structural features of address disguises 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, attempting to leverage user inertia right after completing an operation to quickly insert fake addresses into records. The system assesses such behaviors within specific time windows and contextual conditions.

Why unify risk decision-making?

A single signal alone often isn’t enough for high-confidence risk judgment. Therefore, the system aggregates 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 retrospective optimization: Each detection can be traced back to its basis, facilitating continuous improvement.

For non-custodial wallets, this kind of risk control 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 strategy 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 protection 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 for address poisoning risks 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 leverage human habits, security capabilities need to shift from “result alerts” to “process 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.