Who runs a secondary-market sanctions sweep?

Stablecoin issuers, banks and fintechs with their own branded stablecoin, and the issuance platforms that run tokens for them.

Goldsky

Secondary-market sanctions sweeps for token issuers

Talk to our team

What is a secondary-market sanctions sweep?

A secondary-market sanctions sweep, sometimes called token holder screening, is checking every wallet that holds or moves your stablecoin or token against sanctions lists, including wallets that never became your customers.

Stablecoin and token issuers run sweeps because their tokens pass from wallet to wallet well beyond the customers they onboarded, so a listed wallet can hold them without the issuer ever dealing with it.

Goldsky keeps each holder’s balance of your token current in your database, so your database can check every holder whenever the list changes, and screens each new transfer against your list; the list, the review and any freeze stay with your team and your token contract.

How a sanctions sweep of your token’s holders works

This chart runs from a sanctions list update to a freeze on a listed address, where your token contract supports one, with the holder check and the transfer screen side by side. Your setup may differ.

Screening providerList updatedNew addresses reach your watch list

Token transferredYour token moves between any two wallets

TurboKeep each holder’s balanceHistory first, then each new transfer

TurboScreen each transferA listed sender or recipient raises an alert

Check every holderYour database joins balances to the list

Decide the actionYour team reviews each hit under your policy

Address frozenWhere your token contract supports freezing

Goldsky
Your provider

How to run a secondary-market sanctions sweep

A pipeline Goldsky runs reads every transfer of your token, history first, and keeps each holder’s balance in your database, so your database can check every holder against the list whenever the list changes. The same pipeline screens each new transfer as it lands, and your team reviews every hit and decides whether to freeze.

What you’ll need

Goldsky Turbo
A sanctions list or risk data provider
A database for the watch list and holder balances
A case tool or webhook endpoint for alerts
A token contract with a freeze function, if you freeze listed addresses

Update the sanctions list
The sweep checks holders against the list, so a new listing is what usually starts one.
Your sanctions data provider supplies newly listed addresses, and your loading job writes them, in one address format, to the table your screening reads. A listing that waits for someone to copy it over by hand leaves listed holders unchecked until then.
Your token moves between any two wallets
Holders change every day, and any transfer can put your token in a listed wallet.
Anyone holding the token can send it on without asking you, including to a wallet that’s on the list or about to be. Transfers in the newest blocks can still be replaced for a short time (a reorg), so one seen once isn’t final.
Keep each holder’s balance in your database
Handled by Goldsky Turbo
To know who holds your token right now, you need every transfer that has moved it, added up per wallet and kept current.
The history has to start at the token’s first block and then follow each new block, so balances add up to the supply. A gap leaves some holders with wrong balances and others missing entirely, and the newest blocks can still be replaced for a short time (a reorg), so a transfer from a replaced block has to come back out of the balance.
With Goldsky, a Turbo Pipelines pipeline that starts from the earliest block reads your token’s past transfers and then each new one, and its postgres_aggregate sink, which writes to a Postgres database, keeps a running sum per wallet of what it received minus what it sent. When a reorg removes a transfer, the sink takes it back out of the balance, as long as the pipeline’s SQL keeps the _gs_op column.
Keep running balances in your database (opens in a new tab)
Screen each new transfer
Handled by Goldsky Turbo
The holder check runs when the list changes, so a listed wallet sending or receiving your token in between has to be caught when it happens.
The sender and the recipient of every transfer of your token are compared with the same list, and a match raises an alert with the transaction, the amount and which side matched. Alerts go out when a transfer is seen, before it’s final, so the receiver has to apply a correction if a reorg later removes the transfer.
Goldsky’s Turbo Pipelines can check both sides of every transfer of your token against a dynamic table with dynamic_table_check() and post each hit to your case tool through a webhook sink. Insert a newly listed address and the running pipeline starts matching it.
Match addresses with dynamic tables (opens in a new tab)
Check every holder against the list
A holder is any wallet with a balance above zero, and each one has to be compared with the list.
Each time the list changes, your database joins the wallets that hold a balance to it. Because the balances follow the chain block by block, a check runs against today’s holders rather than an old copy.
Decide the action on each hit
A match tells you a listed wallet touched your token; what to do about it is a policy decision.
Your compliance team confirms the match, records its reasoning and decides whether to freeze, report or take no action, under your policy and the rules that apply to you. Freezing the wrong address locks a holder out of their funds, so each decision needs a named approver, and a proposed FinCEN and OFAC rule would have US issuers make the certifications of their anti-money laundering program available to FinCEN on request.
Freeze the listed address
A freeze stops a listed wallet from moving the token it holds.
Your token contract carries out the freeze where it has a freeze or blocklist function, and the freeze is itself a transaction recorded onchain. If the contract has no such function, a freeze isn’t available, and your policy has to say what happens instead.