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 / UN 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; 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
Scores are produced from a baseline of 5 plus the signed contributions below, clamped to the 0–100 range. Every report shows the full breakdown — there are no hidden factors.
| Component | Contribution |
|---|---|
Entity type Known threat actors and mixers contribute the largest entity-driven adders. Generic protocol contracts add a small amount; known exchanges receive a small deduction. | -4 to +65 |
Sanctions list match An address matched against OFAC SDN, EU, UK, or UN sanctions lists triggers a score floor — the final score will not fall below the floor regardless of other signals. The jurisdiction(s) that matched are surfaced in the breakdown. | Floor at 82 |
Counterparty exposure Percentage of inbound/outbound volume that touches sanctioned, high-risk, or verified-exchange counterparties. Computed from the full counterparty graph (hop-cache analysis), not a rolling transaction sample — so the figure is stable across re-analyses. | -5 to +45 |
Behavioral signals Mixer proximity (Tornado Cash, Railgun), CoinJoin pattern, unverified contract code, wallet age, balance tier, and direct exchange transactions each contribute small adjustments. | -8 to +25 per signal |
Attribution confidence Higher attribution confidence reduces noise in the score; an unattributed wallet with low confidence carries a small upward adjustment. | -12 to +6 |
Score bands: LOW (0–20) · MODERATE (21–40) · ELEVATED (41–60) · HIGH (61–80) · CRITICAL (81–100).
Data sources per chain
WalletDNA supports 18 chains. Each chain uses native RPC or a primary indexer for on-chain data, plus chain-specific attribution sources. Sanctions screening (OFAC, EU, UK, UN) is applied uniformly across all chains.
| Chain | Primary data | Attribution |
|---|---|---|
| Bitcoin (BTC) | Blockchair, Mempool.space | Curated address tags, CoinJoin pattern detection |
| Ethereum (ETH) | Etherscan, native RPC | Curated DEX / bridge / mixer contracts, Etherscan public labels |
| 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 |
| Litecoin (LTC) | Blockchair | Curated exchange wallets |
| EVM L2s & sidechains | Native RPC + Blockscout (BASE, ARB, OP, AVAX, BNB, MATIC) | Shared curated registry of bridges, routers, and exchange deposit wallets |
| Cosmos ecosystem | Mintscan, public RPC (ATOM, XLM) | Validator and IBC channel registry |
| ADA / DOT / TON / SUI | Native explorers and indexers | Public address tags from chain-specific 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
OFAC SDN, EU, UK, and UN 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