Supported networks: which check runs on which chain
A single network count hides which checks run where, so this page shows the full matrix. It is generated from the configuration this deployment is running, and the JSON is at /api/public/networks.
| Network | Sanctions list match | Transaction integrity | Issuer freeze (USDT / USDC) | Ownership by signature | Ownership by micro-transfer | Wallet history and trace | Issuers readable |
|---|---|---|---|---|---|---|---|
| Ethereum | ● yes | ● yes | ● yes | ● yes | ● yes | ● yes | circle, tether |
| Tron | ● yes | ○ no | ● yes | ○ no | ● yes | ● yes | tether |
| BNB Chain | ● yes | ● yes | ○ no | ● yes | ● yes | ◐ endpoint | — |
| Base | ● yes | ● yes | ● yes | ● yes | ● yes | ● yes | circle |
| Arbitrum | ● yes | ● yes | ● yes | ● yes | ● yes | ● yes | circle |
| Polygon | ● yes | ● yes | ● yes | ● yes | ● yes | ● yes | circle |
| Avalanche | ● yes | ● yes | ● yes | ● yes | ● yes | ◐ endpoint | circle, tether |
| OP Mainnet | ● yes | ● yes | ● yes | ● yes | ● yes | ● yes | circle |
| Solana · opt-in | ● yes | ● yes | ● yes | ○ no | ○ no | ○ no | circle, tether |
| Bitcoin | ● yes | ○ no | ○ no | ○ no | ● yes | ○ no | — |
| Linea · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Scroll · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| zkSync Era · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Gnosis · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Celo · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Mantle · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Blast · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
| Polygon zkEVM · opt-in | ● yes | ◐ endpoint | ○ no | ● yes | ◐ endpoint | ◐ endpoint | — |
● yes runs today. ◐ endpoint the chain is supported and this check waits on a configured node or explorer. ○ no cannot exist here: no issuer contract, no explorer, or no signing scheme.
Checks that need no endpoint
A sanctions match is an address comparison against data the publishers release, and one 0x address is the same address on Ethereum, Base, Linea and every other EVM chain. An EIP-191 ownership signature is cryptography over a message. Both work the day a chain is recognised. Transaction integrity and issuer-freeze reads have to call a node, and those are the ones that wait.
The 8 chains waiting on an endpoint
Linea, Scroll, zkSync Era, Gnosis, Celo, Mantle, Blast, Polygon zkEVM. Sanctions screening and signature-based ownership proof already run on these. The node-dependent checks stay off until an endpoint is configured, rather than being pointed at a guessed public one. A wrong endpoint does not fail loudly. It makes the check MISSING, and the policy then holds every deposit on that chain. If you need one of these chains live, tell us which. Turning it on is a configuration change, not a release.
Questions
How many blockchains does KYTGate screen?
Sanctions screening runs on 18 networks, because a sanctions match is an address comparison against published list data and one 0x address is the same address on every EVM chain. Live USDT and USDC issuer freeze reads run on 8, because those need the issuer's own contract on that chain. The table on this page gives every check separately, because a chain supports some checks and not others.
Why do some chains say "endpoint" instead of yes?
Those 8 chains are supported by the code and switched off for the checks that need a node. Transaction integrity and issuer-freeze reads call a blockchain node. A guessed public endpoint would not fail loudly. It would make those checks MISSING, and the policy would TECHNICAL_HOLD every deposit on that chain. We would rather show a chain as off than have it look supported while it silently holds funds. Setting the endpoint switches the checks on, and the status page starts probing it.
Is a check on an unlisted chain silently skipped?
No. Every screening reports the status of each dimension: COMPLETE, PARTIAL, MISSING, STALE, UNSUPPORTED or NOT_AVAILABLE. A check that cannot run on a chain reads UNSUPPORTED or NOT_AVAILABLE rather than passing, and if your policy marks that dimension mandatory the decision is TECHNICAL_HOLD. An unavailable check is never treated as clean.
Does KYTGate support Solana and Bitcoin?
Sanctions screening, yes for both: the official lists carry addresses on both chains, and the match is an address comparison. Solana also has transaction integrity and a freeze read, waiting only on a chosen RPC endpoint. The freeze there works differently and is labelled accordingly. The mint's freeze authority (Circle, for USDC) freezes token ACCOUNTS rather than keeping a global list. A wallet can therefore hold a frozen USDC account and an untouched USDT account at the same moment, and an address that never held the token has nothing to freeze, which is not the same as a clean record. Bitcoin supports ownership proof by micro-transfer and has no issuer blacklist of any kind, so that dimension reads NOT_AVAILABLE there rather than implying a check that never ran.
Where does this page get its numbers?
From the running configuration. The matrix is computed from the same tables the screening path reads: which chains have EVM semantics, a configured node, an issuer contract or an explorer. The JSON is at /api/public/networks. Every network count elsewhere on this site is imported from the same place, so the numbers cannot drift from the configuration they describe.
Generated from this deployment's configuration at render time. Endpoint health, per chain and per role, is on the status page; what each check actually does is on methodology.