Every vendor publishes a chain count. Almost none say what the number means. Here is ours, qualified: which machine each chain runs, whether contracts are read or only the surface around them, and whether an endpoint can be proven to serve the chain it claims.
id 1
SVM, no id
id 8453
id 56
id 999
id 42161
id 143
id 137
id 4663
id 130
id 9745
id 43114
id 10
id 25
id 100
Marks belong to their projects and identify the chains this platform reads. Listed means selectable and validated, which is not the same as every engine indexing it.
Three tiers, and only the third may appear on anything a customer reads. Enforced in the code that gates the claim, not in a style guide.
Configured. An adapter exists and the chain is selectable, validated and routable. Where a chain sits the day it is added, and on its own it entitles us to say nothing.
Observed. Blocks have actually been read, and contiguity measured on the chain itself rather than assumed from the client library. Coverage of the input is a separate axis from quality of detection.
Supported. Detectors have run against a benign capture from that chain, so a false-positive rate exists for it. Until that number exists, the chain is not named to a buyer.
Neither does anything here. These chains are read by one system, into one model, on one threat graph, and three of the things that catch people only work that way.
Every destination mint must match a source lock or burn on the chain it claims to come from. A correctly signed mint with no source leg still fails, which is the one check that does not care whether the validator set was compromised.
inv.bridge-message-correspondence
When an asset breaks, the markets holding it reprice in the same block whether or not anyone told them. Look-through exposure carries that across chains, so a lending market hears it from the graph rather than its own liquidation engine.
ml.fundflow-anomaly
Funds do not sit still after a drain, and rarely on one chain. Peel-chain analysis follows the counterparty graph across every chain in scope, so an outflow stays attached to the incident that produced it.
ml.peel-chain-laundering
Each could be answered with something plausible. Each is answered with nothing instead, because a system that guesses is worse than one that admits it does not know.
A monitoring gap and a quiet chain look identical from the inside. Block contiguity is measured on the chain itself, so a gap in what we saw is reported as a gap in what we saw. The first live run silently dropped 52.6% of blocks and looked healthy doing it.
A screen that could not reach a live source returns insufficient-data, never a pass. Clear means a named source was consulted at a stated time, which is the only version an auditor can put in a file.
Every one of the 14 EVM chains is checked against its published id on connect. An endpoint reporting the wrong chain is removed; one that does not answer is kept and reported, because unreachable is not proof of wrong. Without that check, a fallback transport answers an Ethereum question with another chain's data.
A rate belongs to the benign capture it was measured on. Averaging would let a well-measured chain carry an unmeasured one, so a chain without its own capture has no rate, and is never called supported.
A scoping call answers it against this table rather than a logo wall, including where the honest answer is that contract monitoring is not there yet.