Loading…
VikingIntel/Known LimitationsVikingIntel/Known LimitationsWhere VikingIntel's scores can be wrong, and why.
On-chain data comes from Helius and Birdeye. Both have coverage gaps and rate limits; a wallet or token with unusually sparse or delayed data can produce a score built on an incomplete picture rather than a genuinely low-activity wallet. Missing price data on a token specifically suppresses parts of the token-risk score rather than silently treating it as zero risk.
Clustering is evidence-based correlation, not proof of common ownership. Shared infrastructure (a popular funding CEX, a shared dApp fee-payer pattern used by many unrelated users) can produce false-positive correlation. Conversely, a well-resourced sybil operation that varies funding sources, timing, and behavior per wallet can fall below detection thresholds — a false negative. Smart-money dampening reduces false positives from legitimate coordinated trading but is not perfect.
Exchange, bridge, and sanctioned-address labels are maintained manually and can lag reality: a newly-sanctioned address may not be labeled yet, and a previously correct label can go stale if an address changes hands or a service shuts down. Every label carries a source, a confidence, and a verification timestamp — check those before treating a label as current fact, not just the label text itself.
Risk and sybil thresholds are tuned against accumulated real-world outcomes, not re-derived from first principles on every request. Immediately after a threshold change, or in market conditions meaningfully different from what recent calibration data reflects (a new token category, an unusual volatility regime), scores can be less reliable than usual.
VikingIntel covers Solana only. It does not trace funds once they leave Solana through a bridge or CEX withdrawal to another chain — cash-out mapping shows that exposure exists, not what happens to the funds afterward.
Requests containing an empty path segment (e.g. // between two segments) are normalized by the Next.js framework with a 308 redirect before application code runs, so such requests can never receive VikingIntel's JSON error envelope. Well-formed API clients are unaffected; encoded variants (%2F) do reach the app and get a proper 400.
See Methodology for how scores are actually derived.