Chainalysis Free Sanctions Oracle: What It Covers and What It Doesn't

Bottom line: the Chainalysis oracle is useful for a fast address check, but it is not a complete sanctions-screening control for a regulated CASP. Chainalysis says the oracle is updated for sanctions designations from lists including the US, EU, and UN. EBA GL/2024/15 and CySEC C685 focus on policies, list management, screening-system reliability, ongoing screening, documented alert decisions, and evidence you can produce to a regulator. A boolean oracle call does not provide that by itself.

What are the two free tools and how do their interfaces differ?

Chainalysis announced two free sanctions screening options in March 2022: an API for web, mobile, and server integrations, and an on-chain oracle for smart contracts. The important difference is what you get back and what you must build around it.

1. REST API

Chainalysis's 2022 announcement described an API where users receive an API key and check whether an address is on a sanctions list. As of this refresh, the old public free-tools landing page redirects to Chainalysis Address Screening, so verify current endpoint, response schema, rate limits, and access terms in Chainalysis's current documentation or your Chainalysis account before relying on implementation details.

# Implementation details must be checked in current Chainalysis docs.
# At minimum, your own system should log:
{
  "address": "0x...",
  "screened_at": "2026-07-10T09:30:00Z",
  "source": "Chainalysis sanctions API",
  "result": "match | no_match | error",
  "decision": "blocked | escalated | cleared"
}

Do not assume that an API response is an audit trail. If you use the API in a regulated workflow, your system should retain the request, response, timestamp, list/update context, escalation result, and final decision.

2. On-chain oracle (smart contract)

Chainalysis documents the oracle on 10 EVM-compatible networks. Ethereum, Polygon, BNB Smart Chain, Avalanche, Optimism, Arbitrum, Fantom, Celo, and Blast use 0x40C57923924B5c5c5455c48D93317139ADDaC8fb. Base uses 0x3A91A31cB3dC49b4db9Ce721F50a9D076c8D739B.

It exposes isSanctioned(address), which returns a boolean. true means the oracle currently marks the address as sanctioned; false means the oracle does not currently mark it as sanctioned. The public oracle call does not return the matching regime, designation name, source list, or update timestamp.

interface ISanctionsList {
    function isSanctioned(address addr) external view returns (bool);
}

// Check before processing a transaction
ISanctionsList oracle = ISanctionsList(
    0x40C57923924B5c5c5455c48D93317139ADDaC8fb
);

require(!oracle.isSanctioned(msg.sender), "Sanctioned address");

The oracle is useful for smart contracts that need an on-chain pre-check. It should not be treated as proof that a counterparty is clear under every sanctions regime relevant to your business.

What sanctions lists do they actually cover?

Chainalysis oracle documentation defines sanctioned entities as entities listed on economic or trade embargo lists, including but not limited to sanctions lists imposed by the US, EU, or UN. That is broader than OFAC-only coverage, but it is not the same as an exhaustive guarantee that every list relevant to your business is covered.

For direct official sources, OFAC publishes the SDN List and other US sanctions data through its Sanctions List Service; the European Commission manages the EU consolidated financial sanctions list; the UN Security Council maintains the UN Consolidated List. For the UK, the current source is the UK Sanctions List: the old OFSI Consolidated List closed on January 28, 2026 and is no longer updated.

OFAC's own digital-currency address search is exact-match via the ID # field; it is not a blockchain analytics or evidence workflow.

The practical gap is not just list coverage. A regulator can ask how your screening system is configured, which lists it uses, when lists were updated, how customer records were rescreened, which alerts were generated, and what decision was taken. The oracle does not generate those records for you.

Why is the lack of built-in evidence a problem?

The API result, if you use it, has to be logged by your own system. You need to preserve enough context to reconstruct what was screened, when, against which source or vendor dataset, what result was returned, and what action was taken.

The oracle is even simpler: it returns true or false. If you need to prove that address X was checked at time Y and then cleared, escalated, or blocked, you need your own logging, case handling, and retention process.

EBA GL/2024/15 expects PSPs and CASPs to understand and document the screening system's capabilities and limitations, manage list updates, define the data to be screened, and document decisions taken on alerts. CySEC C685 similarly expects ongoing screening, up-to-date sanctions lists, regular testing, and evidence when a screening system misses a sanctions record or accepts a documented risk.

What does Chainalysis's own disclaimer say?

"Chainalysis cannot guarantee the accuracy, timeliness, suitability, or validity of the data."

-- Chainalysis oracle documentation

That disclaimer does not make the oracle useless. It means the oracle should be treated as a data input and control, not as a complete compliance conclusion. You still need policies, validation, monitoring, and records around the tool.

Why does this matter for EU-licensed CASPs?

The regulatory landscape for crypto sanctions screening in the EU is specific about what's required. Two documents define the standard:

EBA Guidelines on Restrictive Measures (GL/2024/15)

These guidelines apply from December 30, 2025. They say PSPs and CASPs should put in place policies, procedures, and controls to comply with restrictive measures, including an effective screening system. Relevant expectations include:

• Screening crypto-asset transfers before making crypto-assets available to the beneficiary, subject to the guideline's technical framing
• Screening all parties to transfers against applicable restrictive measures
• Updating internal datasets immediately when restrictive measures enter into force, change, or are lifted
• Understanding and documenting the screening system's capabilities and limitations
• Documenting decisions taken in respect of alerts

CySEC Circular C685

For CySEC-regulated entities, Circular C685 and the related February 27, 2025 guidance are more practical. CySEC's thematic inspections focused on UN and EU sanctions lists and relevant screening practices for US and UK sanctions lists. The guidance expects onboarding and ongoing screening, whole-database screening on every relevant list update, up-to-date list feeds, testing of screening tools, and documented remediation where weaknesses are found.

A regulator will not only ask whether a boolean check was performed. They can ask how the system was selected, how it was tested, which list sources were enabled, when rescreening happened, and how possible matches were resolved.

What is the free oracle actually good for?

None of this means you should avoid the oracle. It is useful when the use case matches the interface:

• On-chain gating. Smart contracts can call isSanctioned(address) before allowing an action.
• Secondary checks. It can be one control in a broader sanctions-screening workflow.
• Public availability. Chainalysis says the oracle is available without a customer relationship.
• Fast direct-address checks. The oracle answers a narrow question without off-chain case management.

The limitation is what the oracle gives you back. A boolean result is not a compliance program. Use it as a screening layer, but build or buy the evidence, monitoring, list-management, and alert-handling infrastructure around it.

What about other free tiers?

Other vendors have also announced free or low-friction sanctions-screening options over time. Treat all of them the same way: verify current access, covered chains, covered lists, response fields, rate limits, and terms directly with the vendor before relying on them.

The same fundamental limitation usually applies: a result is not the same as documented controls. For EU/Cyprus regulatory use, the decisive question is whether you can evidence policies, list management, rescreening, alert handling, testing, and final decisions.

How does the free oracle compare to EBA requirements?

Here's a practical view of what the Chainalysis oracle provides against expectations in EBA GL/2024/15 and CySEC C685.

The oracle can contribute to pre-transfer screening if it is integrated at the right point in the workflow. The missing pieces -- evidence, rescreening, list management, alert handling, testing, and broader risk context -- require your own controls or a separate compliance platform.

Bottom line

Chainalysis's oracle is a useful sanctions-address control. It is public, on-chain, and documented for major EVM networks. Chainalysis says its sanctions data includes US, EU, and UN lists.

But list coverage alone is not compliance. If you're an EU-licensed CASP, you need documented policies, list management, rescreening, alert handling, testing, and records of decisions. CySEC-regulated firms also need to align with C685's expectations on ongoing screening and relevant UK screening practices, using the current UK Sanctions List rather than the closed OFSI consolidated list.

Use the free oracle where a boolean on-chain check helps. Do not mistake it for a complete screening program. The oracle gives you one check; your compliance process still has to produce the records.