Skip to main content
Sanctions-clean. KYC-free. We screen the wallet, not the person.

​
What it is

An address is checked against public sanctions lists. That’s a list lookup on a public identifier — not identity verification.

What we check

Whether a blockchain address appears on a sanctions list.

What we never collect

Names, documents, dates of birth, addresses, selfies. No KYC on you or your customers.

​
Two wallet layers

Your wallet is screened when you sign in, and re-checked daily.A sanctioned wallet can’t sign in, so no session is issued. The verdict is cached on your account.This is platform-level and not configurable — it’s the compliance obligation that lets the product exist at all.

​
A third control: where the request comes from

Wallet screening is not the whole compliance surface. Before either layer runs, a coarse IP-geolocation check runs at the edge — on quoting, on payment creation, on both ways a customer can pay, and on merchant sign-in. Requests that resolve to Iran, North Korea, Cuba or Syria, or to the Russian-occupied Ukrainian oblasts (Crimea and Sevastopol, Donetsk, Luhansk, Kherson, Zaporizhzhia), are refused with HTTP 403 and error_code: "unavailable_in_region". The message names no jurisdiction, for the same reason the payer error is vague.
Unlike the two wallet layers, this one fails closed where it can: a request that geolocates to Ukraine but whose oblast can’t be determined is blocked rather than allowed. If no geolocation data reaches the runtime at all, the request proceeds and the gap is logged.
You can’t turn this off — it isn’t a setting. It applies to your own sign-in as well as to your customers’ payments: a merchant whose request geolocates to an embargoed region gets no session. Only the coarse country and subdivision are read; no IP address and no personal data is stored.

​
How it’s done

We use a public on-chain oracle — a smart contract anyone can query — rather than a commercial API.

Why that matters

No API key, no vendor account, no terms that can change to paid or be revoked. One less dependency that could take your checkout offline.

Chain-agnostic

Sanctions lists don’t vary by chain, so every address is screened against the canonical list.
There is no equivalent on-chain oracle on TRON. Two keyless sources are used instead: Tether’s on-chain blacklist, and a free public sanctions API for list parity.Tether’s blacklist is not the same as a sanctions list — roughly a superset, and it can lag. It also doubles as a useful pre-check, since a blacklisted payer’s transfer would fail anyway.This is a documented deviation forced by what TRON provides, and it is how TRON addresses are screened today — including on the testnet the product currently runs on. With payer screening set to Enforce, a pay-by-address deposit on TRON whose sender hits either source is held rather than settled. TRON mainnet is not deployed yet.

​
If screening is unavailable

Both wallet layers fail open. If the check can’t complete — an RPC outage, for instance — the payment proceeds. The region check above is the exception, and behaves as described there.Deliberate: a screening outage shouldn’t halt legitimate commerce, and the merchant sign-in gate remains the enforcement point regardless.

​
A misconception worth correcting

Swapping tokens does not clean their history.If a sanctioned party pays you and the funds pass through a decentralised exchange, your transaction history still shows the original interaction. Exchange deposit screening at Coinbase, Binance, or Kraken will flag it when you cash out.If you’re relying on a swap to sanitise provenance, you’re mistaken about what swaps do.

​
Should you enable payer screening

Reasons to

You’re in a regulated sector, your banking partner expects it, or your risk appetite is low.

Reasons not to

It adds a failure mode to checkout and screens an address, not a person — determined actors move funds first. It’s not a fraud control.
Payer screening also has two modes, not one. In Settings → Compliance you choose Enforce — a sanctioned payer’s payment is refused with the deliberately vague error — or Monitor, where the payment goes through and only an identity-blind record of the decision is kept. Monitor adds no failure mode to checkout. Your call, per account, changeable at any time.

​
Regulatory framing

Refusing service to a sanctioned wallet is the negation of a service, not the provision of one. A list lookup on a public identifier is not itself a regulated crypto-asset activity. What we deliberately don’t do.