In the Web3 world, many people's first reaction to security is to protect private keys, mnemonic phrases, and authorization permissions.

These are certainly important, but in practical usage, there is another type of risk that does not stem from private key leakage or depend on contract vulnerabilities, but occurs during an operation that is seemingly ordinary: copying an address.

Address poisoning exploits this situation. It does not profit by hacking the system, but by disguising, interfering, and misleading users into transferring assets to the wrong address in what appears to be a normal transfer process.

This type of attack is tricky, not because of how high the technical barrier is, but because it precisely leverages users' visual habits and path dependencies in everyday operations.

What is address poisoning?

Address poisoning refers to attackers generating a disguised address that visually resembles a user's commonly used address, and then incorporating this address into the user's transaction history through a zero or very small amount transaction.

The next time the user needs to make a transfer, if they "casually copy" the address from their transaction history without verifying all the characters one by one, they might mistakenly transfer assets to the disguised address prepared by the attacker.

Such attacks are not uncommon. In the past two years, multiple public cases have emerged on-chain, proving that address poisoning can cause actual losses, and even habits like "executing a small test transfer before a formal transfer" may not be sufficient to avoid risks.

Worse still, the significant reduction in gas fees due to the Fusaka upgrade has indirectly led to a significant drop in the marginal cost of address poisoning attacks. According to Blockaid, the number of on-chain poisoning attempts reached 3.4 million in January 2026, a 5.5 times increase from November last year (628,000), showing an explosive growth in poisoning frequency.

Why is address poisoning easy to fall for?

From a theoretical standpoint, address poisoning is not complex; what makes it difficult to defend against is that it strikes at several natural weaknesses in user operations.

1. The address itself is not suitable for manual verification

A string of on-chain addresses typically consists of 42 characters. For most users, verifying the entire address character by character is not a realistic, stable, or sustainable way to operate. Many times, people only look at the first few and last few characters, confirming "it looks like that address" and then proceeding to the next step. Attackers design disguises based on this habit.

2. Malicious transactions blend into normal transaction noise

Address poisoning transactions often appear with very low amounts or even zero amounts, which are essentially indistinguishable from normal on-chain transfers. Once they blend into real billing records, users find it difficult to quickly discern which are normal transactions and which are deliberately placed distractions just by looking at a long list of historical records.

3. Traditional reminders often occur too late

Many security reminders occur before "confirming a transfer." However, for address poisoning, the truly critical risk point usually comes much earlier—at the moment the user decides to copy the address from their transaction history.

If risk identification and reminders only appear at the last step, then the erroneous operation path has likely already been formed.

In the face of address poisoning, wallets need to do more than just "remind"

The uniqueness of this risk lies in the fact that it cannot be completely solved simply by having users take a closer look and be a bit more cautious.

As a gateway for users to interact with the blockchain, wallets should take on more pre-emptive judgments and proactive protections, trying to intercept risks at earlier touchpoints rather than leaving all the pressure on users themselves.

In imToken 2.19.0, we have made further upgrades to our security risk control capabilities in response to risks related to address poisoning. The overall approach is not to increase a single prompt, but to move identification, filtering, reminders, and verification to more suitable positions within users' actual operational paths.

Three layers of protection against address poisoning

1. Hide high-risk transactions to reduce bill contamination

To address the issue of malicious addresses contaminating billing records through small or zero-amount transactions, the new version defaults to enabling the "hide risky transactions" feature.

When the system identifies high-risk poisoning transactions, it will prioritize filtering them in transaction records and related notifications to reduce the number of these distractions entering the user's view.

The purpose of this is not just to make the interface cleaner, but more importantly, to reduce the probability of users mistakenly copying risky addresses from their transaction history right from the source.

2. Bring reminders forward to the moment of copying

The most critical breakthrough point in address poisoning is not the transfer button itself but the act of copying the address.

Therefore, when a user performs a copy action from the transaction detail page, the system will add more explicit interactive reminders, guiding the user to conduct a more thorough verification of the address rather than merely relying on the first and last characters for judgment.

Compared to only prompting before the transfer, this approach is closer to the actual risk occurrence node and is more helpful in interrupting the habitual path of "casually copying."

3. Continuously mark risks in key links

Beyond transaction records and copying scenarios, the system will also give clear identifications and corresponding reminders for suspected risky addresses at key touchpoints like transaction details and pre-transfer verifications.

This is not meant to increase disturbances but hopes to provide more timely and consistent risk feedback before the user actually makes the next operational step.

Technical Interpretation: Why Address Poisoning Requires a “Dynamic Perception” Risk Control Capability

Address poisoning does not utilize on-chain protocol vulnerabilities but instead takes advantage of user operational habits and visual inertia. Attackers create disguised addresses that closely resemble real addresses and then use low or zero-value transactions to mix them into historical records, leading users to mistakenly copy and transfer to these addresses in subsequent operations.

One important reason why it is difficult to manage is: Based on on-chain execution results, such transactions often appear as "normal." There are no obvious protocol anomalies or traditional attack signatures, so relying solely on static blacklists or post-event reminders often proves insufficient to cover genuine risks.

imToken's response to these kinds of risks does not simply label addresses as permanently "good" or "bad," but dynamically recognizes suspicious transactions by combining real-time on-chain data and the current interaction context at key touchpoints like refreshing transaction records, viewing details, copying addresses, or initiating transfers, and drives the client to undertake filtering, marking, strong reminders, or preemptive verifications.

Risk identification is not just about "looking similar"

The key to poisoning recognition lies not only in whether the strings are similar but how to combine multiple types of evidence for judgment in a complex noise environment. The current recognition logic primarily considers the following types of signals:

Similarity evidence

For an attack to be valid, the disguised address must first be visually "close enough." The system quantifies the structural features of address disguises to identify these high-similarity risks.

Cost shape evidence

Address poisoning typically exhibits specific amount distributions and transaction forms for low-cost dissemination. Amount signals alone are not decisive, but they can be used alongside other evidence to reduce misjudgments caused by single factors.

Behavioral timing evidence

Some poisoning transactions may closely follow users' real transfer actions, attempting to leverage users' inertia after completing operations to quickly insert the disguised address into transaction records. The system will comprehensively assess this type of behavior under specific time windows and contextual conditions.

Why make unified risk decisions?

Single signals are often insufficient to support highly credible risk judgments. Therefore, the system will comprehensively assess multiple types of evidence to output a unified risk result, which is then mapped to different handling strategies across various touchpoints.

This design primarily yields three benefits:

• Reduce false positive noise: Weak signals will not independently trigger high-level handling.
• Ensure consistent experience: The same transaction receives consistent risk judgments on different pages.
• Support retrospective optimization: Each occurrence can trace back to the basis for judgment, facilitating continuous iteration.

For non-custodial wallets, these types of risk control capabilities are particularly challenging.

Because address poisoning leverages user behavior paths rather than obvious on-chain anomalies; and the attack methods continue to change with the chain, assets, rhythms, and disguising techniques. In the absence of centralized control points, the effectiveness of protection relies more on the synergy between identification quality, product touchpoint design, and strategy iteration capabilities.

Therefore, imToken has built this capability into a sustainable evolving security engineering system, supporting strategy updates, version management, as well as effect observation and retrospectives, allowing protective capabilities to keep pace with changes in attack methods.

How to upgrade protective capabilities

If you are already using imToken, it is recommended to upgrade to version 2.19.0 as soon as possible.

In response to risks related to address poisoning, the new version has enabled the corresponding protective capabilities by default, requiring no extra settings to achieve a more preemptive risk identification and reminder experience.

In conclusion

Address poisoning reminds us that Web3 security does not only happen at the "most dangerous" moments; it can also lurk in the most ordinary and familiar operations.

When risks begin to exploit human habits, security capabilities also need to shift from "result reminders" to "process protections." For wallets, what is more important is not just executing transactions, but helping users reduce misjudgments and lower the risks of operational errors at key nodes.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。