Zero-History Wallet Risk: How to Screen Wallets With No Transaction History

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. The response is contextual and behavioral analysis that extends assessment beyond history, applied before funds move.
Most wallet screening tools are built around transaction history. They score wallets by analyzing prior fund flows, counterparty relationships, and behavioral patterns built up over time. This works well for wallets with an established record. It provides no coverage for wallets that have never transacted before. Zero-history wallets are common in legitimate use: new users, fresh operational wallets, and newly onboarded counterparties all start with no history. They are also common in threat activity, where fresh wallets are created to avoid detection by history-based tools. The inability to distinguish between the two creates a structural gap in most compliance and security programmes. This page covers what zero-history wallet risk is, why it matters, what signals are available when history is absent, and how pre-broadcast analysis is designed to extend coverage to the unscreened wallet population.
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. Risk signals and screening outputs are indicators designed to support human and automated decision-making within configured workflows, not legal or regulatory determinations.
Book a Demo

What is zero-history wallet risk?

Zero-history wallet risk refers to the compliance and security exposure that arises when a wallet address has no prior transaction record for screening tools to evaluate. 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 enough history to appear in risk datasets. Zero-history wallet risk is not a specific attack type; it is a structural gap in coverage that affects any compliance or security programme relying solely on history-based screening.

Why do zero-history wallets create a screening gap?

Wallet risk screening typically works by ingesting a wallet address and retrieving its transaction history, then analyzing that history for risk signals: connections to high-risk counterparties, mixer use, structuring patterns, behavioral anomalies, and so on. The more transaction history available, the richer the risk picture.
When a wallet has no prior transactions, this entire analytical layer produces nothing. There is no history to traverse, no counterparty graph to build, no behavioral baseline to establish, and no prior labels to retrieve. The wallet address exists on-chain but is, from a screening perspective, entirely opaque.
This creates three specific problems for compliance and security programmes:
The false clean result problem
A zero-history wallet passed through a standard screening system does not return a low-risk result based on positive evidence of legitimate behavior. It returns a clean result because there is nothing to evaluate. That is a fundamentally different thing, but most screening interfaces present both outcomes identically. Compliance teams that treat a clean result from a zero-history wallet as equivalent to a clean result from a well-understood counterparty are operating on incomplete information.
The first-transaction exposure problem
The first transaction a wallet ever makes is the moment of maximum exposure for history-based screening. There is no data yet. If that first transaction is a large-value transfer, an interaction with a sensitive smart contract, or part of a coordinated attack, the screening system sees nothing to flag. Pre-broadcast analysis of the transaction itself, rather than the wallet's history, is the only analytical layer available at this point.
The deliberately clean slate problem
Threat actors understand that new wallets return clean screening results. Creating fresh wallets for each operation is a known evasion technique precisely because it resets the risk score to zero. Any programme relying solely on accumulated history-based signals is structurally unable to detect threats operating from fresh infrastructure.

How do threat actors use zero-history wallets?

Zero-history wallets appear frequently in financial crime and blockchain security incidents, typically in three distinct operational roles.
Fresh attack infrastructure
Exploit attackers, ransomware operators, and fund laundering operations routinely create new wallets for each campaign or transaction cluster. Using a fresh wallet resets the screening signal to zero and avoids any risk score accumulated from prior activity. Attack infrastructure created hours or days before an exploit is designed to be invisible to history-based detection.
Fund layering and extraction wallets
After an initial exploit or theft, funds are often moved through a sequence of newly created wallets before reaching a mixer, exchange, or final destination. Each hop through a zero-history wallet is a step where standard screening sees nothing until the wallet has been active long enough to accumulate detectable patterns. By then, the funds have typically moved again.
Address poisoning origination
Address poisoning attacks, in which an attacker sends a dust transaction from a lookalike address to insert it into a victim's transaction history, typically originate from newly created zero-history wallets. The attack wallet has no prior record, so a screening check on it returns nothing. Zero-history detection can surface the pattern at the point of the dust transaction itself, before the poisoned address is copied and used.
Onboarding fraud
In exchange and payment platform contexts, fraudulent accounts are often funded from newly created wallets with no prior history. The absence of history is not conclusive evidence of fraud, but it is a risk signal that warrants heightened scrutiny, particularly when combined with other contextual indicators such as immediate high-value activity, unusual asset choices, or rapid fund movement after initial deposit.

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

Request a demo
When a wallet has no prior transaction record, standard history-based signals are unavailable. Risk assessment must draw on signals that exist at or before the time of the first transaction. Several categories of contextual signal remain available.

First transaction value

The value of the first transaction from or to a zero-history wallet relative to typical new wallet behavior. A wallet that immediately transacts at high value on its first interaction is behaviorally atypical for a genuinely new legitimate wallet and may warrant closer scrutiny.

Funding source characteristics

If a zero-history wallet has received an inbound transaction before being screened, the characteristics of that funding transaction are available as risk signals: the risk profile of the sending address, the asset type, the value, and the routing path used to fund the wallet.

Creation timing

The age of the wallet relative to the transaction being assessed. A wallet created hours before a large transaction, or created in a cluster with other newly created wallets at the same time, is contextually different from a wallet that has existed for months with no activity.

Transaction velocity in early interactions

The number of transactions a wallet executes in its first hours or days of activity. Legitimate new wallets typically show gradual activity buildup. A wallet that executes many transactions rapidly from creation is exhibiting a behavioral pattern that may be inconsistent with typical new user activity.

Asset type and protocol interaction

The specific asset being transferred and the smart contracts or protocols being interacted with. A zero-history wallet interacting immediately with high-risk protocols, mixers, or bridges on its first transaction is a stronger risk signal than one making a simple token transfer.

Pre-broadcast execution path

Simulation of the transaction's full execution path before submission can reveal unexpected behaviors even when wallet history is absent. Unusual approval grants, unexpected token routing, interaction with flagged contracts, and economically anomalous state changes are all detectable at simulation time regardless of wallet age.

Coordinated new wallet activity

A wallet created at the same time as multiple other wallets with no history, particularly if those wallets are interacting with each other or with the same protocol, may suggest coordinated infrastructure rather than independent new user activity.

Counterparty risk at first contact

Even when the wallet itself has no history, its first counterparty may. If a zero-history wallet's first transaction involves a counterparty with an elevated risk profile, that counterparty signal is available as a contextual risk indicator.

Self-hosted wallet classification

Confirmation or strong indication that a wallet is self-hosted rather than exchange-hosted is relevant contextual information for risk assessment, particularly under EU AML/CFT rules and related supervisory guidance for in-scope transfers.

How does pre-broadcast analysis help with zero-history wallet risk?

Request a demo
The principle
When wallet history is absent, the transaction itself becomes the primary source of risk signal. Pre-broadcast simulation evaluates that transaction before it executes, surfacing risk indicators that are independent of prior history.
Why this matters
A wallet's history tells you what it has done. Pre-broadcast simulation tells you what this specific transaction is about to do. For zero-history wallets, simulation is often the only analytical layer available at decision time.

Execution path analysis independent of wallet history

Transaction simulation can evaluate the full execution path of a transaction, including all contract calls, token movements, state changes, and approval grants, before the transaction reaches the network. This analysis is available regardless of whether the sending or receiving wallet has any prior transaction history. Unexpected behaviors in the execution path may be detectable from the transaction itself.

First-transaction anomaly detection

Certain execution patterns are inconsistent with what legitimate first transactions typically look like. A zero-history wallet's first transaction that immediately routes through a mixer, grants a large token approval to an unfamiliar contract, or sends to an address with an elevated risk profile may be flagged at simulation time based on the transaction's own characteristics.

Funding source traceability

If a zero-history wallet has received funds prior to the transaction being assessed, pre-broadcast analysis may incorporate the characteristics of those funding transactions, including the risk profile of the sending address, the asset type, and any patterns in the funding path that suggest elevated risk.

Policy-driven controls for unscreened wallets

When configured appropriately, policy controls can be set to apply heightened scrutiny to transactions involving zero-history wallets above configurable value thresholds, routing them for manual review or requiring additional verification before submission. This applies a proportionate additional control layer to the population of wallets where standard screening has limited coverage.

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