How Ocellus works.

What happens in a scan

1. Snapshot

   The token is read at one point in time. The report records the block and time, so every balance in it belongs to the same moment.

2. Holder map

   Every holder the data provider returns goes on the map with its balance and share of the supply.

3. Wallets investigated in depth

   A smaller set of wallets has its funding and trades traced. The report names the set and says why those wallets were chosen.

4. Specialist review

   Six specialists each read their own part of the evidence and write findings that cite the records they rely on.

5. The Skeptic

   Each finding is challenged with the ordinary explanation that fits the same records. Findings can be qualified, weakened or rejected.

6. The report

   The Lead Investigator writes up what survived, keeps unresolved disagreements visible and lists what was not covered.

The eight roles

Holder AnalystGathers evidence

Reviews the holder map and concentration. Separates infrastructure such as pools, bonding curves, burn addresses and labelled services from other holders, and reports only what the balances and the completeness of the holder list support.

Funding InvestigatorGathers evidence

Follows observed funding paths and looks for funding sources that several examined holders share. Labelled services and senders that fund many wallets are treated as weak signals, because exchanges and bridges fund unrelated people.

History AnalystGathers evidence

Reads decoded trades on the venues Ocellus supports, the timing of first buys, sells by examined holders and repeated participation in other launches. A router that forwards a trade is not counted as the trader.

Web InvestigatorGathers evidence

Compares the token listing, the project website and the domain registration record with the launch. Listing and website fields are self-published, so they are reported as what the project says, not as verified facts.

Social AnalystGathers evidence

Not switched on in the current beta. When it is, it looks at the linked X account and a limited sample of recent posts: account age against the launch, how many separate accounts post, and repeated text. Followers and engagement can be bought and are weak signals.

Promise AuditorGathers evidence

Collects concrete claims the project makes and checks each against chain data where the chain can settle it. Claims about yield, backing, products or partnerships cannot be settled on-chain; the report says so instead of guessing.

SkepticChallenges findings

Challenges the other specialists. For each finding it asks what ordinary explanation fits the same records, and can qualify the finding, weaken it or reject it. Its challenges are kept in the report beside the finding.

Lead InvestigatorWrites the report

Writes the report from what survived the challenges. Facts cite their records, unresolved disagreements stay visible, and coverage limits are listed instead of being smoothed over.

What the Skeptic can do to a finding

Qualify

The finding stays, with the alternative explanation written beside it. For example: “54 wallets bought the same way” stays in the report, next to the note that thousands of wallets use that router.

Weaken

The finding is kept at a lower strength because the evidence fits more than one story. For example: A shared funder that turns out to be an exchange withdrawal address drops from a connection to a weak signal.

Reject

The finding is removed from the main observations when the records do not support it. For example: A “cluster” made only of wallets that received tokens from the pool itself is dropped: that is simply buying.

A shared exchange funding source alone does not establish common ownership. Similar timing alone does not establish coordination.

Deterministic checks and AI analysis

Every investigation leaves a record.

Reports are saved. Reviewed cases help us identify missed patterns. When a person reviewing a case finds something the scan did not surface, that pattern can be written as a new rule-based check. New checks, tested against past cases: before a check ships it is replayed on earlier cases to see what it would have caught and what it would have flagged wrongly.

This is a manual process carried out by people. Nothing trains itself: saved reports are not used to train a model, and no check is added automatically.

1. What a reviewed case showedOwnership looked spread out, but many small wallets had bought the same way.

   The checkMatching buy patterns: same entry contract, one burst of time, similar wallet history. Reported as a behavioural pattern, never as common ownership.

   Implemented

2. What a reviewed case showedTrading looked busy, but most wallets sold straight back out.

   The checkBuy-and-sell churn, measured from the transfer history that could be read.

   Implemented

3. What a reviewed case showedA website promised locked liquidity and a renounced owner, and the scan could not tell.

   The checkContract owner and pool-token burn, read at the snapshot where the network supports it.

   Implemented

4. What a reviewed case showedA wallet from one reviewed case can turn up in another token, unnoticed.

   Planned checkCross-case wallet memory: naming wallets from earlier reviewed cases when they appear again.

   Planned, not built

Why it is called Ocellus

An ocellus is an eye-spot. The mark is one eye-spot ringed by eight points, one for each role. Each specialist examines one part of a token. Together, they reveal the connections.