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.
See the methodology applied.
Run a wallet or cluster through VikingIntel and read the evidence behind the conclusion.