Scienter

Who created a Solana token, and what that wallet's OTHER launches did. Takes a mint — the identifier a user actually has — and resolves the wallet that created it, which requires a census that watched Solana launches prospectively since 2026-09-08. EVERY NUMBER IT RETURNS COUNTS LAUNCHES BY THAT WALLET, NOT EVENTS IN THIS TOKEN. Never write that the token had launches or has a death rate; the true statement is about its maker, and it is a reason to look harder at the token rather than a measurement of it. Three outcomes, and they must not be collapsed: - flagged: every settled launch by the creating wallet has died. - not flagged: that wallet has a settled record and at least one launch survived. This is NOT a positive finding; it means the screen does not fire. - no record: either the mint is not one the census publishes evidence for, or its wallet has no settled launch on record. This is the answer for most of the chain and it is NOT a clean result — it is a statement about coverage. Never report it as clear. What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals. It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict. Case is significant: a mis-cased mint is a different mint and will answer no record. Call this when a user asks about a specific Solana token, who made it, or whether its creator has a history. Use solana_deployer instead when a deployer wallet is already known. Args: - mint (string): a base58 Solana mint address, exact case.

{
  "type": "object",
  "properties": {
    "mint": {
      "type": "string",
      "description": "A base58 Solana mint (token) address, exact case. Lowercasing it makes it a different mint and the answer will be no record."
    }
  },
  "required": [
    "mint"
  ],
  "additionalProperties": false
}

What the wallet that deployed a Solana token has done before: how many of its launches settled, how many died, and whether every one of them did. Built from a census that has watched Solana launches prospectively since 2026-09-08, which is why it can answer a question about the deployer rather than about the token. Three outcomes, and they must not be collapsed: - flagged: every settled launch by this wallet has died. - not flagged: a settled record exists and at least one launch survived. This is NOT a positive finding; it means the screen does not fire. - no record: no settled launch by this wallet was ever recorded. This is the answer for most of the chain and it is NOT a clean record — it is a statement about coverage, never about conduct. Never report it as clear. What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals. It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict. Case is significant: Solana addresses are base58, and a mis-cased address is a different address that will answer no record. Call this when a user asks who made a Solana token, whether a deployer has a history, or whether a launch's creator has ever had one survive. Args: - address (string): a base58 Solana wallet address, exact case.

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "A base58 Solana wallet address, exact case. Lowercasing it makes it a different address and the answer will be no record."
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

Scienter's forensic read on one blockchain address: public block-explorer facts (age, activity, balance, bounded-window flows), the published exchange-wallet label when the address is one, the clustering engine's entity when it answers, and itemised findings with citations. This does NOT return a risk score. Scienter publishes no calibrated wallet-risk model and this tool will never emit a number to grade an address by. It returns evidence, and it reports explicitly when a check did not run -- an empty findings list with findings_checked=false means the engine did not answer and must not be read as a clean result. Args: - address (string): an EVM 0x address or a base58 Solana address.

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "An EVM 0x address or a base58 Solana address. Case is preserved."
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

Screen one blockchain address against the U.S. Treasury OFAC SDN (Specially Designated Nationals) list: a direct match on the address itself, plus the engine's two-hop proximity walk over the address's real transfer history. Two separate claims, reported separately. Three direct-match outcomes, and they must not be collapsed: - a match: the address is published on the SDN list. The designated entity, its type, its sanctions programs and the chain OFAC filed it under are returned. - no match: the whole published list was searched and the address is not on it. That is a real finding about one list on one date. - not screened: the list could not be read, so nothing was checked. Never report this as clear; point the user at https://sanctionssearch.ofac.treas.gov/ instead. Proximity: when proximity_checked is true the engine walked up to two hops of transfer history (its warehouse or a live read) looking for a listed address, and reports found or not, the hop count, the path and how far it went. Being N hops from a listed address is a fact about the graph, never a designation. When proximity_checked is false nothing was walked and the result says so. Limits to repeat whenever the result is restated: SDN list only (not the EU, UN or UK/OFSI lists, and not OFAC's non-SDN lists such as SSI, NS-MBS and CAPTA); as published on a stated date; a walk bounded by hops and a node budget. A miss is not a sanctions clearance. Call this when a user asks about sanctions exposure, designation, or OFAC status for an address, so the answer is grounded in what was actually searched. Args: - address (string): an EVM 0x address or a base58 Solana address.

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "An EVM 0x address or a base58 Solana address. Case is preserved."
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

Look up whether an address is a labelled centralised-exchange wallet in Scienter's published exchange-wallet table, whether any address clustered with it is, and what the address's own exchange activity looks like: its deposits to labelled exchange wallets and any per-user deposit addresses inferred from its behaviour, read from real transfer history (activity.checked says whether that read ran). The table is small (tens of addresses, from public block-explorer labels, activity-checked on chain) and a miss means no label is held -- not that the address is unaffiliated with an exchange. Critical limit on what a hit means: an exchange hot or cold wallet is paid by millions of unrelated people. Two addresses that both funded the same exchange wallet are two customers of that exchange and nothing more. Each row carries a clusterable flag saying whether it can be used to link addresses at all; this must be repeated whenever the result is restated. Args: - address (string): an EVM 0x address or a base58 Solana address.

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "An EVM 0x address or a base58 Solana address. Case is preserved."
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

Trace an address's cross-chain bridge transfers: which transfers touched which bridge contracts, toward which chains, for how much, with the transaction hash of each. Scienter matches the address's transfer history (its own warehouse first, a live provider inside a budget after that) against a registry of bridge contracts across seven protocols. The registry is partial by construction, so an empty result means none of the tracked contracts were touched -- never that the funds did not bridge. The coverage and the caveat come back in the same payload and must be repeated whenever the result is restated. Three outcomes: transfers found (listed with amounts and hashes); none of the registry's contracts touched (a bounded negative); not traced (the engine did not answer, and nothing may be inferred). `truncated: true` means the provider's row cap was hit and every count is a lower bound. EVM addresses only; a Solana address is out of scope, which is a different fact from clear. Args: - address (string): an EVM 0x address (a base58 Solana address answers out of scope).

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "An EVM 0x address. Case is preserved."
    }
  },
  "required": [
    "address"
  ],
  "additionalProperties": false
}

List the addresses Scienter's risk model has flagged most recently, highest score first, with each row's chain, score, model version, top evidence and timestamps. Every row is a model output about a token contract's on-chain behaviour -- not a legal finding, not an audit, and not an allegation against any person. Widely held tokens are excluded by an allowlist and the suppressed count is reported, so this is a filtered view of the model's output. An empty list is reported as one of three things and they must not be conflated: a quiet day (the scorer ran and nothing crossed the threshold; a finding), a flag table no scorer has ever written (a gap in coverage; ever_written is false), or an unconfirmed read. A producer that did not answer at all is a fourth, reported as not_deployed. Args: - limit (integer, optional): maximum rows to return, 1-100 (default 20).

{
  "type": "object",
  "properties": {
    "limit": {
      "type": "integer",
      "description": "Maximum rows to return, 1-100.",
      "minimum": 1,
      "maximum": 100,
      "default": 20
    }
  },
  "additionalProperties": false
}

Search Scienter's published forensic receipts -- written reconstructions of specific on-chain incidents -- by address or free text, and get back titles, dates, subjects and public URLs a human can open. There are only tens of receipts in total, each written for one investigation, so most addresses have none. No match is the normal case and is NOT evidence that nothing happened to or around the address. Unverified drafts are withheld from results and counted separately. Args: - address (string, optional): match receipts whose subject or deployer contains this. - q (string, optional): free-text match over title, description and tags. - limit (integer, optional): maximum receipts to return, 1-50 (default 20). Passing neither address nor q lists the most recent published receipts.

{
  "type": "object",
  "properties": {
    "address": {
      "type": "string",
      "description": "Match receipts whose subject or deployer address contains this string."
    },
    "q": {
      "type": "string",
      "description": "Free-text match over receipt title, description and tags."
    },
    "limit": {
      "type": "integer",
      "description": "Maximum receipts to return, 1-50.",
      "minimum": 1,
      "maximum": 50,
      "default": 20
    }
  },
  "additionalProperties": false
}