Screen one blockchain address against the U.S. Treasury OFAC SDN (Specially Designated Nationals) list: a direct match on the address itself, plus the engine's two-hop proximity walk over the address's real transfer history. Two separate claims, reported separately.

Three direct-match outcomes, and they must not be collapsed:

• a match: the address is published on the SDN list. The designated entity, its type, its sanctions programs and the chain OFAC filed it under are returned.

• no match: the whole published list was searched and the address is not on it. That is a real finding about one list on one date.

• not screened: the list could not be read, so nothing was checked. Never report this as clear; point the user at https://sanctionssearch.ofac.treas.gov/ instead.

Proximity: when proximity_checked is true the engine walked up to two hops of transfer history (its warehouse or a live read) looking for a listed address, and reports found or not, the hop count, the path and how far it went. Being N hops from a listed address is a fact about the graph, never a designation. When proximity_checked is false nothing was walked and the result says so.

Limits to repeat whenever the result is restated: SDN list only (not the EU, UN or UK/OFSI lists, and not OFAC's non-SDN lists such as SSI, NS-MBS and CAPTA); as published on a stated date; a walk bounded by hops and a node budget. A miss is not a sanctions clearance.

Call this when a user asks about sanctions exposure, designation, or OFAC status for an address, so the answer is grounded in what was actually searched.

Args:

• address (string): an EVM 0x address or a base58 Solana address.