Methodology
How WalletDNA scores wallets.
Documented, not magic.
A risk score is only useful if you can defend it. This page documents the confidence tiers, score components, data sources per chain, refresh cadence, and known limitations behind every WalletDNA report.
Confidence tiers
Every wallet attribution is labeled with one of four confidence tiers. The tier describes how much corroborating evidence supports the entity label — not how risky the wallet is.
VERIFIED
Direct on-chain proof or first-party attestation.
Examples: OFAC / EU / UK sanctions list match by address; signed Proof-of-Reserves commitment from the exchange; smart-contract owner is a publicly known multisig.
HIGH
Match in two or more independent reputable sources, or a strong primary signal.
Examples: Address appears in multiple independent attribution databases, for example a label independently corroborated by MistTrack (SlowMist); verified contract bytecode matches a known protocol deployment.
MEDIUM
Identified from a single third-party data source.
Examples: Entity label from a chain-specific explorer (e.g. XRPSCAN), Blockchair address tag, or community-curated dataset.
LOW
Heuristic or behavioral inference only — no external attribution.
Examples: Wallet age, balance tier, transaction pattern (CoinJoin, mixer proximity), or hop distance to a known entity.
Score components
Scoring is deterministic and versioned (current methodology: v2.6). Every wallet starts at a baseline of 5. Signals add or subtract their published weight and the result is clamped to 0–100. Two rules override the arithmetic: a direct sanctions match floors the score in the CRITICAL band, and a dusting campaign floors it in ELEVATED. Floors apply after every other term, so nothing a wallet does well subtracts below them. Every report states the methodology version it was scored under.
| Band | Score range | Reading |
|---|---|---|
| LOW | 0–20 | No material risk signals detected. |
| MODERATE | 21–40 | Weak signals present; nothing that alone warrants escalation. |
| ELEVATED | 41–60 | Signals worth a documented review before proceeding. |
| HIGH | 61–80 | Serious signals; enhanced due diligence is warranted. |
| CRITICAL | 81–100 | Sanctions designation or equivalent; do not proceed without legal review. |
Sanctions
Critical driverDirect listing on a sanctions register, or measurable fund flow to and from listed addresses. A direct match floors the score in the CRITICAL band regardless of every other signal: no amount of good behavior offsets a designation. The floor is applied after all mitigating signals, so nothing subtracts below it.
| Signal | Score weight | Detection |
|---|---|---|
| Sanctions list match | score floors at 82 (CRITICAL) | Address screened against OFAC SDN and international sanctions data, refreshed daily. The matching authority is named on the report. |
| Volume via sanctioned addresses | +12 to +45 by share of volume | Counterparty graph analysis. Tiers at any exposure, 1%, 10%, and 30% of traced volume. |
Threat actors
Critical driverAttribution to a known criminal operation: hacker groups, drainers, ransomware operators, darknet markets. Attribution comes from a curated entity database with sources cited on the report.
| Signal | Score weight | Detection |
|---|---|---|
| Known threat actor | +65 | Entity attribution database with source citations, assembled from sanctions designations, incident reports, and security research. |
| Known threat actor, flagged on another EVM chain | +65 | The same address carries a threat label on another EVM chain (Ethereum, BNB Chain, Polygon, Avalanche, Base, Arbitrum, Optimism) and has no contract code on the chain analyzed, so one private key controls it on both. Contracts are excluded, because the same address can hold unrelated contracts on different chains. The report names the chain the label was recorded on. |
Mixers and obfuscation
Major driverUse of services whose purpose is breaking the chain of custody. Being a mixer scores highest; direct interaction with one is scored separately and shown with the evidencing transactions.
| Signal | Score weight | Detection |
|---|---|---|
| Cryptocurrency mixer | +60 | The wallet itself is an attributed mixing service. |
| Tornado Cash interaction | +25 | Direct on-chain transactions with Tornado Cash contracts. |
| Railgun interaction | +20 | Direct on-chain transactions with the Railgun privacy protocol. |
| CoinJoin pattern | +15 | Structural detection of CoinJoin-style transactions in Bitcoin history. |
High-risk counterparty exposure
Moderate driverFund flow through counterparties that are themselves high-risk (mixers, threat actors, previously flagged wallets), measured as a share of traced volume so one small transfer does not dominate the score.
| Signal | Score weight | Detection |
|---|---|---|
| Volume via high-risk counterparties | +8 to +25 by share of volume | Counterparty graph analysis. Tiers at any exposure, 10%, and 30% of traced volume. |
Contract risk
Moderate driverSmart contracts whose code or operator cannot be verified. Unverified code is a classic rug-pull and drainer pattern; an unattributed contract is a milder version of the same uncertainty.
| Signal | Score weight | Detection |
|---|---|---|
| Unverified contract code | +22 | Contract source not verified on the chain's canonical explorer. |
| Unattributed smart contract | +12 | Contract with no entity attribution in the label database. |
Cross-chain movement
Context signalBridges are legitimate infrastructure that also serves as an investigative blind spot. WalletDNA scores bridge involvement lightly and instead traces through it: canonical-bridge deposits are decoded from calldata to recover the destination recipient.
| Signal | Score weight | Detection |
|---|---|---|
| Cross-chain bridge | +10 | Attributed bridge contracts on 18 chains; deposit transactions decoded to name the destination-chain recipient where the bridge encodes it. |
Behavioral signals
Context signalWeak signals that shade a score rather than drive it: young wallets have thin history, whale balances raise stakes, burst activity patterns lower attribution confidence.
| Signal | Score weight | Detection |
|---|---|---|
| New wallet (under 1 year) | +8 | First transaction timestamp. |
| Whale-sized balance | +3 | Balance threshold per chain. |
| Low attribution confidence | +3 to +6 | Composite of history depth, burst-activity detection, and entity coverage. |
Mitigating signals
Reduces riskSignals that reduce the score. Attribution to a regulated venue, proof-of-reserves disclosure, long history, and majority flow through verified exchanges all argue the wallet is what it appears to be.
| Signal | Score weight | Detection |
|---|---|---|
| Verified identity | -12 | Entity attribution at the highest confidence tier. |
| Proof of Reserves disclosed | -8 | Wallet appears in a published exchange PoR attestation. |
| Majority volume via verified exchanges | -5 | At least half of traced volume flows through attributed exchanges. |
| Known exchange wallet | -3 to -4 | Entity attribution to an exchange, or a PoR-verified reserve address. |
| Long-established wallet (3+ years) | -3 | First transaction timestamp. |
| DeFi protocol activity | -3 | Interaction pattern with attributed DeFi protocols. |
Spam and impersonation filtering
Context signalMostly a data-integrity layer: scam airdrops and address-poisoning tokens are detected and excluded so they can neither inflate a report nor trigger alerts, and each flagged token states which rule caught it. Conducting a dusting campaign is the exception. What a wallet received says nothing about that wallet, but sending trivial amounts to many addresses at once is behaviour it chose, so it is scored.
| Signal | Score weight | Detection |
|---|---|---|
| Dusting campaign | +40, and the score floors at 41 (ELEVATED) | Ten or more outbound transfers each worth under one cent at the time of transfer, across distinct recipients. The floor is applied after every mitigating signal, so an attributable or long-established wallet cannot subtract its way back into the LOW or MODERATE bands while it is running a campaign. Priced rather than measured in native units, so the same threshold holds on all 18 chains as prices move. A tight window is recorded as corroboration, not required. |
| Address poisoning | 0, reported not scored | Two addresses in one history matching on their first and last six characters and differing in between, which does not happen by chance at that length. Left out of the score deliberately: the owner of the history is the intended target at least as often as the author, so the finding is surfaced with evidence rather than counted against them. |
| Dust received | excluded from value calculations | Any transfer worth under one cent. Excluded so it cannot raise an alert, and never scored against the receiver, who did not choose to receive it. |
| Token impersonation | excluded from value calculations | Symbols claiming major tokens (USDT, USDC, WETH) are checked against a verified contract registry; a mismatch is decisive. |
| Phishing-pattern symbols | excluded from value calculations | URL fragments, claim/reward keywords, and malformed tickers, supplemented by a third-party token security database that never overrides on-chain verdicts. |
Alert severities
Monitoring grades every alert into one of four tiers, so a fresh sanctions designation never reads like a routine score wobble. Email subjects, Telegram messages and dashboard badges all use the same tiers.
CRITICAL
A fresh sanctions designation, or the score enters the CRITICAL band (81+).
HIGH
The score crosses into the HIGH band (61+), even when the numeric move is small.
ELEVATED
A material risk-score change below the HIGH band.
INFO
New transaction activity and routine monitoring events.
Data sources per chain
WalletDNA supports 18 chains. Each chain uses a public node or a primary indexer for on-chain data, plus chain-specific attribution sources. Two things are applied uniformly across every chain: sanctions screening (OFAC, EU, UK), and CoinGecko pricing, which produces the USD figures on a report, as-of-date valuations, and the thresholds monitoring alerts on.
| Chain | Primary data | Attribution |
|---|---|---|
| Bitcoin (BTC) | Blockchair, Blockstream Esplora, BlockCypher | Curated address tags, CoinJoin pattern detection |
| Litecoin (LTC) | Blockchair, Litecoin Space Esplora | Curated exchange wallets |
| EVM chains (ETH, BNB, MATIC, AVAX, BASE, ARB, OP) | Etherscan, with Alchemy as backup | Curated DEX / bridge / mixer contracts, Etherscan public labels; a threat label on one EVM chain also applies to the same plain-wallet address on the others |
| Solana (SOL) | Helius, Solscan | Solscan public labels, curated program list |
| XRP Ledger (XRP) | XRPSCAN, XRPL public node | XRPSCAN verified account tags |
| TRON (TRX) | TronGrid, TronScan | TronScan address tags |
| Cardano (ADA) | Blockfrost, Cardanoscan | Public address tags from chain explorers |
| Polkadot (DOT) | Subscan | Public address tags from chain explorers |
| Cosmos (ATOM) | Mintscan, Polkachu public RPC | Validator and IBC channel registry |
| Stellar (XLM) | Stellar Horizon, stellar.expert | Public address tags from chain explorers |
| TON | TonAPI, Tonviewer | Public address tags from chain explorers |
| SUI | Sui fullnode RPC, Suiscan | Public address tags from chain explorers |
Refresh cadence
On-demand analysis
Triggered every time a wallet is submitted. Counterparty exposure is recomputed from the current graph.
Monitored wallets
Transaction activity is re-checked hourly by cron; risk score and sanctions daily. Material changes trigger alerts to the watcher.
Sanctions lists
The OFAC SDN list and the EU and UK consolidated lists are refreshed daily from official sources.
Attribution data
Chain-specific explorers and curated registries are refreshed at varying cadences; high-traffic entities are prioritized.
Cross-chain bridge tracing
When a wallet sends funds to a known bridge contract, WalletDNA records the exit rather than letting the trail die at an unlabeled address. Canonical bridges (Arbitrum, Optimism, Base, Polygon, and L2→L1 withdrawals to Ethereum) have a deterministic destination and are named; multi-destination routers (LayerZero, Stargate, Hop, Across, Synapse, Celer, Wormhole) encode the destination in calldata or events, not the contract address, so their destination is marked “not resolved on-chain” rather than guessed.
For canonical bridges, “Continue on {destination}” follows the trail across the boundary by reading the destination recipient directly out of the deposit transaction’s calldata — the address the subject encoded into the transaction they signed. This is an on-chain instruction, not an inference. The crossing opens a separate, first-class analysis of that recipient on the destination chain — its own report of record and risk score — linked back to the source report with the cited deposit transaction, so the two ledgers stay distinct and the evidentiary boundary is explicit.
HIGH — EXPLICIT RECIPIENT
The recipient is decoded from an explicit destination parameter (a to / user address) in the deposit function’s calldata — the address the depositor named.
HIGH — SELF-DEPOSIT
The deposit function credits the sender’s own address by definition (e.g. depositEth / depositETH), so the recipient is the depositor.
LOW — SAME-ADDRESS LEAD
Fallback only, clearly labeled: when the recipient can’t be decoded (unrecognized deposit function, or the resolution lookup is unavailable), the same address is offered as a lead to verify — never asserted as the recipient.
Recipient basis & disclaimer. The destination recipient is read from the address specified in the bridge deposit transaction — an on-chain instruction, not an inference. In uncommon cases the ultimate beneficiary differs: a deposit crediting an intermediary or aggregator contract, a failed or re-executed cross-chain message, or non-standard operator routing. Independently verify against the cited deposit transaction and the destination-chain receipt before relying on it in a proceeding. The same disclaimer appears on any report continued across a bridge and in its PDF Methodology declaration.
Report integrity & analyst sign-off
Three independently verifiable layers travel with a report: the content hash proves what it said, a wallet-ownership attestation proves control of the address, and the analyst sign-off records who stood behind the analysis and when.
CONTENT HASH — WHAT THE REPORT SAID
The stored analysis record (result, narrative, analyst commentary) is hashed (SHA-256) and the hash printed on the PDF. Anyone holding the report can check it at walletdna.com/verify with no account, or against the live endpoint /api/report/{id}/hash. A match confirms the record is unchanged since the report was generated.
OWNERSHIP ATTESTATION — WHO CONTROLS THE WALLET
The wallet holder signs a unique challenge message with the wallet’s own key (browser wallet or offline/hardware); WalletDNA verifies the signature cryptographically and embeds the proof, method, and timestamp in the report. Ethereum and all EVM chains, Bitcoin, Litecoin, Solana, Tron.
ANALYST SIGN-OFF — WHO STOOD BEHIND IT, AND WHEN
The analyst records their name, credential, and firm with a timestamp, bound to the report’s exact content state by a sign-off hash (the content hash plus the analyst’s included supplementary findings) — the workpaper prepared-by convention, applied to on-chain evidence. Any later change to the report supersedes the sign-off: a superseded sign-off never renders on a PDF or Excel workpaper, so a deliverable either carries a valid attestation or none. The public verifier at walletdna.com/verify also reports who signed and whether the sign-off still matches the current content.
A sign-off is a recorded professional attestation — like initialing a workpaper. It records identity as entered by the account holder; it is not independent identity verification.
Known limitations
- •MEDIUM-confidence attributions inherit upstream errors. If a third-party explorer mislabels an address, our MEDIUM-tier label inherits the error until a second source contradicts it.
- •Counterparty exposure has a finite hop depth. Very distant interactions may not be reflected in the exposure breakdown.
- •Brand-new addresses are scored on heuristics only. Without transaction history, attribution and behavioral signals are limited; expect LOW confidence and a near-baseline score.
- •Off-chain context is not captured. WalletDNA scores on-chain signals; legal filings, internal KYC, and off-chain intelligence remain the responsibility of your compliance workflow.
Frequently asked
Why is a confidence level only MEDIUM when the entity is named (e.g., Crypto.com)?
MEDIUM means the entity name comes from a single third-party data source — typically a chain-specific explorer like XRPSCAN. The label is generally accurate, but we haven't cross-verified it against a second independent source or against a signed first-party attestation. A match in two or more independent sources promotes the wallet to HIGH; a signed PoR commitment or sanctions list match promotes it to VERIFIED.
How often is data refreshed?
Wallet analyses are computed on demand and cached briefly to keep responses fast. Monitored wallets (Pro plan and above) are re-checked by our crons — transaction activity hourly, risk score and sanctions daily — and trigger alerts on material changes. Sanctions lists are refreshed daily from official sources. Counterparty exposure is recomputed whenever a wallet is re-analyzed.
Can I appeal a label or risk score?
Yes. Email support and we will investigate. If we agree the attribution is wrong, the correction is applied across the platform — not just to the report you filed against. We treat attribution errors seriously because every customer is downstream of them.
What are the known limitations?
Three to be aware of: (1) MEDIUM-confidence attributions inherit any errors in the upstream data source. (2) Counterparty exposure is computed against a finite hop depth; very distant interactions may not be reflected. (3) Brand-new addresses with no transaction history can only be scored on heuristics until they have on-chain activity to analyze.
Why does WalletDNA publish its methodology?
Risk scores are only useful if you understand what they measure. We publish how scores are produced, what each confidence tier means, and where the data comes from so that compliance teams can defend the figures in their workflows — to auditors, regulators, or internal review committees.
Try it on a real wallet
Every report shows the full score breakdown, the confidence tier, and the sources behind every label. No black boxes.
Analyze a wallet freePro plan from $49.99/month · No credit card for free tier