How VikingIntel reaches a conclusion.
Every classification VikingIntel produces traces back to a documented rule set. This page explains it in plain language, so a conclusion can be checked rather than taken on faith.
Every claim carries one of four labels.
Before any signal is weighed, each statement VikingIntel produces is typed for what it is. The label travels with the claim everywhere it appears — in traces, cases, reports, and API responses — so a reader always knows how much weight a statement can bear.
Directly supported by blockchain data: a transaction, a balance change, an account state read from the chain itself.
Calculated from observed data by a documented method — hop chains, timing deltas, clustering output. Reproducible and version-stamped.
Supported by known-entity evidence: a wallet linked to an exchange, bridge, or service because the registry shows it. Never asserted without that basis.
A conclusion suggested by multiple signals — the analysis says likely, the chain does not say proven. Awaits human confirmation.
When VikingIntel cannot establish a claim from available evidence — the trace ran out of budget, the entity is unlabeled, the input is ambiguous — the answer is unknown, stated plainly rather than guessed.
Public-source material is evidence with provenance, not automatic truth.
VikingIntel enriches on-chain investigations with publicly available information — project websites, domain infrastructure, repositories, and public identities. Each piece is collected with its source, timestamp, and provenance preserved.
Collect
Gather evidence from domain records, project websites, repositories, and public platform profiles.
Normalize
Structure each finding as typed evidence with subject, relationship, object, and collector metadata.
Preserve source
Stamp every piece of evidence with the collector that produced it, the version, and the retrieval timestamp.
Check freshness
Flag evidence older than 30 days. Stale data is not silently excluded — it is marked and available.
Compare independent sources
Evaluate whether multiple collectors produced the same claim independently — not whether more sources exist.
Correlate
Connect independent evidence that supports the same relationship across different source types.
Gate attribution
Apply level caps: identity-adjacent claims with fewer than two independent sources stay at Observed — never promoted to Attributed.
More sources do not automatically mean stronger attribution. Sources must actually support the same claim. A project website mentioning a wallet and a repository referencing the same wallet are two observations — they become corroboration only if they independently support the same relationship.
What VikingIntel can establish from public sources — and what it cannot.
Public-source findings carry the same typed labels as on-chain evidence. The distinction is the source: a website is not a blockchain transaction, and a username match is not ownership proof.
A project website publicly lists a specific Solana address. A domain record shows a nameserver configuration. A repository commit contains a Solana address string.
A verified public registry identifies an address as belonging to a known entity — supported by registry evidence, not assumption.
Multiple observed facts establish a relationship between infrastructure and an investigation subject — computed from collected evidence by a documented method.
Independent evidence collectively suggests a relationship that warrants analyst review. The evidence points toward a connection — it does not prove one.
What VikingIntel does not do: Convert a website mention, username match, repository commit, or shared infrastructure into automatic ownership attribution. Every public-source finding is typed for what it is — and inference stays inference until a human confirms it.
Raw signals are grouped before they count toward anything.
Individual heuristics — a shared fee payer, a matching tx-type/source/program sequence, a synchronized funding burst — are grouped into signal families. Multiple signals inside the same family (e.g. shared fee payer + matching execution fingerprint, both Execution Fingerprint) count as one family, not two separate points of evidence.
- Shared funder
- Funding burst
- Wallet age batch
- Shared fee payer
- Matching tx-type/source/program sequence
- Timing synchronization
- Coordinated buy timing
- Coordinated exit timing
- Shared rare-token history
- Flagged as a farm wallet in an earlier investigation
Signals that repeat within one execution fingerprint collapse into a single family — VikingIntel doesn't simply add every raw heuristic together.
Known infrastructure discounts a signal instead of inflating a cluster.
Before funding-lineage signals count, VikingIntel checks whether the trace passes through a recognized exchange, bridge, or other known entity. If it does, that signal is discounted or the trace is stopped there — a shared CEX deposit address is not treated the same as a shared unlabeled wallet.
Confidence reflects how many independent families agree — not how many heuristics fired.
A cluster reaches HIGH confidence when at least two independent signal families agree after known-entity discounting. Two matching signals from the same family (for example, shared fee payer and matching execution fingerprint, both Execution Fingerprint) are not treated as independent — they're one family speaking once.
0–1 signal families agree after discounting.
Exactly 1 signal family agrees, or evidence is partial/inconsistent across the cluster.
2+ independent signal families agree consistently across the cluster — a single signal never reaches High on its own (capped below the 0.75 high band).
Cluster confidence is a summary, not a verdict on every member.
An individual wallet can diverge from its cluster's overall confidence. A wallet funded in-window but with a different execution fingerprint is flagged at its own, lower confidence — even inside an otherwise high-confidence cluster.
Every report is stamped with the engine version that produced it.
As the model improves, the version number changes — the stamp identifies the engine version and signal-family model behind a conclusion, so a past result can be checked against the rules in effect when it was produced.
Uncertainty is stated, not smoothed over.
Investigations rarely end with complete evidence. VikingIntel represents the gaps explicitly instead of filling them with confident-sounding guesses.
Incomplete evidence stays visible
When a trace runs out of verifiable hops, the result says so rather than implying the funds vanished. When a wallet cannot be evaluated, it says not evaluated rather than scoring zero. A gap in the evidence is a fact about the investigation — recorded, not hidden.
Conflicting evidence is preserved, not averaged
When sources disagree, both sides stay on the record with their provenance — nothing is silently merged into a middle value. Deterministic on-chain facts outrank inference wherever they conflict, and consequential conclusions wait for a human to weigh the disagreement.
Three lines that never move
- Incomplete evidence ≠ no evidence. What is established stays established; what is missing is named.
- Executor claim ≠ chain truth. A report that something happened off-platform is a claim until on-chain records confirm it.
- Inference ≠ fact. An analytical conclusion stays labeled inference until a human confirms it.
A dollar figure appears only when the pricing data earns it.
Fund-flow detection sometimes needs to know what a transfer was worth — including SPL token transfers. VikingIntel corroborates prices across independent sources and applies a confidence policy before any dollar value participates in detection or decisions.
Corroboration before confidence
Prices are checked across independent providers for agreement, freshness, and depth. A single uncorroborated quote never sets the value behind a finding — and stale or thin pricing is marked as such rather than presented at face value.
Tokens participate conditionally
SPL token value can participate in detection when valuation satisfies the confidence policy — not every token is reliably valued, and traces show raw amounts without dollar claims where pricing cannot meet the bar.
A finding becomes shared intelligence only through explicit validation.
Confirmed investigation findings can harden future detection — but nothing is promoted automatically. Each candidate passes through a validation lifecycle with human gates, and shared intelligence can be contested or revoked when the evidence changes.
Propose
An analyst proposes a verified case finding as candidate intelligence. The proposal is inert — it influences nothing yet.
Validate
The backing finding is re-checked: still confirmed, still eligible. A finding that was rejected or edited after proposal does not validate.
Share
Validated intelligence can be published for wider consumption — carrying only the indicator, never case content or evidence bodies.
Contest
New evidence can challenge shared intelligence. Contested indicators stop influencing detection; revoked ones stay revoked.
Deep dive: Threat Intelligence as a product.
VikingIntel advises and authorizes — it never executes.
For protocols, an investigation can end in a decision to act. That decision stays human, bounded, and separated from execution by design.
Humans approve; authorizations are bounded
Consequential actions wait for explicit human approval — there is no autonomous enforcement. An approval authorizes one specific action through a bounded, single-use authorization, and it can be revoked or killed before use.
Execution happens outside, keys stay outside
VikingIntel holds no funds and submits no transactions — the external system keeps its own keys and performs the action. Its report back is treated as a claim and checked against on-chain records, never taken at face value.
History informs, never convicts
Prior incidents and prior decisions feed future risk assessments as context — a repeat pattern raises the signal. Historical data never proves guilt, and the absence of history never proves innocence.
Escalation respects ownership
When a critical outcome lands on an already-open incident, it is correlated into that investigation without reassigning who owns it. Escalation adds urgency — it never changes human responsibility.
Deep dive: Controlled Response as a product.
Contrarian takes from building the system.
Opinions shaped by building the system, not reading about it.
“Single-signal sybil detection is theater.”
A shared fee payer proves two transactions shared a fee payer. That is one data point inside one signal family. Tools that grade clusters on a single heuristic are scoring noise — the real question is how many independent families agree after known-entity discounting.
“Confidence without provenance is just a number.”
We stamp every conclusion with the engine version, the signal families that contributed, and the entity-registry snapshot in effect. If you see a HIGH-confidence label, you can trace which version of the rules produced it and re-run it against the current registry.
“Attribution without evidence is speculation, not investigation.”
The evidence ladder exists because the industry treats Inferred claims as if they were Observed facts. We cap identity-adjacent claims below two independent sources at Observed — even if the source is a major exchange. One signal from one source never promotes to Attributed.
“Entity-aware discounting is the hardest part to get right.”
Most clustering tools treat a shared Binance deposit address the same as a shared unlabeled wallet. That is wrong. A shared known entity is noise, not signal. Our graph-cut step runs before confidence scoring — it discounts or truncates traces through known infrastructure so sybil clusters built on CEX deposits collapse.
“Per-wallet divergence matters more than cluster averages.”
A cluster rated HIGH is a summary across wallets. One wallet inside that cluster can diverge — funded in the window but with a different execution fingerprint. We flag it at its own, lower confidence. Averaging hides the outlier; per-wallet scoring surfaces it.
Design notes — how the system is built to reason, not who built it.
Built to be audited.
Every detection rule, confidence threshold, and entity label in VikingIntel is versioned and auditable — so a finding can always be checked against the rules and registry that produced it.
See the methodology in actionSee the methodology applied.
Run a wallet or cluster through VikingIntel and read the evidence behind the conclusion.