Why Passing the Chainalysis Oracle Doesn't Mean Your Wallet Is Clean

TL;DR - Chainalysis's free sanctions oracle only answers one yes/no question, and a "no" does not mean a wallet is safe to accept.

On March 10, 2022, Chainalysis switched on a free smart contract that checks any wallet address against U.S., EU, and UN sanctions lists in real time. Any developer can call it, no account or contract with Chainalysis required. That part is useful. The part where a "false" result gets treated as a clean bill of health is not.

What the Chainalysis oracle actually checks

The oracle is a single smart contract function: isSanctioned(address). Call it with a wallet address and it returns true or false, based on whether that address appears on the U.S. Treasury's OFAC list, an EU sanctions list, or a UN sanctions list. Chainalysis maintains the underlying data and pushes updates to the contract. Anyone building a dApp, a wallet, or a Safe multisig module can query it, free of charge, since 2022.

A free contract call is a useful first filter. It is not a wallet risk report. For a fuller picture than a single boolean, screen the wallet with Plastron instead - it checks sanctions, mixer exposure, and stolen-funds exposure across Ethereum and 6 other chains in one pass.

Which chains does the oracle cover?

10 networks, as of this writing:

• Ethereum
• Polygon
• BNB Smart Chain
• Avalanche
• Optimism
• Arbitrum
• Fantom
• Celo
• Blast
• Base

9 of the 10 share one contract address; Base runs a separate deployment. That is a wide EVM footprint, and it overlaps heavily with the 7 chains Plastron already screens - Ethereum plus 6 supplementary networks. Width is not depth, though. The oracle answers with the same boolean no matter which chain you call it from.

What a "not sanctioned" result does not tell you

A false result from isSanctioned means only one thing: the address is not currently on one of three government lists. It says nothing about mixer exposure, stolen-funds exposure, exchange-hack proceeds, darknet-market activity, or how many hops separate the address from a sanctioned one. Chainalysis says as much in its own documentation, which describes the oracle as returning a boolean with no screening evidence, no list-management records, no risk scoring, and no UK Sanctions List coverage. That single flag skips an entire sanctions regime and carries no exposure scoring, no audit trail, and no context about how the funds got there.

When OFAC added the Tornado Cash smart contracts to its SDN list in August 2022, the oracle correctly started returning true for those exact contract addresses. It said nothing about the thousands of wallets that had already withdrawn funds through the mixer before the designation. Those wallets never touched a sanctions list themselves, so isSanctioned still returns false for every one of them - even the ones an exchange's compliance team would flag on sight.

Does the oracle catch mixer or stolen-funds exposure?

No, and that gap matters more than the sanctions gap for most wallets. A wallet that received funds 3 hops from a mixer, or that touched proceeds from a bridge hack, still returns false from isSanctioned as long as neither it nor its direct counterparty sits on a sanctions list. Exchanges do not stop at sanctions matches. Compliance teams screen for mixer residue, stolen-funds exposure, and clustering with known scam or exchange-hack addresses - categories the oracle was never built to answer.

Plastron's own screening corpus carries 3,901 labeled addresses across scam, fraud, hack-exploit, and mixer categories, plus a 780-address OFAC SDN list refreshed daily. None of that depth lives inside a single boolean.

Can a smart contract wallet rely on the oracle alone?

Some do. Safe modules and DeFi front-ends often call the oracle directly to gate transactions in real time, and for blocking a direct transfer to an SDN-listed address, that works fine. But relying on it alone means a multisig can approve a transfer to a wallet heavily exposed to a hacked bridge or a darknet market and never see a warning, because none of that trips the boolean. Treat a passed oracle check as a floor, not a ceiling.

Why a full wallet screen checks more than sanctions lists

Sanctions are one designation type out of many that matter for AML risk. A wallet can be perfectly clean on the OFAC, EU, and UN lists and still carry heavy exposure to a mixer, a rug-pull contract, or a hacked exchange's stolen funds - the kind of exposure that gets deposits frozen or accounts closed even without a sanctions hit. A real risk score needs hop distance, entity clustering, and multiple designation categories, not a single yes/no gate. That is the difference between a compliance checkbox and an actual risk assessment. A 2-hop link to a sanctioned address is not the same risk as a direct transfer from one, and a single boolean cannot tell you which one you are looking at.

How a DeFi front-end typically uses the oracle

The flow is simple by design. A user initiates a transaction, the smart contract calls isSanctioned(address), and the boolean decides what happens next: true blocks the transaction, false lets it through. That is the entire decision tree. No wallet history, no counterparty check, no mixer flag - just one government-list lookup before the contract waves the transaction on.

That single decision point is exactly why a passed check gets over-trusted. It was built to answer one question well. It was never built to answer the rest of them.