GET /screen/address
Checks a cryptocurrency address against the sanctioned addresses published by OFAC (SDN and Consolidated) and by the EU financial sanctions list. Every hit names the designated entity behind the address, its programmes and its designation date. Bitcoin, EVM, Tron, Solana and Monero.
The lists are ingested into a local snapshot, so the lookup is purely local → response in milliseconds, and the address you are about to pay is never sent to a third party.
x402 golden rule: the agent pays for the answer to its question. “This address is not on these lists, as of this date” is a successful answer → 200. The 4xx range is reserved for requests the service cannot answer — and an unrecognizable address is one of them, unbilled.
Why this and not a free OFAC checker
Free feeds are OFAC-only. The EU publishes sanctioned addresses too, and they are not a subset: the Garantex Bitcoin addresses in the example below are an EU-FSF designation. An OFAC-only checker returns silence on them.
Beyond coverage, every hit here is attributed: the entity, the list that designated it, the programmes and the date — not a boolean, not a score.
Scope and limits
This endpoint answers one question: is this exact address published by one of these lists, as of the snapshot date served in the same response?
- Only addresses the lists publish themselves. No derived addresses, no associated addresses.
- No transaction analysis, no clustering, no risk scoring. An address that received funds from a designated address is not a hit — that is a different product and a different claim.
- Absence from an official list is not a safety signal.
- EVM addresses are matched case-insensitively; the EIP-55 checksum is not verified and never causes a rejection.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
address | string | yes | Address to screen, up to 128 characters; internal whitespace is collapsed (an address copied out of a PDF carries some) |
chain | string | no | bitcoin | evm | tron | solana | monero |
Comparison happens on a normalized form whose rule the chain family dictates:
EVM lowercased with 0x enforced, base58 case preserved (it is
significant), bech32 lowercased. The normalized form is returned.
chain is law when you give it
Given, chain is law: an address that does not have that family’s shape is
refused (400, unbilled) rather than reinterpreted as another family. Omitted,
the family is inferred from the shape and the answer says so in
query.chain_family_source (inferred vs provided).
other is never inferred. Outside the five named families, a value is an
address only if a list publishes it verbatim; otherwise it is a 400
UNRECOGNIZED_ADDRESS_FORMAT, unbilled — a password or a misplaced IBAN must
not be billed as a verdict.
200 response — UnifiedResponse
{
"data": { ... },
"provenance": {
"source": "ofac-sdn+ofac-consolidated+eu-fsf+un-sc",
"fetched_at": "2026-07-30T17:48:45Z",
"freshness": { "kind": "snapshot", "as_of": "2026-07-28T00:00:00Z" }
}
}
Fields of data
| Field | Type | Description |
|---|---|---|
query | object | address, address_normalized, chain_family, chain_family_source |
verdict | string | sanctioned | not_listed |
hits | array | Matched designations (empty on not_listed) |
lists_screened | array | { "list": string, "addresses": int } — returned on every verdict |
limits | string | Fixed sentence stating what is and is not covered |
Fields of a hit
| Field | Type | Description |
|---|---|---|
entity_id | string | Identifier of the designated entity, prefixed by its list |
entity_name | string | The designated entity the address belongs to |
list_source | string | OFAC-SDN | OFAC-CONS | EU-FSF | UN |
programs | string[] | Sanctions programmes, as published |
listed_on | string | null | Designation date, as published |
chain | string | The chain label the list published (BTC, ETH, XMR, …) |
address_published | string | The address exactly as the list published it |
Case 1 — EU-designated Bitcoin address (sanctioned)
GET /screen/address?address=3My1ffQr5qQzmq4aBFgRqwRYqfB5zPAt8t
{
"query": {
"address": "3My1ffQr5qQzmq4aBFgRqwRYqfB5zPAt8t",
"address_normalized": "3My1ffQr5qQzmq4aBFgRqwRYqfB5zPAt8t",
"chain_family": "bitcoin",
"chain_family_source": "inferred"
},
"verdict": "sanctioned",
"hits": [
{
"entity_id": "EU:EU.12747.39",
"entity_name": "Garantex",
"list_source": "EU-FSF",
"programs": ["UKR"],
"listed_on": "2025-02-24",
"chain": "BTC",
"address_published": "3My1ffQr5qQzmq4aBFgRqwRYqfB5zPAt8t"
}
],
"lists_screened": [
{ "list": "EU-FSF", "addresses": 7 },
{ "list": "OFAC-CONS", "addresses": 0 },
{ "list": "OFAC-SDN", "addresses": 961 },
{ "list": "UN", "addresses": 0 }
],
"limits": "Screening covers the designation lists and snapshot date reported above, and only addresses those lists publish themselves. Absence from an official list is not a safety signal. No transaction analysis, no address clustering, no derived or associated addresses, and no risk scoring are performed. EVM addresses are matched case-insensitively; the EIP-55 checksum is not verified and never causes a rejection."
}
Note the base58 case, preserved in address_normalized, and the source of
the hit: EU-FSF, not OFAC.
Case 2 — OFAC-designated EVM address (sanctioned)
GET /screen/address?address=0x0330070FD38Ec3bB94F58FA55D40368271E9e54A
{
"query": {
"address": "0x0330070FD38Ec3bB94F58FA55D40368271E9e54A",
"address_normalized": "0x0330070fd38ec3bb94f58fa55d40368271e9e54a",
"chain_family": "evm",
"chain_family_source": "inferred"
},
"verdict": "sanctioned",
"hits": [
{
"entity_id": "OFAC-SDN:57056",
"entity_name": "AMNOKGANG TECHNOLOGY DEVELOPMENT COMPANY",
"list_source": "OFAC-SDN",
"programs": ["DPRK4"],
"listed_on": "2026-03-12",
"chain": "ETH",
"address_published": "0x0330070FD38Ec3bB94F58FA55D40368271E9e54A"
}
]
}
The EVM address is lowercased for comparison; address_published keeps the
list’s own mixed case.
Case 3 — not on any list (not_listed)
GET /screen/address?address=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
{
"query": {
"address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045",
"address_normalized": "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
"chain_family": "evm",
"chain_family_source": "inferred"
},
"verdict": "not_listed",
"hits": [],
"lists_screened": [
{ "list": "EU-FSF", "addresses": 7 },
{ "list": "OFAC-CONS", "addresses": 0 },
{ "list": "OFAC-SDN", "addresses": 961 },
{ "list": "UN", "addresses": 0 }
]
}
lists_screened is returned here too — including the lists that publish zero
addresses, so a not_listed cannot be mistaken for broader coverage than it has.
Case 4 — declared chain, honoured as law
GET /screen/address?address=3My1ffQr5qQzmq4aBFgRqwRYqfB5zPAt8t&chain=bitcoin
returns the same hit as case 1, with chain_family_source: "provided".
The same address with &chain=evm is 400, unbilled:
{ "error": "parameter 'address' is not a recognizable evm address", "code": "UNRECOGNIZED_ADDRESS_FORMAT" }
Errors
| Status | code | Case |
|---|---|---|
| 400 | MISSING_PARAMETER | address missing or empty |
| 400 | INVALID_INPUT | chain outside the five families |
| 400 | UNRECOGNIZED_ADDRESS_FORMAT | The value is not a recognizable address — for the declared family, or for any family when none is declared |
| 500 | INTERNAL | Internal error (detail logged, not exposed) |
{ "error": "parameter 'chain' must be one of: bitcoin, evm, tron, solana, monero", "code": "INVALID_INPUT" }
See also
POST /screen/address/batch— check up to 500 addresses with a single x402 settlement.GET /screen/entity— screen a company or person name against the same lists.- For agents — discovery surfaces, the live
/catalogand how settlement works.