Security & data
What the data behind AlphaFlow covers, what it doesn't, and how confidence and known-destination labels are actually produced.
Data sources
On-chain reads (transactions, program interactions, transfers) are sourced live from Solana RPC/indexing infrastructure. This covers everything that happened on-chain; it does not cover off-chain identity, KYC status, or intent — a wallet can be on-chain-clean and still be operated by a sanctioned entity, and AlphaFlow will not know that unless the address is in the known-destination registry.
The confidence model
Every finding — a risk score, a cluster grouping, a traced hop — carries a confidence level rather than a single number presented as certain.
Multiple independent signals corroborate each other — e.g. a shared fee payer plus a matching funding window.
The overall pattern holds, but at least one contributing signal is weaker, indirect, or unverified.
A signal exists but is plausibly coincidental on its own — e.g. a single low-value interaction with a flagged address.
False positives and false negatives
A HIGH confidence finding can still be wrong — shared infrastructure (a popular fee payer, a common program) can occasionally produce a pattern that looks coordinated but isn't. That's why every finding links to the underlying transactions: a reviewer can check the evidence rather than trust the label. On the other side, a wallet that hasn't triggered any known pattern isn't proof of innocence — it may simply not have produced enough on-chain signal yet, or may be using a laundering pattern not yet covered by clustering logic.
What "verified" means for known destinations
Known-destination labels (exchange deposit addresses, bridges, and similar) come from a shared registry. An entry marked verified has had its address-to-label mapping manually confirmed rather than sourced automatically; it's a property of the label's provenance, not of the wallet being labeled.
[PLACEHOLDER: confirm exact review process/criteria used to mark an entry verified — the code confirms the field exists and gates on it, but the specific verification workflow wasn't in scope of what I could confirm from the codebase alone.]