How every answer is produced

Scienter is a forensic platform: it reconstructs what has already happened on public chains and cites the records it reconstructed it from. Five capabilities make up that platform. They are not all at the same stage, and a reader deciding whether to rely on this product needs to know which is which more than they need a feature list.

Built means the code is in this repository and tested. Answering means a request to the public deployment returned a real result on 5 October 2026. The two are different and only the second is a promise. Anything below marked as not answering is a capability we have written and cannot currently serve; it is listed here rather than omitted, because omitting it is how a feature list becomes a lie.

The wallet page carries a card for sanctions, bridges and exchange attribution, and each card says what it checked. Measured on the deployed page, sanctions answered with a real result over real history, and since 5 October so do bridge tracing and exchange attribution. Each card still says what it checked and states it when a read did not run, rather than rendering a clean result.

The Wall of Rugs sits outside the five: the page is live and its scorer now runs, but no rows have crossed its threshold, so the table is empty. The wall says so in those words rather than showing an empty board that would read as a quiet day.

Every finding is read from a public record and cites it. These are the sources, and what each one can and cannot establish.

Token risk score — specified inputs

The feature set the classifier is specified against: token supply distribution and mint authority, liquidity-pool concentration and lock state, deployer wallet age and prior deployment history, honeypot behaviour under simulated sell, and post-launch price and liquidity collapse patterns. These are the inputs. They are not evidence that the model works, and nothing on this site currently serves a score derived from them.

A screen is judged on launches it never saw. The deployer screen was fitted on one window and then measured on a later one: launches by a deployer whose every earlier launch had died were still listed a day later 0.80% of the time, against 4.34% for everyone else. That gap is the claim, and it is the only rate this site states for it.

Answers are checked against known cases every night: a sanctioned exploiter address must screen as sanctioned, a revoked designation as revoked, and a well-known individual's wallet must not be clustered with an exchange. A wrong answer found anywhere becomes a regression test before it is fixed, and the public endpoints are probed from outside every fifteen minutes.

This section exists to be checked. It reports only measurements that were run, and it names the ones that were not.

Measured

• The deployer screen, held out: 0.80% against 4.34% still listed a day later, as above. Launch outcomes has the windows and the counts.
• Known-answer checks: sanctions, revocations and clustering re-run nightly against sourced cases; a failure alerts us the same night.
• Provider accuracy: third-party intelligence providers scored against ground truth on questions with a checkable answer. Published at provider accuracy, which labels its own data mode and publishes zero rows rather than a fabricated board when nothing has been measured.

Not measured

No precision, recall, F1 or confusion matrix has been computed for any Scienter output, including token risk. There is no labelled evaluation set in this repository against which such a figure could be produced. If you have seen an accuracy percentage for rug detection attributed to us (one circulated in early drafts), it was never sourced to a measurement and should not be relied on; it has been removed from every surface we publish. What has been measured is narrower: the Solana deployer screen, held out on a later window, where launches by a deployer whose every earlier launch died were still listed at least a day later 0.80% of the time against 4.34% otherwise (see launch outcomes).

Whether our verdicts predict anything is also unmeasured. The study that would answer it — do records we rate highly go on to outperform records we do not — is blocked on retaining per-run determinations, which the engine does not yet do. It is the most valuable validation this product lacks and it is on the roadmap rather than quietly absent.

Earlier research, disclosed. Before Scienter was a forensics product we built a trader-scoring and signal engine. Its own 90-day record was negative, and we published it. That research is not sold and plays no part in any finding here; the open-source engine is documented separately for anyone who runs it themselves.

The riskiest recent launches leaderboard orders tokens against each other. It does not publish a probability that any token will rug, and the API behind it carries no such field. That is a deliberate consequence of a measurement, not a hedge, and this section states the measurement.

The base rate is the finding

The model behind the leaderboard (v4, artifact rug_detector_v4_quant_20260903) was trained on 2,481 Uniswap V2 WETH launches reconstructed from the factory's own event log, 2021Q1 through 2026Q3. Across that cohort 92.2% of viable launches lost at least 90% of their peak liquidity within 30 days. Restricted to 2026 the figure is 97.6%. Those numbers are the reason everything below follows.

A calibrated probability cannot read low here

On a population where 96.8% of cases are positive, a well-calibrated probability has a floor near that prior. The model's own lowest holdout decile still contains an 80% real rug rate, and its calibration is monotone across all ten deciles (Spearman 0.988) precisely because it is reporting that prior honestly. A model on this population can produce a calibrated probability, or it can produce a number that reads reassuringly for a blue-chip pool. It cannot do both.

Which gate this fails, and by how much

v4 was held to ten deployability gates before release and passes nine. The one it fails is the adversarial control: eight blue-chip pool launches (USDC, USDT, DAI, LINK, UNI, AAVE, WBTC, MKR), reconstructed exactly as training rows were, are required to score below 0.15 and instead score 0.24 to 0.85. That is a real failure and it is published rather than tuned away.

What the same test shows about ordering is the reason this surface exists: those eight sit in the bottom 0.6% of the holdout score distribution, six of them inside the bottom 0.3%. The ranking separates them from the field almost perfectly. The absolute number is unusable; the order is not.

What the leaderboard claims, and what it does not

• It claims an order. Rank 1 scored higher than rank 2 on the same snapshot. Nothing more.
• It does not claim a likelihood. No probability, confidence or percentage chance is published for any token, on the page or in the API. A percentile is a position in a list, not a rate.
• Ranks are comparable only within one snapshot. Rank 1 today and rank 1 last week were ranked against different candidates and are not the same claim.
• A low rank is not a clean bill of health. On a population with a 92% base rate the bottom of the list is still mostly tokens that will fail. The list identifies an ordering, not a safe set.
• Absence from the list is not a verdict. Tokens whose on-chain evidence is under 70% complete are refused rather than ranked, and refusal is reported as a count, never as a low position.

The honest margin

On held-out 2025Q1–2026Q3 data (755 launches) the model reaches AUC 0.926. The strongest single feature available — the deployer wallet's age at launch, chosen on training data and scored on the holdout — reaches 0.805 on its own. The full 159-feature model buys roughly 0.12 AUC over that one column. That gap is the value of the modelling, and it is reported here rather than the gap to a coin flip.

A shuffled-label control, which refits the model on permuted labels ten times, returns AUC 0.4966 (sd 0.061) — chance, as it must. The model is weakest on the rug type that looks most like ordinary trading: it catches 93% of hard liquidity pulls and 58% of slow deployer sell-downs. The full gate table, the per-quarter walk-forward, and three methodology defects found and corrected during the audit are in docs/audit/model-v4-report-2026-09-03.md.

A methodology page that lists only strengths is marketing. These are the conditions under which a Scienter number is weak, wrong, or absent.

Not in production

• Token risk scoring. Specified, partly built on a separate workstream, not merged and not deployed. The API answers 503 with the reason rather than 404, because 404 would be a claim about the token when the truth is a claim about our deployment. No score is served.
• MEV attribution. Not served. Wallet clustering is served (section 1), and a cluster is a set of addresses that behave as one; it does not name the person behind them.

Every published judgment carries a link back to the surface that shows the underlying record. An assertion without one is not something we publish, and if you receive a Scienter claim through any channel — bot, alert, social post, API — with no evidence link, treat it as unverified.

To cite a section of this page back at us, use its anchor — this one is #citation. Anchors are named rather than numbered so that inserting a section above does not silently repoint an existing citation.

One thing is still missing from this document: a model that publishes a probability that a named token will fail. Section 5 describes what does ship — v4, as an ordering, behind a default-off flag — and why an ordering is the honest form on a population with this base rate. A calibrated probability is a different claim, we have built one three times, and we have shipped it zero times. This section says why, because the reasons are the most useful thing we know about the problem.

AI rug prediction

The obstacle is the dataset, not the algorithm. Training a model to predict a rug honestly requires features captured at a fixed point before the outcome — the standard choice is a snapshot 24 hours after launch — paired with the timestamp of the rug event itself. This repository has thousands of confirmed rug addresses and no rug event timestamps, and its feature table is a present-day snapshot rather than a point-in-time one. Survival time is therefore unidentifiable from what we hold.

Two earlier versions failed their honesty gates and were not shipped. Both learned liveness rather than risk: because the features were collected today, a token that had already collapsed presented as missing data, and the model discovered that missing data predicts collapse. That produces excellent-looking validation scores and no predictive power whatsoever. A time-based split alone did not expose it, which is the part worth repeating to anyone building the same thing.

What we are constructing. The labelled historical dataset the model needs: 24-hour post-launch feature snapshots captured going forward, paired with rug event timestamps established from chain data rather than from a present-day scrape. That work is measured in months, not weeks, because most of it is waiting for observations that do not exist yet.

Target: Q4 2026. It ships when precision and recall pass our honesty gates against a held-out set built the same way — and not before. If the gates do not pass, this section will say so rather than the date moving quietly. The survival artifact that would answer this question is marked trained=false and deployable=false and returns no hazard; per-address probability scoring is switched off in this deployment, and a score computed from an empty feature vector is withheld rather than published even when it is switched on. The v4 artifact in section 5 is a separate thing and makes a narrower claim: it orders launches against each other and publishes no probability for any of them.

The reasoning behind launching on forensics first is written up at why we launched forensic, not predictive.

Methodology questions, disputes about a published determination, and reports that a number on this site is wrong all go to the same address. A challenge with a reproduction is the most useful thing anyone can send us, and it is answered.

methodology@scienter.xyz

Security vulnerabilities go to the bug bounty programme instead. The data behind these numbers is catalogued at data sources.