# Wallet screening: supported blockchains and crypto risk

Source: https://help.didit.me/transactions-monitoring/wallet-screening
Updated: 2026-10-30

Screen wallets on Bitcoin, Ethereum, Solana, Base, Optimism and Arbitrum One. Find supported blockchain values, token coverage and risk-score guidance.

Wallet screening looks up a blockchain address's on-chain exposure and returns a
risk score with source-of-funds and destination-of-funds breakdowns. From **$0.15**
per lookup, or **$0.02** if you bring your own blockchain-analytics provider key.
It can run coupled to a transaction or on demand.

## What it tells you

[Video: Wallet risk and what the score bands mean - Didit Academy](https://www.youtube.com/watch?v=Yhm63_n7HuU&t=180)

![The rules section of transaction monitoring in the Didit console](https://help.didit.me/screenshots/transaction-rules-light.webp)

*Screening results are only useful once a rule acts on them.*

Screening a person against sanctions lists and screening a crypto address are different problems. A name-based screen asks whether the individual is listed. Wallet screening asks where the money has been: whether the address has exposure to sanctioned entities, illicit services, mixers, or other high-risk counterparties, traced through on-chain activity.

You get back a risk score and severity, plus breakdowns of **source of funds** and **destination of funds** - the categories of counterparty the address has received from and sent to.

## Coupled or on demand

Two ways to use it:

- **Transaction-coupled.** The address is screened as part of evaluating a transaction, so the rules can act on the result in the same pass.
- **On demand.** Screen an address on its own - before accepting a deposit, when onboarding a wallet, or while investigating a pattern after the fact. In the console this is **Screen an address** on the **Crypto monitoring** tab, which is rolling out and greyed out where it isn't available yet.

## Direction matters

Whether an address is the sender or the receiver changes what the risk means, and it can change what the analytics provider returns for source and destination exposure. An inbound transfer from a high-risk source is a different problem from an outbound transfer to one, and your rules should usually treat them differently rather than applying one threshold to both.

## Bring your own provider key

If you already hold a contract with a blockchain-analytics provider, you can plug your own key in and pay **$0.02** per lookup instead of $0.15 - Didit does the routing and normalisation, and the lookup runs on your provider account.

The providers available in the console Marketplace are listed there; which ones fit your existing contracts is worth checking before you assume. See [wallet screening](https://docs.didit.me/transaction-monitoring/wallet-screening).

## Which blockchains are supported?

Managed wallet screening and crypto transaction screening support these 13 networks:

| Blockchain network | API value |
|---|---|
| Bitcoin | `BTC` |
| Ethereum | `ETH` |
| Litecoin | `LTC` |
| XRP Ledger | `XRP` |
| Bitcoin Cash | `BCH` |
| Dogecoin | `DOGE` |
| Tron | `TRX` |
| Solana | `SOL` |
| Polygon | `MATIC` |
| BNB Smart Chain | `BNB` |
| Base | `BASE` |
| Optimism | `OP` |
| Arbitrum One | `ARB` |

You can screen an address before a transfer or screen a transaction hash after it.
Always select the actual network: an address can have different activity and risk on each chain.
Using `ETH` does not screen that address on Base, Optimism or Arbitrum One.

Celo, Mode and Plume are not currently supported by the managed integration.
Limited sanctions-only coverage is not the same as full wallet exposure and transaction screening.
If you need another network, contact support to check its availability.
Connected screening providers have their own network and account coverage; Lightning requires a supported provider connection.

### How do USDT, USDC and custom tokens work?

The asset and the network are separate.
For a wallet lookup, use the chain's API value in `blockchain`.
For a transaction, put the token symbol in `transaction_details.currency`, set `currency_kind` to `crypto`, and put the chain in `transaction_details.crypto_params.crypto_chain`.
Enable `include_crypto_screening` when you want that transaction screened.

For example, a token on Base uses `BASE` as its chain, even when the token has a different symbol.
The standalone `USDT` and `USDC` values are legacy Ethereum aliases, not searches across every network that supports those tokens.
Always specify the network for token transactions rather than relying on hash-based defaults.
Custom-token transfer screening also depends on whether its contract is indexed on that network.
A created transaction does not prove that screening succeeded: check its screening status and result.

See the [wallet screening API and blockchain values](https://docs.didit.me/transaction-monitoring/wallet-screening#chain-coverage) and the [token and network selection guide](https://docs.didit.me/transaction-monitoring/aml-screening#asset-and-network-selection).

> **Note:** If a wallet screening call returns nothing at all rather than a low-risk result,
> that's a different situation from a clean address. An empty provider response
> should never be read as "no risk found" - check whether wallet screening is
> actually enabled for your account and whether the chain is supported.

## Enabling it

Choose who screens your wallets in **Transaction monitoring → Settings → Wallet screening**: Didit's managed provider, or your own provider account connected in the Marketplace, with the price per screen shown next to each. If the **Crypto monitoring** tab is greyed out with "not available on this deployment yet", that part of the console is still rolling out for everyone, not switched off for your account; the API is the way to screen until it arrives.

## Reading risk levels honestly

Two traps worth naming:

- **`UNKNOWN` is not `LOW`.** An unknown risk level means there wasn't enough data to assess the address - a brand-new wallet with no history, for instance. Treating that as low risk is a decision you should make deliberately, not by accident of mapping.
- **A risk score is exposure, not guilt.** An address that received funds two hops from a mixer is not necessarily its owner's fault. Score-based rules should reflect how many hops and what proportion, which is what the source-of-funds breakdown is for.

An exchange wallet is not guaranteed to have a zero risk score.
Use the current result for the selected chain and read the attribution and exposure breakdown.
A sanctions flag can reflect fund-flow exposure to a sanctions-related entity; it does not by itself mean the wallet owner is sanctioned.
Documentation examples show the response format and are not permanent risk assessments of real addresses.

## Not the same as Travel Rule

Wallet screening tells you about risk. Travel Rule is a separate obligation about exchanging originator and beneficiary information with the counterparty institution. They often apply to the same transfer and are billed separately. See [Travel Rule](https://help.didit.me/transactions-monitoring/travel-rule).

## What it costs

| | Price |
|---|---|
| Wallet verification & screening | from $0.15 per lookup |
| Same, with your own provider key | $0.02 per lookup |

When a Travel Rule transfer needs a wallet lookup to identify the counterparty institution, that lookup is billed once at the screening rate - never twice when crypto monitoring already screened the same address on the same transaction.