RedStone Launches Sanctions Oracle Unlocks Onchain Compliance

RedStone Launches Sanctions Oracle: Institutional AML Compliance Tool

RedStone has launched its Sanctions Oracle, an onchain contract that lets regulated protocols screen wallets against 463 official sanctions lists and revert any transaction that touches a sanctioned address.

TL;DR

EXECUTIVE SUMMARY

RedStone Sanctions Oracle is a smart contract that runs a wallet address against a list of wallets sanctioned by various bodies, such as the US Office of Foreign Assets Control (OFAC) and Council of the European Union.
The output is a simple boolean value: true if the address is flagged by any of the 463 official sanctions lists supported and false if not.
The tool enables AML compliance at the transaction level, enabling regulated protocols to run an oracle call as part of a transaction workflow and instantly revert if it reads true, in line with the industry-wide standard.
The lists are updated weekly and timestamped, which unlocks quantifiable staleness policies, while the standard interface enables a migration in one line of code.

RedStone Sanctions Oracle: The AML Compliance Engine

RedStone Sanctions Oracle, live today on Ethereum mainnet, sources its sanctions lists from the OpenSanctions portal, which aggregates data from 463 sources. Those include OFAC, the EU, the UN, the UK’s Foreign, Commonwealth & Development Office (FCDO), and many other international and nation-level bodies, ensuring there isn’t a single entity dictating the entire list. Besides the regular isSanctioned(), the contract exposes an areSanctioned() function, which enables batch checks.

The oracle aggregates OpenSanctions’ updates and pushes the reviewed new designations onchain every week, ensuring that its users use the latest references. Each update comes with a timestamp, exposed via the getLastUpdateBlockTimestamp() function, making staleness policies easy to quantify and enforce in code. The oracle’s underlying infrastructure relies on a 4-of-6 geographically-distributed multisig setup, in line with RedStone’s ISO-certified approach to cybersecurity, with every list update signed from cold storage.

The contract utilizes the same interface as the Chainalysis one, so migration is a matter of changing a single line of code: just edit the SANCTIONS_CONTRACT constant, from 0x40C57923924B5c5c5455c48D93317139ADDaC8fb to 0x574Ad490fE8087B580DB227a8Ca7EfB7C19Dc8C4. Learn more about the oracle and its exposed functions here.

AML Isn’t a Suggestion

International sanctions compliance is traditionally focused on four sanctioning bodies. These include the OFAC, which is the enforcement arm of the US Treasury and the Council of the European Union, which handles the Union’s restrictions under the Common Foreign and Security Policy. Besides these, there are also the restrictions authorized by the UN Security Council, and the FCDO in the UK, which aggregates sanctioned persons and entities across UK government bodies.

OFAC alone lists over 20,000 persons and entities on its Specially Designated Nationals (SDN) list, along with more than 1,000 crypto wallet addresses linked to them. The other lists add thousands more, overlaps between them add complexity, and every nation state runs its own watchdogs and blacklists on top. The lists also change constantly: OFAC publishes Sanctions List Updates several times a week.

Compliance is not optional. OFAC rules apply to all US persons, including US-incorporated companies and their foreign branches, and non-US persons are prohibited from causing US persons to violate sanctions or from evading them. Under the GENIUS Act, as implemented by a rule proposed jointly by FinCEN and OFAC, issuers must maintain “technical capabilities, policies, and procedures to block, freeze, and reject specific or impermissible transactions.”

Similarly, EU sanctions regulations and the Transfer of Funds Regulation, which apply to MiCA-licensed CASPs, mandate sanctions screening; companies found to violate those face revocations of their licenses and fines. The same applies to many other jurisdictions, such as the UAE, with virtual asset service providers required to enforce real-time blockchain and wallet-level sanctions screening aligned with the rules set by the appropriate regulators.

An asset issuer looking to operate within a regulated framework must enforce AML compliance on the technical level, especially if they have any aspirations for institutional adoption.

The Compliance Filter

The technical side of onchain AML compliance is not overly complex, at least at a glance. The pipeline goes like this: first, watchdogs publish lists of crypto wallets linked with sanctioned people and entities. Then, these lists are aggregated into unified registries. From there, the list has to be pushed onchain, into a relatively simple smart contract. This contract exposes an isSanctioned() function, which, when called, takes an address as the input, runs it against the latest aggregated list, and returns true if it is and false if it isn’t.

This contract, known as the sanctions oracle, can be called by any other smart contracts as part of a transaction workflow. In other words, when processing a transaction, any protocol can query it and, as long as the appropriate logical gate has been built, revert the transaction if it involves a sanctioned wallet.

So far, this has been the most widespread AML implementation across compliant protocols. The industry’s most widely-used sanctions oracle is run by Chainalysis, covering US, UN, and EU sanctions lists. Its list updates are pushed from a single externally owned account. As of the time of writing, the oracle received its latest update on March 18, 2026.

Since then, OFAC alone has published more than 60 individual Sanctions List Updates notices. One of them, the May 20, 2026 designations, added six Ethereum addresses tied to two individuals linked to the Sinaloa Cartel. When we checked the Chainalysis oracle in September, none of the six was flagged as sanctioned:

0xaC4cC4B68ea24BbFAAC8fD127B67Ed445ACcCE22
0x038989cbb1710c72b9920dc4fa529158f463e72c
0x14779CEC0B117d5194c750C55Ea1f42086631964
0x32dA24Ca413F3E7B53145D4737e172C3bdF81e3e
0xf2235d55b2950a0b1317469d72d07ae65b2e27cb
0x4F428c11Dc82388fa5136D636e613ad923Eb700B

The RedStone Sanctions Oracle flags all six. With weekly, timestamped updates, protocols can verify how current their sanctions data is directly onchain and set their own tolerance for staleness.

Migrate now: Change your sanctions oracle address to 0x574Ad490fE8087B580DB227a8Ca7EfB7C19Dc8C4 or check out the Oracle’s documentation here for more information.

Frequently Asked Questions

What is a sanctions oracle?

A sanctions oracle is a smart contract that checks whether a wallet address appears on official sanctions lists. Other contracts can call it during a transaction and revert if the address is flagged. This makes it a common way to enforce anti-money laundering (AML) and sanctions compliance at the transaction level.

Which sanctions lists does the RedStone Sanctions Oracle cover?

It draws on 463 official sources aggregated by OpenSanctions. These include OFAC, the Council of the European Union, the UN Security Council and the UK’s FCDO, plus many national regulators. No single body defines the whole list.

How often is the RedStone Sanctions Oracle updated?

A reviewed batch of new designations is pushed onchain every week. Each update is timestamped and can be read via getLastUpdateBlockTimestamp(), so protocols can set their own staleness rules in code.

How do I migrate from the Chainalysis sanctions oracle to RedStone?

The RedStone contract uses the same interface, so migration means changing one address: replace the SANCTIONS_CONTRACT constant 0x40C57923924B5c5c5455c48D93317139ADDaC8fb with 0x574Ad490fE8087B580DB227a8Ca7EfB7C19Dc8C4. Existing isSanctioned() calls keep working without other changes.