GET
What the wallet that deployed a Solana token has done before
no_record is not clean. Most wallets on Solana have deployed nothing we measured, and this endpoint says so in a sentence rather than answering zero.
Every provider on this chain can tell you about the token in front of you. None of them can tell you what the wallet that made it has done before, because that requires having watched the launches at the time they happened. Scienter’s census has, since 2026-09-08, and this is the surface that sells the answer.

The three answers

Settled means the launch’s 24 hour horizon had already elapsed when the record was measured. A wallet nobody has seen before is not flagged: absence of a record is not a bad record, and flagging first-timers would flag most of the chain.
Case is load-bearing. Solana addresses are base58, lowercasing one destroys it, so the lookup is exact and a mis-cased address answers no_record rather than silently matching something else. A string that is not base58 gets a 400.

A wallet with a record

curl
mints carries a handful of the wallet’s launches so the claim can be checked by hand on any explorer. finding and caveat travel inside data, next to the claim they qualify, because an MCP client hands this object straight to a language model and the model restates the conclusion without whatever surrounded it.

A wallet with no record

This is the state most addresses return, and reading it as a pass is the one mistake that matters here. It is the same error as reporting an address nobody screened as clear of sanctions.

How accurate it is

Asked as a hit rate, the question has no answer, and that is not evasion: this is not a prediction with a hit rate, it is a filter with a measured difference in survival. Nothing here scores a token or forecasts a price. What follows is the whole of the measured performance. The rule — flag a launch when every previously settled launch by the same deployer has died — was written down first and then scored once on a held-out later window, over 7,401 launches whose outcome was checked with the method on Launch outcomes. These are not 24-hour figures. A launch is eligible for checking once it is 24 hours old, but the median launch in this corpus was actually checked 100.5 hours after birth. This column header said “at 24h” until 2026-09-21, which made these rates look directly comparable with the 24-hour prospective figures below — and survival falls with time, so they are not. The like-for-like recut, restricted to launches checked in a single 24-to-30 hour window, is 0.85% against 4.16% over 2,774 launches. Both splits separate with non-overlapping Wilson intervals. The effect shrinks from 15.8x to 5.5x out of sample, which is what a rule chosen on training data should do. What matters is that it survived at all. Today 60,930 wallets are published, 57,068 of them with no surviving launch.

The population it was measured over

Every figure above is measured among launches whose deployer could be resolved. A launch nobody can attribute to a wallet is not in the numerator or the denominator, on either side of the comparison. That is the same population this endpoint serves, which is why the measurement matches the use: you can only ever ask this about a launch we attributed. It is not a claim about launches in general, and it would be a different — weaker — claim if it were, because attribution is not random. A deployer we cannot resolve is disproportionately one whose token died fast enough that no provider ever wrote a report for it. So read it as: among launches we can attribute, the flagged ones survived 0.80% of the time against 4.34%. Not: 0.80% of flagged launches survive. Read as a false-positive rate: about 1 flagged launch in 125 did survive the day. Read the other way, roughly 1 unflagged launch in 23 did. Both numbers are small, which is the point — this separates bad from worse, not good from bad.

What it is not

  • Not a buy signal. It says a flagged launch is several times less likely to still be listed tomorrow. The baseline study over 7,471 prospective outcomes reports no decile that pays a $100 clip back after costs, and nothing here changes that. Used as a reason to buy the unflagged ones, it would lose money.
  • Not a score. There is no number to threshold. There is a record, or there is not one.
  • Not a verdict on a wallet. Association, not causation, over one recorded window. A deployer whose tokens died is not thereby the cause of the next one dying.
  • Survival is a low bar. Still listed with tradeable liquidity is not profit, legitimacy or safety.

Limits

Coverage is about 32.2% of launches (measured 2026-09-19), up from 11.8% when the rule was first scored and 24.7% a day later. And of the launches it can answer, it flags about 95%. Measured the same day on live traffic: 8,902 flagged of 9,365 screenable, leaving 463 that are not. That is not a malfunction. Of the 29,074 launches this census has actually resolved, 894 were still listed — 96.9% were not — so a wallet with one or two settled launches has usually had all of them die. But it changes how to read a reply. A flag is the common answer, and the informative one is its absence. If you are building a filter, the useful question is not “did it flag” but “is this one of the 5% it did not”. Treat a flag as the baseline expectation for a wallet we have a record on, not as a discovery about this particular launch. The rest are first-time deployers, or deployers whose earlier launches have not settled. Coverage rises as the census walk continues and as deployers are read off the chain for the mints no provider has a report for. For comparison, the creator-history flag carried by the nearest public provider fires on about 2.6% of mints. On the larger sample the separation holds: 704 flagged launches survived at 1.28% against 4.51% for the rest, still with non-overlapping intervals. That is a second look at a recomputed split rather than a fresh holdout, so the figures quoted above remain the ones from the single scoring. One window, 2026-09-08 to 2026-09-19. One chain, one venue mix. The rule was chosen after looking at the training data; the holdout is what makes it honest, and a different rule found the same way would need its own.
Scienter analyses public blockchain records. A finding states what those records show and how confident we are; it is evidence, not proof of anyone’s identity, intent or wrongdoing, and an attribution we cite is the cited source’s. An empty result means not analysed, never safe. Nothing here is legal, tax or investment advice, or a recommendation to transact with any address or asset — see Disclaimers for the full text.

Authorizations

Authorization
string
header
required

An sc_ key from https://scienter.xyz/settings/api, sent as Authorization: Bearer sc_.... The same key is accepted in the x-scienter-membership header. Prefer the header over any query form: a credential in a URL reaches access logs, proxies and browser history.

Path Parameters

address
string
required

A base58 Solana wallet address, exact case.

Pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$

Response

ok with the deployer record, or insufficient_evidence when no settled launch by this wallet has been recorded.

The four-state envelope. state: ok carries data as described; the three absences carry data: null and reason. See the Absent schema.

state
enum<string>
required
Available options:
ok,
insufficient_evidence,
not_deployed,
not_supported
subject
string
required
sources
object[]
required
as_of
integer
required

Unix seconds.

data
object
reason
string

Only on an absence: why, in plain words.