Address Poisoning Fix: Detect and Prevent Crypto Address Poisoning Attacks

Address poisoning is a crypto attack where an attacker sends a dust transaction from a lookalike wallet address so it appears in your transaction history. If you later copy that address by mistake, you send funds to the attacker. The best fix is verified-address workflows and pre-broadcast destination screening before funds move.
Blockchain addresses are long, complex, and look similar enough that most users check only the first and last few characters. Address poisoning exploits exactly this habit. An attacker generates a vanity address matching those characters, sends a dust transaction to insert it into the victim's history, and waits. The next time the victim copies an address from their history rather than a verified source, they send funds directly to the attacker. Address poisoning does not require a smart contract vulnerability, phishing link, or malware to succeed. In many cases it succeeds purely through transaction-history manipulation. It is often preventable with the right controls before a transaction is submitted. This guide covers how the attack works, how to detect it, what to do if you have been targeted, and how pre-broadcast screening is designed to help prevent address poisoning before funds move.
Reviewed for technical accuracy by Web3Firewall · Last updated: 23 March 2026
Web3Firewall provides risk intelligence and analysis tools. It does not provide legal, regulatory, or investment advice. Nothing on this page constitutes legal or compliance advice. If you believe funds have already been sent to an attacker's address, consult a qualified incident response provider. On-chain transactions are irreversible once confirmed.
Book a Demo

What to do now

If you think you may have been targeted:
  1. Stop copying addresses from transaction history immediately
  2. Reconfirm the intended destination address from a trusted, independent source
  3. Use a saved address book entry or verified ENS name rather than history
  4. Check your recent transaction history for incoming dust or zero-value transactions from unfamiliar addresses
  5. If funds have already been sent to the wrong address, preserve all transaction records and contact a qualified incident response provider
For teams and platform operators:
  1. Enable incoming dust transaction monitoring to detect poisoning injection attempts in real time
  2. Implement pre-broadcast destination screening to flag lookalike addresses before outbound transactions are submitted
  3. Require full address verification for first-time high-value destinations above configurable thresholds
  4. Maintain an auditable record of all detected poisoning attempts for compliance documentation

What is address poisoning?

Address poisoning (also called address spoofing or transaction history poisoning) is an attack in which an adversary sends a small or zero-value transaction from a wallet address that closely resembles one the victim has previously transacted with, typically matching the first and last characters of the legitimate address. The goal is to insert the attacker's lookalike address into the victim's transaction history. If the victim subsequently copies an address from that history rather than from a verified source, they may send funds directly to the attacker. Address poisoning does not require a smart contract vulnerability, phishing link, or malware to succeed. It exploits the habit of copying addresses from transaction history.
In one sentence:
Address poisoning inserts an attacker-controlled lookalike address into a victim's transaction history, so the next time the victim copies a familiar address, they copy the wrong one.
The core mechanic:
An address matching the first and last characters of a legitimate counterparty looks identical at a glance. The middle characters are different, but most users never check them.
The fix:
Never copy addresses from transaction history. Always verify the full address from a trusted source. Use pre-broadcast destination screening configured to catch lookalike addresses before funds move.

How does address poisoning work?

Address poisoning unfolds in four stages, none of which require technical access to the victim's wallet or devices.
Stage 1: Target selection and address surveillance
The attacker identifies a target wallet, typically one that makes regular transfers to a consistent counterparty. On public blockchains, all transaction history is visible. The attacker identifies the most frequently used counterparty addresses in the target's history.
Stage 2: Vanity address generation
Using freely available vanity address generation tools, the attacker creates a new wallet address that matches the first and last characters of the target's known counterparty. On a standard Ethereum address, most users check at most eight characters, leaving the middle section entirely unchecked.
For example (illustrative fictional addresses, not real counterparties):
‍Legitimate address: 0x71C7656EC7ab88b098defB751B7401B5f6d8976F
‍Attacker lookalike: 0x71C7890aB3d7f1234567890ABcd456789a8976F
The opening and closing characters are identical. The middle section differs entirely.
Stage 3: Dust transaction injection
The attacker sends a tiny or zero-value transaction from the lookalike address to the victim's wallet. The immediate financial value is usually negligible; the real risk is the poisoned history entry. This transaction inserts the attacker's address into the victim's history, making it appear as a familiar counterparty.
Stage 4: Waiting for the victim to copy the wrong address
The next time the victim sends funds to their legitimate counterparty, they may open transaction history, see the familiar-looking address, copy it, and send to the attacker instead. The transaction is valid, confirmed on-chain, and irreversible.

How do I know if my wallet has been targeted by address poisoning?

Request a demo

Unfamiliar dust transactions

One or more very small or zero-value transactions appearing in your wallet history from addresses you do not recognise and did not initiate. Each dust transaction is the injection mechanism, inserting the attacker's lookalike address into your history.

Lookalike addresses in history

Addresses in your transaction history that appear identical to known counterparties at first glance but contain different middle characters when the full address is examined. Most wallet interfaces truncate addresses. Always expand to full before copying.

Unexpected inbound transactions

Transactions you did not initiate appearing from addresses you have never previously interacted with. Any unexpected inbound transaction, regardless of value, warrants full address verification before any subsequent sends to similar-looking addresses.

Multiple dust injections with similar patterns

A pattern of small inbound transactions from addresses that all share character sequences with your known counterparties, indicating a systematic poisoning campaign rather than a single attempt.

Addresses mimicking exchange or protocol addresses

Dust transactions from addresses designed to resemble the deposit addresses of exchanges, DeFi protocols, or custodians you regularly interact with, targeting withdrawal flows where address copying is common.

Alerts from wallet monitoring tools

Wallet monitoring systems can be configured to detect incoming dust transactions from addresses matching lookalike attack patterns and alert before any subsequent sends. Proactive monitoring catches poisoning attempts at injection time, before the victim is in a position to copy the wrong address.

What is the fix for address poisoning?

If you have been targeted but have not yet sent funds, the poisoning attempt has succeeded in inserting the attacker's address into your history, but no funds have moved.
Never copy addresses from transaction history. Transaction history is not a safe address source. Copy the destination address directly from a verified source: the recipient's own communication, a verified address book entry, an ENS or blockchain name, or the platform's own interface.
Verify the full wallet address before every send. Not the first few characters. Not the last few. The complete address. Address poisoning is substantially mitigated the moment a user checks the full string rather than a truncated preview.
Mark or label known counterparties in your wallet's address book so you never need to copy from history for regular counterparties.
If you have already sent funds to a lookalike address
Blockchain transactions are irreversible once confirmed. Funds sent to an attacker's address cannot be recalled or frozen through any on-chain mechanism. Contact a qualified incident response provider. Preserve all transaction records and evidence. Report the attacker's address to relevant exchange compliance teams. If the attacker routes funds through an exchange, there is a possibility, though not a certainty, that the exchange may be able to act on a report. Do not send additional funds in an attempt to recover.
For organisations and platforms, the preventive fix extends beyond user education.
Implement pre-broadcast destination address screening, configured to evaluate the destination address before a transaction is submitted. Deploy incoming dust transaction monitoring to detect poisoning injection attempts at the moment they occur. Apply lookalike address detection against a wallet's known counterparty set to flag destination addresses matching a poisoning attack pattern before funds move.

What is the fix for address poisoning?

If you think you may have been targeted:
  1. Stop copying addresses from transaction history immediately
  2. Reconfirm the intended destination address from a trusted, independent source
  3. Use a saved address book entry or verified ENS name rather than history
  4. Check your recent transaction history for incoming dust or zero-value transactions from unfamiliar addresses
  5. If funds have already been sent to the wrong address, preserve all transaction records and contact a qualified incident response provider
For teams and platform operators:
  1. Enable incoming dust transaction monitoring to detect poisoning injection attempts in real time
  2. Implement pre-broadcast destination screening to flag lookalike addresses before outbound transactions are submitted
  3. Require full address verification for first-time high-value destinations above configurable thresholds
  4. Maintain an auditable record of all detected poisoning attempts for compliance documentation

How does pre-broadcast screening help prevent address poisoning?

Request a demo
The principle
Address poisoning is most effectively addressed at the pre-broadcast stage, before confirmation makes the transaction irreversible.
Why pre-broadcast matters:
Once a transaction is confirmed on-chain, it is irreversible. Post-transaction monitoring can detect a poisoning pattern, but cannot recover funds. Pre-broadcast controls are the most reliable intervention point, because they create a window where a transaction can be held, escalated, or blocked before funds move.
When configured appropriately, pre-broadcast screening can address address poisoning through four specific mechanisms:

Destination address novelty detection

A transaction to a destination the sending wallet has not previously used is flagged as a novelty event. For wallets with established counterparty patterns, a sudden transaction to a previously unseen address is a high-signal anomaly, even if the address looks familiar at a truncated glance.

Lookalike address pattern matching

The destination address can be compared against the wallet's known counterparty set. An address sharing the first and last characters of a known counterparty but differing in the middle is a direct lookalike attack indicator. This check requires a system holding the verified counterparty set and actively comparing against it, not transaction history inspection alone.

Dust transaction correlation

If the destination address first appeared in the wallet's history as the sender of a dust or zero-value transaction, that correlation can be surfaced as a risk signal. An address that entered history through a dust transaction should not be trusted without full independent verification.

Behavioral consistency check

The transaction can be evaluated against the wallet's established behavioral patterns, including typical counterparties, transaction sizes, and timing. A large transfer to a first-time address, in a context where the wallet normally sends to a small stable set of counterparties, is anomalous regardless of whether the address appears familiar.
When these signals are detected, systems configured with appropriate policies can hold the transaction, escalate for manual review, or block prior to broadcast within configured workflows, creating the intervention window that confirms or rejects the destination before funds become irreversible.

How does zero-history wallet risk affect Travel Rule compliance?

The Travel Rule requires CASPs and VASPs to collect originator and beneficiary information for in-scope crypto-asset transfers, and to apply risk-based handling measures for transfers involving self-hosted wallets. Zero-history wallets create a specific operational challenge within this framework.
In the EU, Regulation (EU) 2023/1113 and related EBA guidance require CASPs to apply risk-based controls and handling measures for in-scope transfers, including those involving self-hosted wallets. When the counterparty wallet in a transfer has no prior transaction history, the risk assessment component of that process has less historical data to work with.
This does not reduce the obligation; it changes the tools available for meeting it. Risk assessment for zero-history self-hosted wallets may rely more heavily on the contextual and transaction-level signals described in Section 4, and on pre-broadcast simulation of the specific transaction, rather than on accumulated behavioral history.
For organisations subject to Travel Rule obligations, zero-history wallet risk is an operational consideration in designing the risk-assessment component of self-hosted wallet controls. The obligation to apply risk-based controls arises from applicable AML/CFT frameworks across the full transaction population, not from a separately codified requirement specific to zero-history wallets.

How does zero-history wallet risk relate to other wallet risk concepts?

Concept

Definition

Relationship to zero-history wallet risk

Zero-history wallet risk
Screening gap when a wallet has no prior transaction record
Core topic: the structural blind spot in history-based screening
Unhosted wallet risk
Risk associated with wallets not held by a regulated custodian
Zero-history is a subset: many unhosted wallets have transaction histories; zero-history is the specific case where history is absent
Wallet risk scoring
Methodology for assigning a risk score to a wallet based on its characteristics
Challenged by zero-history: standard scoring relies on history; contextual and simulation-based signals may substitute where available
Behavioral analysis
Detection of anomalous patterns relative to established baselines
Partially applicable: some behavioral signals are available at first transaction; full baseline analysis develops over time
Address poisoning
Attack using dust transactions to insert lookalike addresses into history
Intersection: poisoning attacks often originate from zero-history wallets; zero-history detection can be an early signal for poisoning attempts
On-chain AML
Application of AML controls to blockchain transaction data
Zero-history wallet risk is a specific gap within on-chain AML coverage; addressed through contextual signals and simulation rather than history
KYC / identity verification
Off-chain identity verification at onboarding
Complementary: KYC establishes who a user is; zero-history wallet risk assessment addresses what their wallet is about to do

What regulations make zero-history wallet controls relevant?

For many crypto businesses, AML/CFT obligations require risk-based controls across the full transaction population, including transactions involving wallets with no prior history. Zero-history wallet risk is an operational challenge within those existing frameworks, not a separately codified regulatory category. Firms should assess their precise requirements with qualified legal counsel.
Item 1
FATF Risk-Based Approach
FATF guidance requires VASPs to implement a risk-based approach to AML/CFT controls covering all customers and transactions, not only those with established transaction histories. FATF guidance and subsequent updates, including the June 2025 update to Recommendation 16, shape how national and regional regimes implement information requirements and risk-based controls for virtual asset activity, including for new and unhosted wallet counterparties.
Item 2
EU Transfer of Funds Regulation
Regulation (EU) 2023/1113 extends originator-and-beneficiary information requirements to in-scope crypto-asset transfers and is supported by EBA guidance on the information that must accompany transfers and how firms should handle missing or incomplete information. Under the EU framework, CASPs must apply risk-based controls and handling measures for in-scope transfers involving self-hosted wallets, as set out in the Regulation and supervisory guidance. Newly created wallets with no prior history fall within the scope of those controls where the underlying transfer is in scope.
Item 3
EU MiCA
Regulation (EU) 2023/1114 creates CASP authorisation requirements and obligations including transfer service controls. MiCA and EU AML/CFT frameworks are separate regimes that often rely on overlapping monitoring, governance, and control infrastructure. MiCA entered into force in June 2023, with the main CASP regime applying from 30 December 2024, subject in some Member States to transitional arrangements.
Item 4
FinCEN / BSA (US)
FinCEN's guidance clarifies how existing Bank Secrecy Act obligations apply to certain virtual currency business models, including AML programme, recordkeeping, and SAR obligations for covered money services businesses. Risk-based AML programmes are expected to address the full customer and transaction population. The 2019 FinCEN guidance explicitly noted it did not create new requirements but applied existing BSA rules to covered entities.
Item 5
FCA (UK)
In the UK, certain cryptoasset businesses must register under the Money Laundering Regulations and are supervised by the FCA for AML/CTF compliance. Registered firms are expected to maintain systems and controls appropriate to their money-laundering and terrorist-financing risks across their full transaction population, including transactions involving wallets with no established history.
DORA (the Digital Operational Resilience Act, applying from 17 January 2025) is not an AML/CFT regime, but increases the importance of resilient monitoring and alerting infrastructure for regulated entities, including CASPs under MiCA, across all transaction types.

Use cases by team

Request a demo

Compliance and AML teams

Design risk-based controls that apply proportionate scrutiny to zero-history wallet interactions without blocking all new wallet activity. Configure thresholds for heightened review based on transaction value, asset type, and protocol interaction. Maintain audit records of all zero-history wallet assessments for regulatory examination support.

Exchange operations (CEX)

Apply risk-based due diligence to deposit and withdrawal requests involving zero-history wallets. Flag first-time high-value deposits from wallets with no prior record for compliance review. Use pre-broadcast simulation to evaluate the execution path of transactions involving zero-history counterparties before processing.

Custodians

Screen outbound transfer destinations that are zero-history wallets before authorisation. Apply heightened scrutiny to first-time transfers to wallets with no prior record above configurable value thresholds. Use contextual and simulation-based signals in place of unavailable historical signals for risk assessment.

Payment platforms

Assess incoming payments from zero-history wallets using contextual signals: first transaction value, funding source characteristics, asset type, and pre-broadcast simulation of the payment transaction's execution path. Route elevated-risk zero-history wallet payments to compliance review before processing.

Infrastructure providers

Integrate zero-history wallet risk assessment into wallet APIs, RPC infrastructure, or transaction relay services, surfacing contextual risk signals to downstream clients for wallets that return no results from standard history-based screening.

DeFi protocol teams

Monitor first-time interactions with your protocol from wallets with no prior transaction history. Consider whether multiple new wallets beginning to interact with your protocol simultaneously may indicate coordinated activity. Apply pre-broadcast simulation to first transactions from zero-history wallets interacting with sensitive protocol functions.

Example: zero-history wallet assessment in practice

Here is a concrete illustrative example of how zero-history wallet risk assessment differs from standard screening and what contextual signals remain available. All addresses and figures are entirely fictional and are not based on any real organisation or incident.
This example shows the core problem with treating a zero-history clean result as equivalent to a verified clean result. The wallet is not clean; it is unscreened. The appropriate response to a zero-history result is proportionate additional scrutiny, not automatic approval.

Why Web3Firewall for zero-history wallet risk

Request a demo
Web3Firewall is a Web3 security and compliance platform, often described as a SIEM for blockchain. It is designed for compliance and security teams who need wallet risk assessment to cover the full transaction population, including wallets for which standard history-based screening returns no usable signal.
The platform is designed to combine behavioral monitoring, wallet risk scoring, transaction simulation, and a programmable policy engine into a single operational layer. For zero-history wallets, the platform can shift assessment to contextual signals and pre-broadcast simulation of the transaction itself, rather than relying solely on accumulated transaction history. Transactions routed through Web3Firewall can receive a real-time verdict of allow, deny, or require approval, applying customer-defined risk and policy controls within configured workflows before a transaction reaches the network.
This enables organisations to apply proportionate, policy-driven scrutiny to the zero-history wallet population without treating every new wallet as high risk or returning a false clean result when no data is available.

Contextual risk assessment for new wallets

When a wallet has no prior transaction history, risk assessment can be configured to draw on contextual signals available at transaction time: creation timing, funding source characteristics, first transaction value, asset type, and protocol interaction pattern. These signals may be combined into a contextual risk indicator even when historical signals are unavailable.

Pre-broadcast simulation independent of wallet history

Transaction simulation can evaluate the full execution path of a transaction before it reaches the network, regardless of whether the sending or receiving wallet has any prior history. Unexpected token approvals, unusual routing, interactions with flagged contracts, and economically anomalous state changes may all be detectable at simulation time from the transaction itself.

Coordinated new wallet activity detection

Wallet activity can be monitored to detect patterns where multiple zero-history wallets are created and begin transacting within a short time window, interacting with the same protocols or platforms. Such patterns may indicate coordinated infrastructure rather than independent new user activity, depending on configuration and supported environments.

Policy-driven controls for the zero-history population

Configurable policy controls can be set to apply heightened scrutiny to transactions involving zero-history wallets above defined value thresholds, routing them for manual review, requiring additional verification, or holding them pending approval within customer-defined workflows. This applies proportionate additional coverage to the population with limited screening data.

Funding source traceability

If a zero-history wallet has received an inbound funding transaction before the assessed transaction, the risk characteristics of that funding source can be incorporated into the assessment. A zero-history wallet funded by a high-risk address carries elevated contextual risk even without its own transaction history.

Audit-ready zero-history assessment records

Every zero-history wallet assessment, contextual signal evaluation, and transaction verdict can be logged with supporting evidence. Compliance teams can maintain an auditable record of how zero-history wallet transactions were assessed, what signals were available, and what decisions were made, for regulatory examinations and governance reviews.
Web3Firewall provides risk intelligence and analysis tools. It does not provide legal, regulatory, or investment advice. Risk signals and assessment outputs are indicators designed to support human and automated decision-making within configured workflows. They are not guarantees of detection or prevention outcomes. Results depend on integration, configuration, and supported environments.

Extend wallet screening beyond the history gap

Standard wallet screening returns nothing on zero-history wallets. Web3Firewall is designed to extend coverage to the unscreened population using contextual signals and pre-broadcast simulation, where the transaction's own execution path provides the risk signal that wallet history cannot. Try the sandbox to assess any wallet address, or book a demo to see how zero-history wallet controls fit into your compliance programme.
Try the sandbox
Book a demo

Frequently Asked Questions

What is zero-history wallet risk?

Zero-history wallet risk is the blind spot that appears when a wallet has no prior on-chain record, so standard screening tools return little or no evidence-based risk signal. Because most wallet screening relies on historical transaction data and known-bad address lists, a newly created wallet returns no risk signals, creating a gap where threat actors can operate undetected until they accumulate detectable history.

Why are zero-history wallets a problem for crypto compliance?

A zero-history wallet returns no matches against watchlists, no risk score from historical data, and no behavioral baseline to deviate from. This means a new wallet used for illicit activity can pass through standard screening undetected on its first interaction. Compliance programmes relying solely on known-bad address lists have no coverage for this category of wallet.

How do you screen a wallet with no transaction history?

When a wallet has no prior transaction history, risk assessment shifts to contextual signals available at transaction time: the value and asset type of the first transaction, the risk profile of the funding source if available, the wallet's creation timing, transaction velocity in early interactions, and pre-broadcast simulation of the transaction's full execution path to surface unexpected behaviors.

Are zero-history wallets always high risk?

No. Most newly created wallets belong to legitimate users. Zero-history is a signal reflecting limited screening coverage, not a determination that a wallet is malicious. The appropriate response is heightened scrutiny and contextual assessment, not automatic rejection. The goal is proportionate controls that extend coverage to the unscreened population without blocking legitimate users.

What signals can be used to assess zero-history wallet risk?

Available signals include: first transaction value relative to typical new wallet behavior, funding source characteristics if the wallet received an inbound transaction, creation timing relative to the transaction, transaction velocity in early interactions, asset type and protocol interaction pattern, and pre-broadcast simulation of the transaction's execution path revealing unexpected approvals, routing, or contract interactions.

What regulations make zero-history wallet controls relevant?

AML/CFT frameworks require risk-based controls across the full transaction population, not only those involving wallets with established histories. In the EU, Regulation (EU) 2023/1113 and related EBA guidance require CASPs to apply risk-based handling measures for in-scope transfers, including those involving self-hosted wallets that may be newly created. FATF guidance requires risk-based approaches covering all customers and transactions. Firms should assess their specific obligations with qualified legal counsel.

How is zero-history wallet risk different from unhosted wallet risk?

Unhosted wallet risk refers broadly to compliance and operational risks associated with wallets not held by a regulated custodian or exchange. Zero-history wallet risk is a specific subset focused on the screening gap created when a wallet has no transaction record. Many unhosted wallets have established transaction histories; zero-history wallets specifically present the challenge of assessment without prior data.

What is the difference between zero-history wallet risk and address poisoning?

Address poisoning is a specific attack in which an attacker sends dust transactions from a lookalike address to insert it into a victim's transaction history. Zero-history wallet risk is a structural screening gap, not a specific attack. The two can intersect: address poisoning attacks often originate from newly created zero-history wallets, making zero-history detection a useful early signal for poisoning attempts.
HomeAbout UsCareerProductPartnership
CEXsCustodiansInfrastructure ProvidersMSSPsStablecoin and Token Providers
Docs Blogs Privacy Policy Terms and Conditions
© All rights reserved. Web3Firewall. Privacy |  Terms and Conditions