Why we launched forensic, not predictive

The short version

Scienter is launching as a crypto forensic intelligence platform. It reconstructs what has already happened on public chains and cites the records it reconstructed it from.

It is not launching as a rug predictor, which is what we spent several months building. We built that model three times and shipped it zero times. The reason is not that the algorithm was bad. It is that we do not have a dataset honest enough to train one on, and neither, as far as we can tell, does anyone else selling this.

This note is the working. It is longer than a launch post needs to be because the failures are the useful part.

What we were trying to build

The product we wanted was the obvious one: give it a token contract a few hours old, get back a probability that it rugs within thirty days. That is a genuinely valuable thing and it is what the market asks for.

To train it honestly you need two things per token:

1. Features captured at a fixed point before the outcome. The standard choice is a snapshot 24 hours after launch — liquidity, holder distribution, lock state, deployer history, the first hour's trade shape. 2. The timestamp of the rug event itself, so you know both whether it happened and when.

We had thousands of confirmed rug addresses. We had, and still have, zero rug event timestamps.

Failure one: the model learned liveness

The first version scored well. It scored well enough that it was briefly described in our own marketing copy as 83% precise, a figure that was never computed from an evaluation set and which we have since removed everywhere we could find it.

What the model had actually learned was whether a token was still alive today.

The features were collected by asking data providers about each address in the present. For a token that had already collapsed, the pools were gone, so the provider returned nothing, so the feature vector was mostly zeros and blanks. For a token that was still trading, the provider returned real numbers. The model discovered — correctly, and uselessly — that missing data predicts having-already-rugged.

This is temporal leakage, and it is the standard failure in this problem. It produces beautiful validation scores. It has no predictive power at all, because at the moment you would actually want to use it, the token is alive by definition and its features look exactly like the healthy class.

Failure two: a time split did not fix it

The second version was retrained with a proper time-based split: train on older tokens, validate on newer ones. This is the textbook fix for leakage, and it cleared the thresholds we had set.

It was still leaking. A time split separates *when the token launched*; it does nothing about *when the features were observed*. Both halves of the split were still described by a scrape performed today, so both halves carried the same tell. The model passed the gate and was not shipped, because the gate was measuring the wrong thing.

That is the part we would most want another team to take from this: a time-based split alone does not demonstrate the absence of temporal leakage when the feature collection is retrospective.

Failure three: the honest version had nothing to learn from

The third version was built the right way round. Features restricted to what was knowable at launch, reconstructed from chain data rather than from a present-day scrape — creation bytecode rather than current code, deployer history as of that block, the first hour of trades as recorded.

It does not leak. It also barely predicts anything: screening on contract capabilities alone lands close to a coin flip. The honest conclusion is that the signal we wanted lives in the features we could not reconstruct retrospectively, and that the way to get them is to start capturing them prospectively and wait.

There is a fourth version in progress. It is not deployed either. The inference artifact that ships in this repository today is marked trained=false and deployable=false, refuses to score anything, and is not wired to any route.

What we found while checking our own site

Writing this note involved auditing what our own deployment was serving. One endpoint was returning a rug score of 81.1 out of 100 for 0x1111111111111111111111111111111111111111 — a placeholder address that has never held a token, a pair, or a transfer. It returned the same 81.1 for 0xdeadbeef…deadbeef. Real USDC, the most liquid ERC-20 in existence, returned no score at all.

The number was the model's intercept: the probability it assigns when every feature is missing. Underneath it sat an eight-row factor table whose own text said "Observed max_liquidity_usd: 0" while the headline read as an accusation about a specific address.

Nobody shipped that on purpose. It is what an unguarded model does when the data layer hands it nothing, and it is the single most damaging thing a product like this can publish. Automated scoring is now switched off by default, and a score computed from an empty feature vector is withheld even when it is switched on.

We are including this because a positioning note that only described old mistakes, and not the one found while writing it, would be advertising rather than a record.

So what are we selling

Forensics. Reconstruction of events that have already happened, where every figure resolves to a record you can open in another tab and check against us.

The difference matters commercially and not only ethically. A prediction is a claim about the future that you cannot verify at the moment you most need to trust it. A reconstruction is a claim about the past that you can verify immediately and completely — and if we get one wrong, you can prove it, which is the property that makes the rest of our claims worth anything.

Receipt 001 is the worked example: a transaction-by-transaction reconstruction of the Fintoch exit, including 31,666,317.817167183900341924 USDT leaving the contract in a single receipt, the 186 seconds to consolidation, and the point at which the public trail stops being ours and starts being somebody else's attribution. We say which is which.

When the model ships

When it passes its honesty gates against a held-out set built the same way as the training set. Our target is Q4 2026, and the work between here and there is mostly waiting: capturing 24-hour post-launch snapshots going forward, and establishing rug event timestamps from chain data rather than from a scrape.

If the gates do not pass, the methodology page will say so rather than the date moving quietly. That page also lists, per capability, what is built and what is actually answering in production today — including three capabilities that are built and are not currently answering.

We would rather launch with less and have it be true.