HOW WE PROVE
THE SCORING WORKS.
The Antares scoring engine is closed source — not because we have something to hide, but because publishing the code would also publish every loophole a rug-puller needs to evade detection. That puts us in the same boat as the anti-fraud teams at banks, ad networks, and exchanges: credibility has to come from outcomes, not from the codebase.
This page documents what we test against, how often, and what an independent reviewer can verify without ever seeing a line of source.
The backtest corpus is a frozen library of real Solana token scans, captured by hitting the exact same /api/scan endpoint your extension hits. Each entry records the verdict the engine returned, the score it produced, every flag it raised, and the supporting on-chain state at capture time — holder count, liquidity, LP-burn status. Nothing is synthesised. Every row is a real mint that traded on Solana.
The corpus is intentionally skewed toward known rug pulls. False negatives on rugs are the catastrophic failure mode — a SAFE verdict on a token that turns out to drain its LP is what destroys user trust — so the test set is built to hammer the engine on the worst cases. Clean blue-chip memecoins are represented to catch the inverse failure mode (false positives on legitimate liquidity), and the borderline middle bands have enough coverage that a tuning change can't silently re-flag half the corpus.
Every night an automated job re-scans every token in the corpus against the live /api/scan endpoint and compares the new verdict and score against the captured snapshot. The check has three independent failure modes, ranked by severity:
False negative regression
A labelled rug starts coming back SAFE. Hard failure — opens a tracking issue immediately, blocks merges to the scoring layer until resolved.
False positive regression
A labelled blue-chip starts coming back DANGER or RUG. Same severity, same gate. Erodes credibility just as fast as a missed rug.
Verdict-band drift
Borderline tokens shift one band (CAUTION → DANGER or back). Surfaces in the daily report so a human can decide whether the label needs an update or the engine needs a tune.
The job hits production — the same endpoint your extension uses. No mocks, no synthetic data, no shortcuts. Requests are rate-limited so the check doesn't compete with real user traffic. The corpus itself is read-only; the job verifies, it never mutates.
Closed source doesn't mean unauditable. The audit happens through behaviour, not through code review. Here is exactly what an independent reviewer can confirm today:
The endpoint is real.
Every public /api/scan call is the same code path the corpus drift check hits. You can compare the JSON your extension receives against a token's known on-chain state and the result is reproducible.
The verdicts have a logic.
Re-scan any token currently in the corpus and the score should land in the same band as the snapshot unless the on-chain state genuinely moved. When the band shifts for no chain reason, that's a story we owe you.
Flags are explicit, not vibes.
Every flag exposed in the overlay is a named string with a severity. A paying user opens Critical Flags and sees exactly which signal moved the score — not "score 105, trust us".
The drift check has teeth.
A regression in either direction trips a hard CI failure on the daily run — not a soft warning that someone has to remember to read.
For security researchers, integration partners, and exchange compliance teams who need a deeper look than behaviour can give: we hand out scoped read-only access to the scoring repository under a one-page NDA. The review covers the engine, the cross-validation layer, and the Safe Gate logic — everything that turns inputs into a verdict.
Email with subject [AUDIT] and a short description of who you are and what you want to verify. Replies within 48 hours.
Antares is a heuristic risk-screening tool, not an oracle. A SAFE verdict means none of the detection layers found a critical signal at scan time — it is not a guarantee the token won't rug. False negatives happen, especially on novel attack patterns. The whole point of the corpus drift check is to catch them as fast as the corpus reflects the new attack — not to pretend they never occur. Read the terms for the full disclaimer.
The description above is exactly what the test runner does — not a marketing reframe of it. If the corpus grows, the same loop runs against the new tokens. If a labelled rug starts evading the engine, the test fails before the new build ships. If we are wrong, the test fails, and the truth shows up in the same place this page does.