A KYT program only sees what its coverage allows. If the screening tool reads Ethereum but not TRON, every address that laundered through TRON reads as clean. The engine would have found the exposure, but it never sees the data. Coverage is the floor under every other capability - latency, scoring, alert routing. A chain the tool does not read is a chain where risk hides unchallenged. This guide covers why multi-chain coverage matters and which blockchains a KYT program must cover. It also maps where cross-chain blind spots create exposure and how to evaluate coverage against the asset mix an exchange or protocol handles. For the full KYT surface, see Phalcon Compliance. This page is part of the KYT Resource Center.
Why Multi-Chain Coverage Matters
Illicit funds do not stay on the chain where they were stolen. A hack that drains a DeFi protocol on Ethereum routinely bridges through a sidechain, then swaps into a stablecoin on a high-throughput L2. It often exits through a TRON or Bitcoin wallet unconnected to the original incident. Value moves across ledgers faster than any fiat system allows, and a control that watches only one ledger watches a fraction of the actual flow. The FATF risk-based approach for virtual asset service providers frames this as the core structural risk of the asset class.
FinCEN's AML program rule for money services businesses (31 CFR 1022.210) lands on the same expectation for crypto exchanges and other US money services businesses. Monitoring has to follow the risk, not the convenience of a single chain's data. The operational consequence is direct. Coverage gaps show up not as alerts but as silence, and examiners read that silence as a program weakness. The absence of a control on a chain where the institution transacts is indistinguishable from the absence of the control altogether.
Which Chains KYT Must Cover
Coverage is not uniform. Some chains carry a disproportionate share of illicit flow because of their role in the ecosystem, the assets they host, or the friction they remove. A sound KYT program prioritizes chains along three axes: where the institution's exposure sits, where illicit value concentrates, and where funds route when they exit.
The first priority is the high-volume, high-incident chains. Ethereum and Bitcoin together account for the majority of historical illicit crypto value. Bitcoin remains the dominant rail for ransomware cash-out, darknet market settlement, and sanctions evasion. Ethereum carries the bulk of DeFi-related theft, bridge exploits, and stablecoin laundering. Most stablecoin issuance and DeFi activity live on it or on EVM networks that inherit its address model.
The second priority is chains where illicit flow concentrates for structural reasons. TRON is the clearest example. It hosts a large share of USDT issuance and its transactions are cheap. It has also been repeatedly identified in sanctions designations and enforcement actions as a network used by designated actors to move stablecoins. A program that does not read TRON cannot screen the stablecoin flow passing through it. BNB Chain occupies a similar position for retail-driven activity and token migrations routed through its low-fee environment.
The third priority is the stablecoin chains and L2s where activity is migrating. Stablecoin activity on Polygon, Base, Optimism, and Arbitrum has grown as issuers and exchanges route volume through low-fee environments. Avalanche C-Chain carries a share of cross-chain bridge traffic. L2s are where new user growth and protocol deployments are landing, which means they are also where new illicit activity is landing.
Where Single-Chain Coverage Fails
A cross-chain blind spot is the gap between what an institution's KYT tool can read and what the institution's users transact on. The most damaging is the asymmetric one: a tool that covers EVM networks but misses Bitcoin or TRON, or vice versa. Both patterns appear in the wild, and both produce the same failure mode. A clean risk score comes back for an address whose actual exposure sits on a chain the tool did not query.
The mechanics of how a blind spot becomes a missed alert are simple. A bad actor bridges funds from Ethereum to TRON, runs them through stablecoin transfers, and presents a TRON address for withdrawal screening. If the tool reads Ethereum but not TRON, it sees nothing or an unrelated history, returns a low risk score, and the withdrawal is released. The alert that should have fired never exists, because the engine never saw the data that would have driven it.
This is a documented laundering path. The OFAC sanctions list and FATF guidance both describe cross-chain movement as a standard technique used by designated actors. A program covering only the EVM side of that path screens only half the trail. The half it screens is the half designed to look clean.
Phalcon Compliance Native Chain Coverage
It currently supports screening across ten chains: Ethereum, TRON, BNB Chain, Polygon, Base, Optimism, Avalanche C-Chain, Arbitrum, Bitcoin, and Solana. The list covers the four priority groups above. These are high-volume, high-incident chains (Ethereum, Bitcoin), the structurally high-risk stablecoin chain (TRON), and the high-throughput retail chain (BNB Chain). The set also covers the L2 and sidechain group where stablecoin and DeFi activity has been migrating. New chains are added on a regular cadence as activity and risk shift. The list an institution evaluates today should be re-checked against the current supported set before commitment, not treated as fixed.
In practice, the native chain set is designed to close the asymmetric blind spot described above. An address screened against the engine is screened against the chains it has transacted on, not only the chain where it was submitted. A TRON address with prior Ethereum exposure is read across the relevant chains rather than against one.
The risk data behind the screening is built on more than 600 million labeled addresses and over 17 risk indicator categories. These cover behavioral patterns, exposure to known illicit services, and counterparty risk. Coverage and data work together. Coverage without labeled data returns a score but no evidence, and labeled data without coverage reads the right chains for the wrong addresses. The engine pairs the two so the screening verdict is supported by the underlying exposure and indicator detail, making the decision auditable rather than opaque.
The supported-chain list moves on a regular cadence as new chains are added, so check the current documentation before treating any specific chain as covered or uncovered.
Evaluating Coverage for Your Asset Mix
The right way to evaluate coverage is not to compare chain counts across vendors. Two tools that list the same number of chains may cover entirely different sets. A tool that covers fewer chains may cover the ones that matter, while a tool that covers fifteen misses the ones that do. The evaluation has to start from the institution's own exposure, not from a vendor's marketing list.
The first step is to build the internal chain-exposure list. Pull the deposit and withdrawal flow for a meaningful window - a quarter is a common baseline. Then tally the chains where the institution's users transact, ranked by volume, address count, and incident history. The output is a list ranked by actual exposure, not by reputation.
The second step is to map that list against the supported-chain set of any tool under evaluation. The question is not how many chains the tool covers in total but whether it covers every chain on the institution's own exposure list. A tool may cover 90 percent of the exposure list but miss the chain that carries a disproportionate share of risk. That tool is not 90 percent as good. It is strong on the chains that matter less, and blind on the chain that matters more.
The third step is to pressure-test coverage against known laundering paths. Take a sample of addresses with documented cross-chain exposure. Include one that bridged Ethereum to TRON, one that moved through a mixer to Bitcoin, and one routed via a sanctioned entity on BNB Chain. For each, verify whether the tool reads the relevant cross-chain history or only the chain where the address was submitted. Coverage on paper has to translate into coverage in the screening result.
The fourth step is to confirm the new-chain addition cadence against the institution's roadmap. If the institution plans to list an asset on a chain the tool does not yet cover, ask when the tool will cover it. Also confirm what the interim control is until that point. The supported-chain set is a moving target, and an evaluation that treats it as static will be wrong within a quarter.
Coverage Gaps and Workarounds
No tool covers every chain, and no coverage list stays current forever. A mature KYT program keeps a documented position on gaps: which chains are uncovered, why, what the interim control is, and when the gap closes. The absence of that position is itself a finding, because it implies the institution has not mapped its own exposure.
For chains not yet supported, the interim control is typically a combination of three measures. The first is enhanced due diligence on counterparties that touch the uncovered chain, applied at onboarding rather than at transaction time. The second is a hold-and-review policy for deposits or withdrawals on the uncovered chain, where an analyst confirms the counterparty before settlement. The third is monitoring the vendor's roadmap with a documented integration date rather than an open-ended wait.
The workaround is not a substitute for coverage. A hold-and-review policy on an uncovered chain is a manual control on a flow that should be automated, and it scales poorly as volume grows. Its purpose is to keep the institution covered until the tool catches up. A gap that persists across multiple quarters without a closure plan is one the institution has accepted. The cadence of new-chain additions is itself a selection criterion. A tool that adds chains on a predictable schedule closes gaps on a timeline the institution can plan against. One that adds chains only under customer pressure leaves the gap to be discovered after the fact.