Token intelligence, one API call away

The DeFade API gives developers programmatic access to the same on-chain risk analysis that powers defade.org. Analyze any token for rug pull risk, insider networks, bundle manipulation, smart money activity, and more — all via a fast REST API. Every endpoint defaults to Solana; adding ?chain= runs it on Ethereum, Base, BSC, Robinhood, Arc, Hyperliquid or Monad, on every plan on sale (all but /v1/bundles, whose EVM version is /v1/bundles-pro, and /v1/usage, which has no chain). Fields can differ per chain — see Chains.

What can you build?

Trading bots that check rug risk before buying. Portfolio dashboards with real-time risk scoring. Telegram/Discord bots for community token screening. Browser extensions that warn users on DEX pages. Analytics platforms tracking insider activity across Solana, Ethereum, Base, BSC, Robinhood, Arc, Hyperliquid and Monad.

Quick Start

Make your first API call in under 60 seconds.

1. Get an API key

Paid plans are self-serve: pick Lite, Starter, Growth, Pro or Enterprise under Pricing (or at defade.org/developers), pay by card or crypto, and your key is shown on the confirmation page and emailed to you straight away. Want to try first? Request a free 7-day trial key and tell us what you're building; we review and email it, usually within 24 hours. Either way, send the key with every request in the x-api-key header. The same key also powers the MCP connector for Claude and ChatGPT.

2. Analyze a token

Use your key to run a full analysis on any Solana token mint address:

curl https://api.defade.org/v1/analyze/YOUR_TOKEN_MINT \
  -H "x-api-key: df_your_api_key"

const res = await fetch('https://api.defade.org/v1/analyze/YOUR_TOKEN_MINT', {
  headers: { 'x-api-key': 'df_your_api_key' }
});
const data = await res.json();
console.log(data.risk.score, data.risk.rating);

import requests

res = requests.get(
    'https://api.defade.org/v1/analyze/YOUR_TOKEN_MINT',
    headers={'x-api-key': 'df_your_api_key'}
)
data = res.json()
print(data['risk']['score'], data['risk']['rating'])

3. Interpret the results

Two endpoints score a token, on scales that run in OPPOSITE directions. Read this before wiring either into a threshold: rugScore counts UP toward danger, while risk.score counts DOWN toward it. A token scoring 85 is near-certain trouble on one and near-clean on the other. On an EVM chain only rugScore exists.

/v1/rug-score — rugScore, 0 safe → 100 critical

The rug probability model. Higher is worse. verdict is the label, verdictColor the colour to render it in.

/v1/analyze (Solana) — risk.score, 100 safe → 0 critical

The legacy safety score, carried on the risk object as score, rating, color and flags. Higher is safer — the inverse of rugScore, and a different set of labels. If you only need one number, use /v1/rug-score. Solana only: on an EVM chain /v1/analyze carries no risk object, on any plan, and /v1/rug-score is the score there.

Authentication

All API requests require authentication via an API key.

Include your key using either the x-api-key request header (recommended) or the api_key query parameter. The header method is preferred as it keeps your key out of server logs and browser history.

curl https://api.defade.org/v1/rug-score/TOKEN_MINT \
  -H "x-api-key: df_your_api_key_here"

curl "https://api.defade.org/v1/rug-score/TOKEN_MINT?api_key=df_your_api_key_here"

Get an API Key

Buy a plan and the key is yours immediately, or request a free 7-day trial.

Paid plans are self-serve. Choose Lite, Starter, Growth, Pro or Enterprise under Pricing or on defade.org/developers and pay by card (Stripe) or crypto. The key is shown on the confirmation page and emailed to you the moment payment clears; no review, no waiting. Every paid plan covers every chain and every endpoint; the plans differ on monthly allowance (in units) and rate limit.

Free trial keys are issued on request. Submit the form at defade.org/developers#keygen with a short note on what you're building. We review each request and email a 7-day trial key, usually within 24 hours. Trial keys reach six endpoints (analyze, rug-score, token-price, holders, kol, trending) plus usage, on every chain we cover — Solana + Ethereum, Base, BSC, Robinhood, Arc, Hyperliquid, Monad — at 10 req/min, 100 req/day and 3,000 units/month. A trial call costs 1 unit, except rug-score, which reads the scan's modules first and draws 5 of the trial's 3,000 on Solana and on an EVM chain.

An API-plan key works everywhere: the REST API from your own code and the MCP connector in Claude or ChatGPT, same plan, same quota. DeFade Pro web subscribers get a different, connector-only key from their dashboard; it reaches the connector's tools, spends the plan's monthly scan allowance, and is not valid on the REST API. See MCP connector → Getting a key.

Using your key

Send your key with every request in the x-api-key header (or as an api_key query parameter). Every paid plan can call all 30 endpoints on every chain; the plans differ on how many units a month you get and how fast you may send them. A call costs one unit, except funding-origin, funding-graph, sybil-cluster, fresh-wallets, rug-score and stress-test on an EVM chain, which cost 5, and rug-score and stress-test on Solana, which also cost 5. See Authentication for details.

API Endpoints

30 endpoints covering every angle of on-chain risk. Click any endpoint to expand full details, parameters, and response schema. Every paid plan unlocks all 30 endpoints on every chain — plans differ on included units and rate limit. The second badge shows chain support: 28 run on every chain, bundles is Solana-only, and usage reports on your key so it has no chain at all (see Chains).

Every endpoint wraps its result in the same envelope: token (the mint you asked about), timestamp (when the response was assembled) and poweredBy, with the endpoint's own fields in between. Five exceptions: /v1/holder-overlap and /v1/wallet-overlap take several mints so they carry mints instead of token; /v1/wallet-reputation is about a wallet, so it carries wallet (and chain); /v1/trending is not about one token so it has no token; and /v1/usage reports on your key, so it has no envelope at all. On /v1/analyze the endpoint's own token object replaces the envelope's mint string. With an EVM chain the envelope also carries chain.

Chains

One endpoint set, every chain. Solana is the default; ?chain= selects an EVM chain.

Every endpoint takes an optional chain query parameter. Omit it and the request is treated as Solana, so existing integrations keep working with no change. Pass it to run the endpoint on an EVM chain — same envelope and semantics; module fields can differ per chain, and each endpoint entry says where in an On EVM chains note. The largest differences: analyze answers the contract and market read with no risk, holders or creator, so the EVM score is /v1/rug-score; socials answers a presence and X sentiment read in place of the links; dev-tracker reports the creator's position in shares of supply, with a status vocabulary of its own; holders counts in holdersCount and lists in holders; liquidity reports LP custody and v3/v4 positions in fields of its own; historical-bundles measures a bundle against the window's buys rather than the supply; kol carries its totals at the top level rather than under a summary; the funding modules stamp fetchedAt in place of computedAt / fromCache; snipers has no reachedGenesis or firstTxTime; and rug-score adds a per-module modules map with skipped and failed. Most EVM answers also carry available, chain and the lower-cased address, and several answer a 200 with available: false and a reason where Solana answers an error: each note says which. A good pattern on any chain: call /v1/rug-score first — it starts the module scans for that token, so most per-module calls that follow answer from cache.

curl https://api.defade.org/v1/rug-score/7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU \
  -H "x-api-key: df_your_api_key_here"

curl "https://api.defade.org/v1/rug-score/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48?chain=base" \
  -H "x-api-key: df_your_api_key_here"

Supported chains

Plus solana (base58 mint address), which is the default when chain is omitted. Additional chains are added to this list as they launch — the rows are rewritten from the live chain registry (/api/evm/access) for the chain ids this page knows a display name for, so a chain that launches appears here without an edit and a chain that is held back never does.

Which plans reach which chains

Chain access is a property of your plan, not of the endpoint. Every plan on sale covers every chain, with an identical endpoint list:

Requesting a chain your plan doesn't cover returns 403; only keys on a retired Solana-only plan (see Pricing) can hit this. Sending a 0x address without a chain, or a base58 mint with an EVM chain, returns 400 — the address format and the chain have to agree.

Endpoint coverage on EVM

28 of the 30 endpoints run on every chain. One is Solana-only, and usage has no chain:

/v1/usage reports on your key rather than on a token, so it takes no chain parameter. /v1/trending, /v1/holder-overlap, /v1/wallet-overlap and /v1/wallet-reputation accept chain as a normal query parameter alongside their own.

Overage Credits

Keep making requests after your daily limit — pay-per-use, no plan upgrade required.

When your monthly allowance or your daily request limit is reached, the API normally returns 429 Too Many Requests. If your key holds credits, those requests are fulfilled using credits instead of being blocked, whether or not the overage switch is on. A credit costs $0.04 in the $5 pack and less in the larger ones (below). Past the monthly allowance or the daily limit a request takes as many credits as it costs units: 1 credit for most calls, 5 credits for the heavy EVM calls listed in units.heavyOnEvm, 3 credits for the Solana calls listed in units.heavyOnSolana.

How It Works

1. Purchase a credit pack via the dashboard (card or USDC) or the API. 2. When you pass your monthly allowance or daily limit, requests automatically consume the credits on your key: there is nothing to switch on for that. 3. When credits run out, the standard 429 response resumes.

The overage switch (“Keep going past my limits” on the dashboard) does something else: it lets us charge the card behind your plan for another 125-credit pack ($5.00) automatically whenever your balance falls below 25 credits, so the key keeps working instead of reaching the 429. Each charge is emailed to you. There is no cap on how many packs it buys in a month, so leave it off unless you want uncapped automatic charges; with it off, you are only ever charged for the packs you buy.

Buy Credits via API

Returns a Stripe checkout URL for one-time credit purchase. After payment, credits are added to your key automatically.

Response Headers

When a request uses an overage credit, two extra headers are included in the response:

429 Response with Credits Info

When your daily limit is hit and credits are unavailable or disabled, the 429 response includes a credits object:

{
  "error": "Daily limit exceeded",
  "limit": "1000/day",
  "resetsAt": "midnight UTC",
  "credits": {
    "enabled": false,
    "balance": 0,
    "costPerRequest": "$0.040",
    "hint": "Buy overage credits or tick \"Keep going past my limits\" in your dashboard to keep making requests after your daily limit."
  }
}

Rate Limits

Rate limits are enforced per API key at both per-minute and daily granularity.

When you exceed your per-minute rate limit, the API returns 429 Too Many Requests with a retryAfter field (in seconds). When you exceed your daily limit, the request is blocked unless your key holds overage credits, in which case each extra request consumes as many credits as it costs units (1 for most calls). Rate limit status is included in every response via headers:

Limits by Plan

The daily count resets at midnight UTC; the monthly allowance resets on your billing date (usage.periodResetsAt on /v1/usage). The per-minute and per-day figures count requests; the monthly figure counts units — one per call, five for funding-origin, funding-graph, sybil-cluster, fresh-wallets, rug-score and stress-test on an EVM chain, three for rug-score and stress-test on Solana.

Error Handling

All errors return a consistent JSON structure with an error field and optionally a message with more detail.

Error Response Format

{
  "error": "Rate limit exceeded",
  "limit": "10/min",
  "retryAfter": 23
}

HTTP Status Codes

You pay for answers, not errors. A request refused for its shape (400) or by your plan (403, 429) is never charged, and a call that fails on our side (any 5xx, timeouts included) is given back: its units, or the credit it used, return to your allowance and it does not count toward your daily or per-minute limits. A call your client gives up on before the answer arrives (its own read timeout, a dropped connection) is given back too; that one still counts toward the per-minute and per-day limits. The same holds when the refusal comes from a module inside the analysis: since 2026-10-14 a module's 400, 404, 429 or 504 comes back as that status with the module's body, never as a 200 carrying an error field, and the unit is given back. A module's own 200 — pending, unavailable, available: false, an empty list — is a result: the module answered, and the call is charged as usual.

SDKs & Integration

The DeFade API is a standard REST API — it works with any HTTP client in any language.

Official JavaScript SDK

Zero-dependency client for Node 18+, CJS and ESM, with TypeScript types — open source at github.com/DeFadeLtd/defade-sdk.

npm install defade   # or: npm install github:DeFadeLtd/defade-sdk

import DeFade from 'defade';

const client = new DeFade({ apiKey: process.env.DEFADE_API_KEY });

const scan = await client.analyze('TOKEN_MINT');            // safety score: 100 = clean
const risk = await client.rugScore('TOKEN_MINT');           // rug probability: 100 = dangerous
const eth  = await client.holders('0x…', { chain: 'ethereum' });

Plain JavaScript / Node.js

// Simple wrapper function
const DEFADE_KEY = process.env.DEFADE_API_KEY;

async function defade(endpoint, mint = '') {
  const url = `https://api.defade.org/v1/${endpoint}${mint ? `/${mint}` : ''}`;
  const res = await fetch(url, {
    headers: { 'x-api-key': DEFADE_KEY }
  });
  if (!res.ok) throw new Error(`DeFade API ${res.status}: ${(await res.json()).error}`);
  return res.json();
}

// Usage
const analysis = await defade('analyze', 'TOKEN_MINT');
const trending = await defade('trending');

Python

import os, requests

DEFADE_KEY = os.environ['DEFADE_API_KEY']
BASE = 'https://api.defade.org/v1'

def defade(endpoint, mint=''):
    url = f'{BASE}/{endpoint}' + (f'/{mint}' if mint else '')
    r = requests.get(url, headers={'x-api-key': DEFADE_KEY})
    r.raise_for_status()
    return r.json()

# Usage
analysis = defade('analyze', 'TOKEN_MINT')
trending = defade('trending')

Other Integrations

DeFade also offers a Telegram bot (@DeFadeAnalyzerBot) for instant token checks, a Chrome extension that auto-detects tokens on DEX pages, and a community channel at t.me/DeFadeChat.

Launchpad Integration

Show DeFade's score beside every coin you list: one call from your server scores a coin, and a cheap call reads it back for each page.

1. Score each coin from your server

Call /v1/rug-score/:mint (add ?chain= on an EVM chain) with your secret key when a coin launches. It costs 5 units on every chain and starts every module scan for the coin. It answers within its budget (?wait=full waits up to 25 s) and names in pending what is still computing; the scans keep running, so while complete is false, call it again a minute later. Do not show an answer with complete: false as the coin's verdict: the launch modules land last, and the score can move a long way when they do. A cold token on an EVM chain can answer 504 module_timeout (not charged) while its holder or liquidity read is still running; retry after retryAfterSec.

2. Show it with /v1/badge/:mint

The badge is the token's latest complete score, compact, from what DeFade has on file: your own rug-score calls, or a scan of the coin on defade.org or in the Telegram bot. It does not run the scan: it reads the score on file and, for a token that has one, the token's current market, to check the score still stands. It answers in milliseconds once the token's record is warm and costs 1 unit; every plan that reaches /v1/rug-score reaches it. A stored score is served as it is for five minutes; for up to an hour while the market has not moved under it (market cap within half to double of what it was scored at, liquidity at least half, and no dead-token line crossed since); and a dead verdict for up to a week while the token stays dead (NEVER TOOK OFF for six hours). Outside those, or with no complete score on file, it answers 404 not_scored, which is not charged: score the coin again from your server, and link to the scan meanwhile.

curl https://api.defade.org/v1/badge/TOKEN_MINT \
  -H "x-api-key: df_your_api_key"

{
  "token": "7xK...",
  "chain": "solana",
  "timestamp": "2026-11-07T15:06:08.238Z",
  "scored": true,
  "rugScore": 30,
  "verdict": "SOME RISK",
  "verdictColor": "yellow",
  "scoreLabel": null,
  "flags": [ { "label": "Top 5 wallets hold 17%", "severity": "warning", "weight": 6 } ],
  "launchpad": "pump.fun",
  "launchTool": null,
  "scoredAt": "2026-11-07T14:52:39.955Z",
  "ageSec": 808,
  "state": "recent",
  "scanUrl": "https://defade.org/token/7xK...",
  "poweredBy": "DeFade.org"
}

How to show it

Print the verdict and the rugScore in verdictColor, or the scoreLabel when it is set, and link the badge to scanUrl so a reader can see the evidence behind it. Say the score is DeFade's. When state is recent, show its age. On 404 not_scored, show that the coin has not been scanned yet, with the same link. Higher rugScore is worse; risk.score on /v1/analyze runs the other way (see Interpret the results), so do not mix the two.

Keys

From your server, use your secret key (df_…) on every endpoint, and keep it there. Cache each coin's badge on your side for a minute, so page views do not become calls. A secret key sent from a web page to the badge is refused (403 secret_key_in_browser), and every other /v1 endpoint refuses a browser call from another site outright (403 Origin not allowed).

From your visitors' browsers, use a publishable key (df_pk_…), issued for one of your secret keys and for the exact origins of your site (https://, up to ten, no wildcards). Anyone can read a key in a web page, so this one can do very little:

• it reads /v1/badge and nothing else: every other endpoint, /v1/usage and the MCP connector refuse it as an unknown key (401), and the website's own routes treat it as no key at all;
• it is answered only for a request carrying one of its origins, with Access-Control-Allow-Origin for that origin, never * and never with cookies; a call with no Origin is refused (403 origin_required), and so is one from another origin (403 origin_not_allowed);
• it spends your plan's units and limits like your own calls, but never your credits: past your allowance it answers 429 rather than buying credits or charging your card;
• a daily cap (half your plan's daily limit unless you ask for another) and a limit of 60 calls a minute per visitor bound what a copied key can spend; a token with no score on file counts against both, though it costs no unit;
• it stops working when your secret key is revoked or expires, follows it if you regenerate it, and can be revoked on its own.

An origin check is not authentication: a script outside a browser can claim any origin. The limits above are what hold a copied key, which is why it reads only a cached score. Send the key as ?api_key= and the call needs no preflight:

const r = await fetch(`https://api.defade.org/v1/badge/${mint}?api_key=df_pk_your_publishable_key`);
const b = await r.json();
if (r.status === 404) showNotScanned(b.scanUrl);   // not scanned yet: link to the scan
else if (r.ok) showBadge(b);                 // verdict, rugScore, verdictColor, scanUrl

Publishable keys are issued by DeFade, not from the dashboard yet: email info@defade.org with your secret key's first characters and your site's origins.

Units and limits

Your plan's per-minute, per-day and monthly limits apply to both calls (see Limits by Plan); a refused or failed call costs nothing. Size the plan on coins, not page views: scoring a coin at launch and once more when its modules are in is 10 units, so 200 new coins a day is 2,000 units a day, about 60,000 a month, while badge reads from your server's cache cost one unit per coin per minute that someone is looking at it. Write to info@defade.org if your volume does not fit a plan.

Getting a key

Buy any plan under Pricing (card or crypto, the key is delivered at once), or request a free 7-day trial key: it reaches /v1/rug-score, /v1/analyze and the badge on every chain, within its 3,000 units. For a publishable key, or a launch-day integration, email info@defade.org.

Badge errors

MCP Connector

The same API, spoken as Model Context Protocol, so Claude, ChatGPT and any other MCP client can run DeFade scans directly in a conversation. One endpoint, no SDK, no separate key.

Connect

Add a custom connector pointing at the URL below, with your API key in the query string. Connector UIs only take a URL, which is why the key goes there; x-api-key and Authorization: Bearer also work for clients that let you set headers.

https://api.defade.org/mcp?api_key=YOUR_KEY

Claude — Settings → Connectors → Add custom connector → paste the URL. ChatGPT — Settings → Connectors → Add → paste the URL. Both then list DeFade's tools and call them when a question needs one.

DeFade is also listed on MCP.so, with the hosted endpoint and how to connect it.

Getting a key

Two keys open the connector, and they are different products:

An API-plan key (df_…). Buy Lite, Starter, Growth, Pro or Enterprise under Pricing or on defade.org/developers (card or crypto, key delivered immediately), or request a free 7-day trial. It works on the REST API and in the connector alike, metered in units against the plan. A trial key reaches only get_token_scan, get_rug_score, get_holders, get_token_price and get_usage, on any chain.

The Pro connector key (df_mcp_…), included with a DeFade Pro web subscription. Issue it from the dashboard under "Claude & ChatGPT connector" and paste the URL it gives you. It reaches all fifteen tools on every chain, and every tool call spends a scan from the plan's monthly allowance — the same one the website uses, one scan per distinct token per UTC day however many tools you run on it — so get_usage reports scans, not units. It only works through the connector: a direct REST call answers 403 mcp_only, and it stops working when the subscription lapses. It is not an API key, and it does not turn a Pro subscription into an API plan.

Tools

Fifteen tools, one per module, each mapping to the /v1 endpoint of the same name:

get_token_scan          get_rug_score           get_holders
get_whales              get_liquidity           get_launch_bundles
get_launch_snipers      get_wallet_links        get_smart_money
get_dev_tracker         get_funding_sources     get_lookalike_clusters
get_fee_fingerprint     get_token_price         get_usage

Every tool takes an address and an optional chain, exactly like the REST route behind it; get_token_price also takes an optional timeframe (the route's ?type=), so 1D reaches back up to a year of daily candles. Nothing here writes, trades or spends — all fifteen are read-only.

Billing and limits

A tool call is an API call: it runs through the same key, the same plan endpoint list, the same chain scope, the same unit quota and the same rate limits as a REST request, and shows up in your usage the same way. Connector traffic is tagged mcp on the usage dashboard so you can tell it apart from your own integrations. There is no separate MCP plan or price. With the Pro connector key the meter is the web plan's scan allowance instead (see Getting a key).

Two scores, opposite directions

Worth knowing before you read an assistant's answer: on Solana get_token_scan returns risk.score, a safety score where 100 is clean (on an EVM chain it returns the contract and market read with no score, and the connector tells the assistant to ask get_rug_score there), while get_rug_score returns rugScore, a rug pull probability where high is dangerous. The connector states this in its handshake instructions and repeats it on every result, so a model should not confuse them — but if you are reading raw output, check which tool produced it.

Calling it directly

It is plain JSON-RPC 2.0 over HTTP POST (stateless Streamable HTTP — no session header, no SSE stream), so you can drive it with curl:

curl -X POST "https://api.defade.org/mcp?api_key=YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

curl -X POST "https://api.defade.org/mcp?api_key=YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"get_token_scan",
                 "arguments":{"address":"YOUR_MINT","chain":"solana"}}}'

A failed call comes back as a tool result with isError set and the API's own message inside it — wrong plan, bad address, allowance spent — rather than a bare protocol error, so the assistant can tell you what actually went wrong.

Changelog

Changes to the shape of a response, and anything else that can break an integration written against an earlier version. Endpoints added, and fields added to an existing response, are safe to ignore — they are listed so you know what is new.

2026-11-07 · Changed · /v1/dev-tracker: a creator's locked supply reads as locked, on every chain

On Solana, a lock deposit made in a transaction that also paid the dev (a dev buy locked in its own create transaction) was netted against the buy and lost: $SHIP WPQCYWEt…dYB8's creator bought 39,244,396 tokens and locked them in Jupiter Lock in one transaction, and the answer read totalUnaccountedPct 4 under SOLD & BURNED. Such a deposit is now in totalLocked, and so is the dev's supply held in any escrow the scan knows: Jupiter Lock, Streamflow, the burn vault, Shipfun's Ship Vault (the dev it holds for read from the vault itself) and the UNCX, Lock.wtf, Locking Protocol and Team Finance lockers. totalLocked is what the escrows still hold for the dev: what it claimed back out of its own lock comes off it, in the new totalUnlocked, totalUnlockedPct, unlockCount and recentUnlocks; what a lock another wallet funded paid it is in totalReceived, and in the new receivedFromLocks. lockDetails entries add escrow and fullyUnlockedAt, and leave out an escrow claimed back in full. New statuses, ahead of the sold and burned ones: LOCKED + SOLD (green: more locked than sold), SOLD + LOCKED and PARTIAL EXIT + LOCKED; $SHIP reads LOCKED + SOLD, 4% locked to 2026-12-31, 0.18% sold. On the EVM chains, a contract the dev sent tokens to that holds them as a lock (a lock call, a locker's name, the tokens still there) is out of toContractRecipientsPct and contractRecipients, in the new totalLockedPct, lockCount and lockDetails (program, escrow, pct, unlockDate, fullyUnlockedAt), with the same statuses where it read SOLD EVERYTHING; /v1/rug-score names it in a weight-0 line.

2026-11-07 · Added · who holds a Solana pool with no LP token, and LP MULTI-PROVIDER on Solana

On Solana, when the main pool has no LP token (Orca Whirlpool, Meteora DLMM), /v1/liquidity now reads who holds the positions of the token's pools on chain, as it does for a v3/v4 pool on an EVM chain, and returns them as positionLock in the EVM shape: the largest single provider's share of all the liquidity (largestOpenOwner), the creator's (creator), and what is locked, burned or went unread. When the liquidity is split between independent providers (at least 10 live positions, none holding a fifth of it, at most a tenth of it unread) lpStatus reads LP MULTI-PROVIDER, which until now only an EVM answer could carry, where it read LP NOT LOCKABLE; otherwise it stays LP NOT LOCKABLE. lpLockable stays false, risk reads as it does for LP NOT LOCKABLE, and /v1/rug-score mentions it without scoring it, as it does LP NOT LOCKABLE.

2026-11-07 · Changed · Six more launchpads named

Shipfun, notrandom.fun and Float on Solana, and Flywheel, FOBO and Cracker.fun on the EVM chains, are now named for every key. On /v1/analyze on Solana: a Shipfun coin's token.timeline.launchpad.platform reads "Shipfun", where the coin read only its program (Meteora DBC), and its creator is the dev its Ship Vault names. A pump.fun coin launched through notrandom.fun has a new token.timeline.launchFrontend (name, program, via, evidence); its launch platform stays pump.fun. A coin on one of Float's configs has a new token.timeline.launchpad.float, Float's own reading: viaProgram, tier and tradeFeePct, and for a coin launched through Float's program its launchState, feeReceiver and the wallet that launched it (creator, which is also the coin's creator). A coin opened on Float's public tiers outside its program now reads Raydium LaunchLab, not Float, here and in the rug database. On the EVM chains, launchpad.name reads Flywheel or FOBO (Robinhood) or Cracker.fun (BNB Chain, Base, Robinhood and Monad), and those launches' own contracts are no longer counted among the buyers in /v1/bundles-pro and /v1/snipers.

2026-11-07 · Added · /v1/badge and publishable keys, for launchpads

/v1/badge/:mint is new on every chain: the token's latest complete rug score, compact, for a coin page (rugScore, verdict, verdictColor, scoreLabel, the top three flags, the launchpad and the scanUrl), read from what DeFade has on file. It costs 1 unit, never runs the scan, and answers 404 not_scored, not charged, when there is no current score. It is the rug score's own record rather than an analysis endpoint, so the endpoints the plans list are unchanged, and every plan that reaches /v1/rug-score reaches it. A publishable key (df_pk_…), issued by DeFade for a secret key and the exact origins of a partner's site, calls it from the browser and reaches nothing else. A secret key sent to the badge from another site's page is refused with 403 secret_key_in_browser. See Launchpad Integration.

2026-11-07 · Added · J7 and RapidLaunch as launch tools

A token launched with J7 or RapidLaunch, two deployers, is now named as launched with it, beside Proxima, Sumo and uxento: summary.launchPlatform on /v1/bundles-pro has label: "J7" or label: "RapidLaunch" and one of two new via values. launch_metadata: the token's metadata is on the tool's own server (J7's metadata.j7tracker.io or j7m.io, RapidLaunch's metadata.rapidlaunch.io or m.rapidlaunch.io), read on Solana and, on Ethereum, from Stroid's launch event (host). launch_contract: the launch transaction went through the tool's own launch contract, J7's router on Robinhood or a RapidLaunch contract its creator was delegated to (EIP-7702) on Robinhood, Ethereum, Base or BSC (contract, creator, signature). A Stroid launch that names RapidLaunch's fee wallet as its partner reads via: "partner", as uxento's do. As with uxento, the rug score's +10 line counts only when bundleInLaunchBlock is true; otherwise the tool is named at 0.

2026-11-07 · Changed · /v1/holders on an EVM chain counts a small token's holders on chain

A holder index refreshes its count on its own schedule, and the count can trail the index's own book: a Robinhood token read 297 holders where its Transfer logs left 315 addresses holding it, and the index's top 100 matched the chain to the wei. For a small token (an index count of 5,000 holders or fewer, and a whole history of 30,000 transfers or fewer), holdersCount is now counted on chain: every Transfer log the token has emitted, replayed to the block in the new holdersCountBlock, checked against totalSupply() at that block and against the book's own rows, with holdersCountSource "transfer_logs" and holdersCountIsFloor false. Every other token keeps the index's count, and so does a small one whose read has not finished two seconds after the holder read started (the next read takes it). /v1/rug-score scores the same count.

2026-11-06 · Added · /v1/deployer-reputation on an EVM chain names the tokens that run the same code

A creator can throw its wallet away after every launch; the contract it deploys is rarely rewritten. codeTwins is new on every EVM chain: the other tokens whose contract runs this one's code with only its names, figures and addresses changed, and how each ended. DeFade fingerprints the code of every new pool's token as it opens and of every token scanned, and reads each one's pool at intervals over its first three days. A token a launchpad or a factory made is not compared, since every one of them runs its template. /v1/rug-score reads it on the deployer line, in the first 48 hours of a token, for drains within six hours of launch only: three or more, at least half of those that could be judged, +10; five or more, at least 70%, +18. What the creator's own history and its funder's already charged comes off it.

2026-11-04 · Changed · PROBABLY SAFE ends at 20, SOME RISK starts at 21

On every chain, a rugScore of 21 to 24 now reads SOME RISK (verdictColor yellow), where it read PROBABLY SAFE (green). PROBABLY SAFE is 0 to 20. The other bands are unchanged. An integration that sets its own threshold at 25 should move it to 21.

2026-11-01 · Changed · /v1/rug-score and /v1/stress-test on Solana cost 5 units

On Solana, /v1/rug-score and /v1/stress-test cost 5 units a call, from 3, on every key, as they already cost on an EVM chain. On a token nobody has scanned the score runs most of a scan first, and 3 units no longer covered it on every plan. Past the monthly allowance or the daily limit either call takes 5 credits. A scan on defade.org charged to a key costs the same 5 units on a Solana token. /v1 and /v1/usage report the cost in units.heavyCostOnSolana. Every other Solana call still costs 1 unit.

2026-11-01 · Changed · an EVM /v1/rug-score no longer starts Smart Money

The EVM score has not read Smart Money since 2026-10-14, but the call still started it so that a later /v1/smart-money answered from cache. It no longer does: the score, its pending and its cost are unchanged, and a /v1/smart-money call after it reads its own answer, so the first one can take a few seconds longer.

2026-10-31 · Changed · credit packs are 125, 525 and 1,375 credits, and past the daily limit a call takes its units in credits

The $5, $20 and $50 credit packs give 125, 525 and 1,375 credits, from 200, 840 and 2,200: $0.040, ~$0.038 and ~$0.036 a credit. Credits already on a key keep their count, and an automatic top-up buys the $5 pack. Past the daily limit alone a request took 1 credit whatever it cost; it now takes as many credits as it costs units, as past the monthly allowance: 5 for the calls in units.heavyOnEvm, 3 for those in units.heavyOnSolana, 1 for the rest. credits.costPerRequest on /v1/usage and on a refusal reads 0.04.

2026-10-31 · Changed · a Solana token on its launchpad curve has the curve's liquidity on /v1/liquidity

On Solana, /v1/liquidity answered totalLiquidityUsd: 0 for a token still on its bonding curve (lpStatus: "BONDING CURVE"), on pump.fun, Raydium LaunchLab, Meteora DBC and boop.fun alike, while /v1/analyze gave the curve's liquidity. It now carries the same figure: what the curve holds from its buyers, in its quote at the quote's dollar price (a pump.fun curve paired with WEN in WEN), as an EVM curve's does. risk stays MODERATE and the answer is still no pool: pools is empty, and the rug score's liquidity lines and dead-token check read no pool depth from it. When the curve could not be priced the figure is 0, as before.

2026-10-30 · Changed · keys sold before 2026-08-09 have a monthly allowance

The grandfathered plans had no monthly allowance, only the daily limit. Each now has one, at the price and rate limits it was bought with: Starter (Solana) 2,000 units, Pro (Solana) 6,500, Enterprise (Solana) 35,000, Starter All Chains 1,500, Pro All Chains 5,500 and Enterprise All Chains 25,000. It resets on the key's creation date each month, as on every plan, and /v1/usage reports it in limits.perMonth, usage.thisPeriod and usage.remainingThisPeriod, which read null on these keys until now. Past it the key answers 429 Monthly allowance exceeded, or spends credits when it holds them.

2026-10-30 · Changed · scans on defade.org by an account that holds an API key spend the key's units

An account whose email holds a paid API key gets every Pro check on the website, the Telegram bot and the extension. Those scans were never counted. Each distinct token now spends units from that key, once per UTC day as a website scan is counted (a scan asked for again, past a minute, is charged again): 3 on Solana and 5 on an EVM chain, what /v1/rug-score costs there. They come out of the same monthly allowance and daily limit as API calls and show in /v1/usage; past the allowance the scan spends credits when the key holds them, and otherwise the site says the allowance is used up and when it resets.

2026-10-30 · Changed · /v1/rug-score and /v1/stress-test on Solana cost 3 units

On Solana, /v1/rug-score runs most of the scan page's checks before it scores: analyze, liquidity, snipers, dev tracker, the holder network and, on every paid plan, Deployer Reputation, Fresh Wallets, Bundle Detection, Sybil Cluster, Funding Graph and Historical Bundles. It cost 1 unit; it now costs 3, on every key, as an EVM rug score costs what the modules it reads cost. /v1/stress-test reads that rug score and costs the same. Past the monthly allowance either takes 3 credits ($0.075). Every other Solana call is still 1 unit. /v1/usage, /v1 and /api/pricing list the two in units.heavyOnSolana, with their cost in units.heavyCostOnSolana; the plans' included figure on /v1 reads units, not requests.

2026-10-30 · Changed · vesting a Doppler token or a Zora creator coin keeps in its own balance is vesting, not burned

A Doppler token (DopplerERC20V1 and CloneDERC20VotesV2 clones, the whole-contract DERC20; Bankr's launches among them) and a Zora creator coin keep the supply they vest in their own balance and release it from there. /v1/holders read that balance as tokens sent to the token itself: tagged token_contract and counted in burnedPct, with every other share taken of what was left. NAFF (0x2869…1725 on Base) read 83.78% burned and its creator 99.14% of circulating; kazonomics (0xca41…a776) 49.74% burned; and where Base's index left the token's own row out (1F916 0x9e00…7ba3) its 15% was missing. On Ethereum, Base, Robinhood and Monad (Zora: Base) the token's own row is now locker and vesting, named “Vesting in the token (Doppler …)” or “Vesting in the coin (Zora creator coin)”, added from the chain when the index left it out (addedFromChain); it leaves burnedPct (what the token holds past what its schedules owe stays there), what it still locks is in lockedPct and what is unlocked and not claimed in vestingUnclaimedPct, and every share is of the real circulating supply. The answer carries vesting in the shape a Virtuals token's has (protocol "Doppler" or "Zora", inToken: true, each beneficiary's allocation, cliff, end and what unlocks within 30 days), and the wallets it pays carry vesting_claim, vestingBeneficiary: true and vestingClaim.beneficiary; /v1/fresh-wallets no longer counts them as fresh wallets. The vesting cannot be cancelled (vesting.irrevocableNote); a Zora coin's owners can redirect it (vesting.redirectNote), and a Doppler token with a yearly mint rate says so (vesting.mintNote). On /v1/rug-score it is read through the Virtuals vesting lines: what unlocks within 30 days on the deferred-unlock ladder, what unlocks by 90 days and what stays locked at weight 0, and what the wallets it pays hold on the dev-holds ladder; what still vests to the wallet the dev line reads is the dev's, on a dev line of its own beside “Dev still holds” (which keeps what the wallet holds): what it can claim now or within 30 days on the deferred-unlock ladder, the ladder any other beneficiary's share is weighed on, and what stays locked past 30 days at weight 0 with its date (“The dev's wallet can claim 7.0% of supply from vesting in the token now or within 30 days …; 76.1% more vests to it after that, until 2027-10-29 — not scored”, +4, on NAFF), left out of the vesting lines, so the 30-day unlock is weighed once on the ladder whichever line names it. 1F916 reads 37 for 46: its beneficiary's 6.3% is no longer “One wallet created at launch” (+5). The holder answer's warnings for such a token: vesting_schedule (the schedule, held in the token and not burned, and whom it pays), vesting_claims (what the wallets it pays hold), vesting_claims_sold (what was claimed and sold into a pool), vesting_redirectable (a Zora coin's owners can send its vesting to another wallet), token_mint_rate (a Doppler token's yearly mint to its owner, and whether it has started), vesting_unidentified (a share of a whole-contract DERC20's vesting its creation named no wallet for) and holder_book_completed (the token's own balance, left out by the index, read on chain and added). A read that could not confirm every wallet the creation names (a whole-contract DERC20 has no log of them), or whose creation transaction did not answer, is no answer: vestingPending: true with vesting.reason read_incomplete, asked again a minute later, never its vesting owed to an unidentified wallet.

2026-10-30 · Added · a Clanker v4 token's vault and airdrop, read on chain

On Base, Ethereum, BSC and Robinhood the holder rows of Clanker v4's vault (ClankerVault) and airdrop (ClankerAirdrop, ClankerAirdropV2), and on Base the v3.1 factory's vault, on /v1/holders are named by what they are, from each contract's own record for the token, in the words every surface uses: “Clanker's vault contract: unlocks to the dev on 2026-11-01”, “Clanker's airdrop contract, nobody has claimed it: the dev can rewrite who gets it now and take it all back from 2026-11-09”. They keep the launchpad tag and add clanker_vault or clanker_airdrop; their share leaves launchpadPct for a new clankerExtensionPct. The admin's own row carries clanker_admin and, when it has no other name, “Admin of Clanker's vault contract”, “Admin of Clanker's airdrop contract” or “Admin of Clanker's airdrop and vault contracts”. A new clankerExtensions gives each contract's terms (vaults: admin, adminIsDev, allocatedPct, claimedPct, heldPct, claimablePct, lockedPct, unlock7dPct, unlock30dPct, availableToClaimPct, lockupEnd, vestingEnd, allAtOnce, unlocked; airdrops: version, admin, adminIsDev, allocatedPct, claimedPct, unclaimedPct, claimedAny, unclaimedAny, claimedOfAirdropPct, unclaimedOfAirdropPct, lockupEnd, vestingEnd, adminClaimAt, adminClaimed, rootReplaceableFrom, rootReplaceableNow, adminClaimOpenNow), every date UTC to the minute with its seconds beside it, the admin, devAdmins, adminPct, kinds ("airdrop and vault", "airdrop" or "vault": the contracts that hold supply) and line, one sentence for both contracts, with the clanker_extensions warning saying the same; { "available": false, "reason": "read_failed" } and the clanker_extensions_unread warning when a contract did not answer, with clankerPending: true on the answer: it is kept a minute, the score built from it is not kept as the score of a complete answer, and /v1/rug-score lists holders in pending. The chain's vault and airdrop balances are read beside the rows: a row the holder index lists at a stale balance takes the chain's, and one the index left out (on a book that lists the other, or a token a Clanker factory made) is added with addedFromChain: true and a holder_book_completed warning (0xb1c3…8b07 on Base: its 2% vault, missing from the index). The sentence names each contract with its share and says what its admin can do only where the contract lets it, with when: an airdrop (ClankerAirdropV2) whose admin is set, not zero or 0x…dead, has not taken it back and still holds some “can take it all back now” or “from 2026-11-09” (adminClaim), and “can rewrite who gets it now” only while nobody has claimed and more than a day has passed since its lockup (updateMerkleRoot); the v1 airdrop has no admin and no such words; a vault “unlocks to the dev on 2026-11-01”, “the dev can withdraw it now”, or vests until a date with what can be withdrawn now and within 30 days. The admin is “the dev” when the creator read (or, on /v1/rug-score, the dev tracker) names it the token's dev, “its admin 0x…” otherwise. POA (0x4570…61d8 on Base): “87% of supply is in Clanker's airdrop (82%, nobody has claimed it) and vault (5%) contracts: the dev 0x1afa…6c81 can rewrite who gets the airdrop now and take it all back from 2026-11-09, and the vault unlocks to them on 2026-11-01”. On /v1/rug-score neither row is a whale any more (no launchpad row is, except one the creation read alone named, which carries the new creation_factory tag), and one line, that sentence, takes their place, on the deferred-unlock ladder for each contract: supply in an airdrop its admin can take back or re-list (in full while its window is open or opens within 7 days, three quarters within 30 days, named with its date beyond), and a vault that pays its admin (all at once: by when it unlocks, on the same steps; a vesting: what can be withdrawn and vests within 30 days). That line charges the supply in the two contracts; what the admin's own wallet holds is charged by the holder ladders and the lines on that wallet (the dev's holding, the insider network), which the sentence names (“the dev's own wallet holds 9.9% more”) and never weighs, so neither line cuts the other. The v1 airdrop has no admin in its code, so its supply is named at weight 0 whether its terms were read or not; an unread vault or V2 airdrop is scored as its admin's. A caller who is not shown wallets reads “the dev” or “its admin” in these lines, without the address. When one admin can take back or be paid half the supply or more within 30 days through the two contracts (an airdrop it can take back now or within 30 days, or whose recipient list it can rewrite now; a vault that unlocks to it now or within 30 days; and what its own wallet holds), the score is never below 55, ELEVATED RISK, with the line “The dev 0x1afa…6c81 can take 87% of supply within 30 days through Clanker's airdrop and vault contracts — score floored”; an airdrop with no admin, one already taken back or all claimed, and windows more than 30 days away give it nothing. POA read “+18 2 whales (≥5% each) hold 87.0%” and 33, then 41 with the two Clanker lines; it reads 55. /v1/whales leaves the two rows out of the whales and lists them in protocolAccounts by their names.

2026-10-30 · Changed · four.meme, Genius, flap.sh and the Pons V2 family on their bonding curves are read off the curve

A token still on its bonding curve on four.meme (TokenManager2, TokenManager v1 and FourCore) or Genius on BNB Chain, flap.sh on BNB Chain, Base, Monad and Robinhood, or the Pons V2 family on Robinhood (Pons, Clank, Happi, Zeta.fun, TickUp.fun and Up Only) is now read off its curve, whatever the pair feeds list beside it, as a Virtuals curve is: each launchpad's own record of the token (four.meme's TokenManagerHelper3, flap.sh's Portal, the Pons factory's getLaunchedToken, a FourCore token's vault as FourCore's launch event names it) and the curve's state. On /v1/analyze such a token has market.source: "curve" and market.curve with basis: "raised" and the figures described for Virtuals (raisedQuote, targetQuote, neededQuote, tokensSoldPct, priceQuote, priceUsd, marketCapUsd, curveTokens, curveSupplyTokens, gradThresholdTokens, virtualQuote, heldPct, sellTaxPct, buyTaxPct), in the curve's quote (BNB, ETH, MON, a dollar stablecoin such as Robinhood's USDG, a token DeFade prices off its own pool on chain — GENIUS, BNCB and SPCXB on BNB Chain, from a pool that can pay out at least $5,000 of its dollar or coin side — or a token such as ZETA or a tokenized stock whose dollar price DeFade does not read, when every dollar figure is null but for the token's own price and market cap where the pair feed's listing of the curve prices the token: a flap.sh curve in NVDAB or BTCB on BNB Chain, a Pons curve in MCD, NVDA or V on Robinhood), plus kind (fourmeme, fourcore, flap or pons), holder (the contract that holds the curve's tokens), sellCostLabel (what a sell pays: trading fee, sell fee, sell fee and tax, sell fee and creator tax or curve fee) and quoteUsdKind (native, stable, pool for a quote priced off its own pool, feed when the quote has no dollar price here and priceUsd and marketCapUsd are the pair feed's for the token, read off the feed's own listing of the curve (four.meme's, flap.sh's, a Pons curve's), never a pool beside it, with quoteUsd and the reserve's dollar figure null and no sell priced in dollars, or null; with quoteNoUsdWhy where DeFade knows why the quote has no dollar price: ZETA's only market is its own bonding curve); launchpad.onCurve: true with bondingProgress the quote raised against the target (four.meme's 0xfae5…ffff: 2.7 of 13.2 BNB, 20.4%). /v1/liquidity answers BONDING CURVE with the same figures in bondingCurve and the pools beside the curve in note and besidePools; /v1/stress-test (model: "curve") and the scan page's exit calculator price sells by the curve's own formula after its fee and tax; the dead-token check on /v1/rug-score judges the curve in its own terms: NEVER BONDED past six hours with nothing traded (read from what the curve holds of the token six hours and one hour back and, when that did not move, the token's transfers out of the curve over the six hours) when it has raised less than its floor, the raise that lifts its price as far over its opening as 2.5% of the target lifts a Virtuals launch's (4.23% of the target on four.meme's TokenManager2 and FourCore, 4.12% on TokenManager v1, 4.74% on flap.sh, 4.94% on Pons and Genius, 4.85% on Clank, 9.32% on Zeta.fun, and by the launch on Happi), or, where the curve has a dollar market cap (its quote priced here, or the pair feed's for the token), when that is under $5,000; a flap.sh or FourCore curve, whose state keeps no date, is dated by the pair feed's listing of it, as before. A curve whose quote read did not answer has no quote: it is named, with market null and no bondingProgress, never priced in the chain's coin. A token its launchpad says graduated reads as before, its old curve listing out of pairs and pools. A launchpad curve read by what it holds (LiquidLaunch, Faze, Warp, Peach, Foci) is now read whatever pools the feeds list beside it, not only when none lists the token.

2026-10-30 · Changed · smart-account wallets are holders, a creator's launch buy is no snipe, and more launch contracts are read for what they are

On every EVM chain an ERC-4337 smart account (a Coinbase Smart Wallet, a Light Account, a Kernel and the rest, recognised by the code it runs, never by a name) is a person's wallet on /v1/holders: its row carries no contract tag, isContract: false and smartAccount (its kind, or “Smart-account wallet”), it counts in the concentration figures, and the info warning smart_account_wallets says how many of the top holders are one; an account that needs two signers or more is a multisig with its threshold and signers, as a Safe is. kazonomics (0xca41…a776 on Base) read 43.33% of its supply in contracts (+10 on /v1/rug-score), every one of the 34 rows a Coinbase Smart Wallet; it reads 0%. /v1/fresh-wallets, the insider network, the funding graph and the historical bundles keep these accounts as wallets. On /v1/snipers a creator's buy inside a Doppler or Flaunch creation call is the creator's launch buy (devLaunchBuyExcluded), not an instant snipe (NAFF 0x2869…1725: its creator's 16.08%; “+5 16% sniped at launch then sold” is gone), and a Doppler fee collection is no buy. On Robinhood the other Pons V2 forks are listed by their own names (Happi, Zeta.fun, TickUp.fun and Up Only): a fork's curve is a launchpad and curve row named for its launchpad (“Zeta.fun (bonding curve)”), in launchpadPct, never in contractsPct, and Happi's lockers, test lockers its deployer can empty, are no lock. On /v1/liquidity Pools.trade's second FeeSplitter (by its address and its code) and Argus V5's lock vault read locked: TRDXYZ (0x45c6…b0cf on Robinhood) reads LP LOCKED for POSITION-BASED LIQUIDITY, and 15 for 24. A Pangea token whose supply is spread across chains carries crossChainSupply (localPct, elsewherePct and chains, each with its pct where it was read) and the info warning cross_chain_supply; its shares stay of the whole supply.

2026-10-30 · Changed · the same wallets charged once on more lines, and a Virtuals curve that trades is alive

On /v1/rug-score on every EVM chain the same-wallets rule now also reads “Dev still holds” (the dev wallet), “Wallets the dev transferred to still hold” (what each recipient still holds of what it was sent), the credited creator's “still holds” line, “N whales (≥5% each) hold” and the top-10 and top-20 lines: each keeps only the part of its weight that wallets no heavier line of another module charges, and says where the rest is counted. GACHA (0xd5a0…3b84 on Base) charged its creator's 14.2% on the insider network's line and again on the dev line, and reads 45 for 52; UNICORN (0x84df…b4ea on Base) charged its creator's 27.1% as the single wallet and again as the dev, and reads 70 for 82. A Virtuals creator's holding after its vesting claim is left to the dev line only when the dev line reads that same wallet (LLL 0xfc5a…1bff's creator is a Safe, the dev line its signer). A Virtuals curve that traded at all on its FPair in the last six hours is not NEVER BONDED, whatever the trades came to, and the verdict's reason prints $0 in the last 6h beside it, never more. On /v1/holders a Virtuals answer whose vesting read had not answered in full (vesting.reason pending, read_incomplete or read_failed) carries vestingPending: true; it is kept a minute, and the score built from it is not kept as the score of a complete answer. An answer of another EVM module computed from such a holder answer (Fresh Wallets, the insider network, the funding graph, Funding Origin, Sybil bands, Smart Money, Whale Alert and the rest, not Bundle Detection) carries vestingPendingBook: "pending" while the vesting read is still out, kept a minute, or "retry" when it came back incomplete or failed, kept five minutes; /v1/rug-score lists that module in pending, and the score built on it is not kept as the score of a complete answer. A Virtuals curve short of its target is judged by its own pair wherever the pair feed ranks it, never by a pool beside it or that pool's candles; its trades are read off its FPair whenever no feed shows one, VIRTUAL's dollar price read or not; and one dumped into its own trades still reads RUGGED / DEAD. The FPair of a token still on its curve is a launchpad and curve row whether a pair feed lists it or not, so its share sits in launchpadPct on every scan, never in pooledPct on some (NS 0xd0f8…2a8c read 48.4% pooled with the FPair listed). vesting.nextUnlock names the next unlock of 0.01% of the supply or more when one follows a smaller step: PRXVT (0x4b5d…c5a9 on Base) read 2026-11-04, a step under 0.01%, ahead of the 4.36% due 2027-01-07.

2026-10-29 · Changed · a Virtuals launch's own wallets are no buyers, bundles, snipers or launch tool

On Base and Robinhood a Virtuals launch moves most of its supply through Virtuals' own wallets and the token's own contracts: the team-reserve wallet (paid the reserve at preLaunch and the creator's buy at launch, both through BondingV5), the anti-sniper vault (buying back off the curve for the creator), the Hyperboost pool (the curve's excess at graduation), the ACF reserve, and the token's TokenTable vesting unlocker, airdrop distributor and Hyperboost drop. /v1/bundles-pro and /v1/snipers now read them as launch plumbing, never a buyer, a sniper, a bundle wallet, a shared funder or a recipient of bundled supply: NS (0xd0f8…2a8c on Robinhood) read summary.bundledPct 54.16 and a cohort that bought 55.22%, and reads 0.74 and 1.12. The creator's buy is devLaunchBuyExcluded, named by BondingV5's own record of the launch (tokenInfo: LLL 0xfc5a…1bff's creator is its Safe, not the signer who sent its preLaunch), with the new routedVia: "Virtuals" and paidTo: "teamReserve": BondingV5 paid it to Virtuals' team-reserve wallet, which passes it to the token's vesting unlocker on the schedule the creator chose, and that schedule can unlock it at launch (NS's 4.1% was claimed and sold into the curve four minutes in). What was released and sold is on /v1/holders vesting. New: summary.launchPlumbing on /v1/bundles-pro and launchPlumbing on /v1/snipers, the wallets by role and the contracts by kind, absent for any other token. A token's own contracts count only on a launch BondingV5 (or BondingV2, on Base) names in its tokenInfo: an unlocker by its TokenTable clone code, an airdrop distributor or a Hyperboost drop by its program's code, each serving the token, owned by the team-reserve wallet and paid by the launch wallet that pays its kind; the token's own transfers alone prove nothing, since a token can emit any transfer. Virtuals' own wallets are left out of the buyers whatever the token, and named in launchPlumbing only on such a launch. A free account's answer keeps launchPlumbing with the roles and kinds and no address, and devLaunchBuyExcluded with boughtPct, routedVia and paidTo. The reserve wallet funding the token's airdrop distributor no longer reads as a launch tool's fee in summary.launchPlatform (FLIP 0x96ec…07f7 read Sumo, via: "launch_fee", +10 on /v1/rug-score). The wallets they pay are not plumbing: a vesting beneficiary or a claimer that buys or sells is read like any other wallet. On /v1/funding-graph and /v1/funding-origin the launch wallets are left out of the holders traced, and as a holder's funder they are named rails, never a hub: the team-reserve wallet pays one holder, the creator, the odd remainder of its own buy off the curve, which reads under dexPct, never bridgedPct (NS read bridgedPct 98.81, its Agent Creation Fund reserve traced to Virtuals' operations wallet). A Virtuals vesting unlocker or drop a holder claimed from is a named contract rail, an unlocker only when the team-reserve wallet owns it. On /v1/insider-network the launch wallets are never a node or a link.

2026-10-29 · Added · a Virtuals token's vesting, read on chain, on /v1/holders and the rug score

On Base and Robinhood, a Virtuals launch's answer on /v1/holders now carries vesting: its TokenTable vesting contracts found and read on chain (every schedule, its beneficiary, what is locked, unlocked, claimed and claimable, the next unlock and when everything is unlocked, never more locked than the contract holds), the wallets that claimed and what they still hold, sold, burned or sent on (one hop further where a wallet passed it on), and who can cancel the schedules and withdraw the deposit. A Virtuals launch is a token Virtuals' platform wallet owns that BondingV5 (BondingV2 on Base) launched, by its own tokenInfo record, or on Base that a Genesis launch created (its supply minted to a Genesis contract that names it and that Virtuals' FGenesis maps back to: NYKO 0x1299…4926), never a token some Virtuals wallet holds: the chain's own VIRTUAL is none. A vesting contract is a clone of TokenTable's unlocker owned by Virtuals' team-reserve wallet; a clone any other key owns stays a contract. Its row moves from contract to locker and vesting, “Vesting (TokenTable)”: its share leaves contractsPct, what it still locks is in lockedPct and the rest in the new vestingUnclaimedPct. Virtuals' own wallets are named and tagged by role (acf_reserve, hyperboost_pool, team_reserve, buyback_vault, excess_frozen, each with launchpad), its airdrop distributors and Hyperboost drops by type (airdrop, hyperboost_drop, a contract Virtuals paid), and a pool the Agent Creation Fund reserve laid its one-sided Uniswap v3 ranges out in keeps pool and adds acf_range: they leave largestRealPct, the top-N figures and contractsPct. What Virtuals will put on the market (the ACF reserve in its wallet and its ranges, the Hyperboost pool and drop, unclaimed airdrops) is the new launchReservePct, out of pooledPct too; what waits with its wallets (the team-reserve wallet's balance, the buyback vault's buys, Base's frozen excess wallet) is in launchpadPct; launchSupply breaks both down (NS and QBUG read largestRealPct: 25, Virtuals' Agent Creation Fund reserve; they read 0.3 and 0.08 now). A wallet that claimed from the vesting contract carries vesting_claim and stays a holder. When the holder index leaves Virtuals' launch addresses out (GACHA's Base book summed to 50.9% of the supply, without its vesting contract's 33.3% and its creator's 14.2%), their balances are read on chain and added, and when what was added comes to 1% of the supply or more every listed balance is re-read at the same block on a book that was short, and bookCompleted and the holder_book_completed info say so. A read that did not get every answer it needs is { "available": false, "reason": "read_incomplete" }, and one still running when the holder answer is made "pending". isLockerName now reads Lockup names (SablierLockup, a stream its recipient cannot pull early): such a row is a locker; a staking contract its stakers withdraw from at will (GachaLockedStaking) is a contract. On /v1/rug-score the vesting contract no longer draws “supply sits in contracts — unlock risk” (+10) nor the reserve the whale lines; in their place: what unlocks from vesting within 30 days, on the deferred-unlock ladder (22, 14, 8 or 4 points at 40, 20, 10 or 1% of supply), what unlocks within 90 days, stays locked and was unlocked at launch (weight 0), what the wallets that claimed still hold on the dev-holds ladder (12, 7 or 3 points above 15, 8 or 3%; the creator's share is the dev line's, a contract's or multisig's the contract or sibling-multisig line's when that line scores), a claim at launch sold within thirty minutes on the dev quick-dump ladder (15, 10 or 5 points at 15, 8 or 3% of supply: 0x12ef…add4's creator claimed 42% and sold it through a contract within seconds), the Agent Creation Fund reserve and the Hyperboost and airdrop payout still to reach the market on the same ladder, and that Virtuals' key can cancel the schedules (weight 0). On every EVM chain the score now charges the same wallets once across modules: a line that charges what wallets hold (the largest wallet, the top five, the insider network, the fresh wallets and the one new wallet, signal fusion, the team that claimed) or what they moved (the fresh wallets' transfers, the dev's) keeps only the part of its weight that wallets no heavier line of another module charges, and says where the rest is counted; and the insider risk level scores only when no insider holding line did, as on Solana (GACHA read 100 on one wallet's 14.2%).

2026-10-29 · Changed · a Virtuals token on its bonding curve is read off the curve

On Base and Robinhood a Virtuals token that has not graduated trades on its own BondingV5 curve (or, on Base, a BondingV2 one: UNICORN 0x84df…b4ea reads 39.05%, 16,400 of 42,000 VIRTUAL), which the scan now reads directly, whatever owns the token: its reserves, its graduation threshold and launch liquidity, the real VIRTUAL its buyers paid in, its anti-sniper tax and the side it is charged on, and VIRTUAL's dollar price from Base's VIRTUAL/USDC pool. Its dollar figures are the curve's or null, never a pair feed's, and market.volume24h is null for it. On /v1/analyze such a token has market.source: "curve" with the curve's price, market cap and figures in market.curve (basis, raisedQuote, targetQuote, neededQuote, tokensSoldPct, priceQuote, antiSniperTax and the rest, described above), and launchpad.onCurve: true with bondingProgress the VIRTUAL raised against the 42,000 graduation is reached at: NS (0xd0f8…a8c on Robinhood) reads 1.41%, 592.4 of 42,000 VIRTUAL, with 4.55% of its curve's tokens sold. Where it had a price from GeckoTerminal's listing of the curve (Robinhood) or from a pool beside it (Base), the price is now the curve's: 0x12ef…add4 on Base read $0.0000186 off a $3 Uniswap v4 pool, three times its curve's price. /v1/liquidity answers lpStatus: "BONDING CURVE" for it, with bondingCurve carrying the same figures, where it answered POSITION-BASED LIQUIDITY off the FPair (Robinhood) or off a side pool (LLX, 0xb9dd…380f on Base: $47); the pools beside the curve are named in note and besidePools. /v1/rug-score carries the weight-0 Still on bonding curve line for it in place of the v3/v4, low-liquidity and market-cap-to-liquidity lines (LLX: +12, +6 and +5), and its dead-token check judges the curve in its own terms: NEVER BONDED past its first six hours when it has raised less than 2.5% of the VIRTUAL it graduates at and nothing traded on its FPair in the last six hours (the listed FPair's volume, or its trades read off the chain), never the $5,000 floor on a market cap that moves with VIRTUAL's price, and no side pool's price moves. A token whose curve could not be read is not scored dead. /v1/stress-test prices it by the curve's own formula too (model: "curve"), after its buy and sell taxes and, inside an anti-sniper window, that tax on its side. A graduated, cancelled or drained Virtuals token reads as before, with the FPair it left (GeckoTerminal still lists it at $0) out of pairs and pools.

2026-10-29 · Changed · the supply a Solana launchpad leaves or locks

On /v1/holders (and the holders of /v1/analyze), a launch program's vault or escrow is read for what its tokens are for. A Meteora DBC fixed supply's leftover, which the pool's own vault holds until anyone withdraws it to the config's leftover receiver, read "Protocol/Infra" and was left out of concentration: Believe Dbvz2VXg…xfBLV's 50.00%, withdrawable by its creator, and EGGSKY CMjoDyLv…9vWy's 95.81%, withdrawable by Jupiter Studio's claimer. That part is now a row of its own, protocolType: "leftover", read by who can take it. Withdrawable now by the creator (or any one wallet but a platform's), it carries heldBy and counts in concentration as that wallet's (Believe: top 5 2.12% to 52.07%). Withdrawable now by a platform's wallet (Bags, Jupiter Studio's claimer, Moonit's pool creator), or only once the pool graduates, it carries owedTo instead and stays out of concentration (EGGSKY's top 5 stays 4.14%). Payable only to the burn address, it is protocolType: "burn", read as burned. A wallet that already received a withdrawn leftover keeps its row and gains launchLeftover, its share of the supply at the time (DROP dNUciax4…AGS: ADRPgA4g… received 85% of supply from Bags on 2026-04-18, and holds 56.30%); a pool that gained in the withdrawal bought what the receiver sold into it and is no recipient. A Jupiter Lock escrow read "Jupiter Lock", type lock, with no date, out of concentration and out of lockedSupply: its locked part is now protocolType: "locker" and counts in lockedSupply with its schedule (ArGQNkWx…DQ3u: 15% for its creator, next 1.25% on 2026-12-09, fully unlocked by 2027-11-04; lockedSupply.pct 0 to 15, all of it in lockedSupply.vestingPct), and its claimable part is "vesting_claimable", counted as the recipient's (3X3TyLLq…jupx: 25.06%, all of it claimable since 2026-06-09; top 5 0.46% to 25.49%). An escrow its creator can cancel (Jupiter Lock's cancel mode 1 or 3, or mode 2 with one wallet as creator and recipient; never one DBC's pool authority made) is "lock_reclaimable" and counts as the creator's. A Raydium LaunchLab pool's vesting in vault A, tagged infra with the curve's stock, is split the same way, its unlock counted from the migration (137NTJzX…PrLE: 30% for 2j8Zpw36…, all of it claimable at graduation, owed and not counted until then). New: vesting and leftover at the top level, lockedSupply.vestingPct, and on rows heldBy, owedTo, vesting, leftover, launchLeftover, supplyDetail and partOf; lockedSupply.lockers[] adds the schedule. A row split in parts changes topHolders' length and ranks. MetaDAO's DAO row is named "MetaDAO market", type amm, where it read "Contract/PDA", and a Boop.fun curve's vault row says the share it keeps for BOOP stakers in supplyDetail. On /v1/rug-score, a part one wallet can take now joins the concentration and whale lines as that wallet's, added to what that wallet holds itself (“Single wallet (the launch's leftover, withdrawable now by the launch's creator wallet hvAY…cdoy) holds 50.0%”: a launch curve's creator that is a program's address, not a key anyone holds, is named the launch's creator wallet, never the creator, and the scan's token.creator is not taken from it); a leftover a platform's wallet can withdraw, or withdrew and still holds, is one line weighed on the ladder the Streamflow unlock uses, not whale lines; a Jupiter Lock its creator can cancel is a fake-lock line on the same ladder, as a cancellable Streamflow lock is, and the dev line (“Dev still holds”) leaves out the part of holdingPercentage that is such a lock (lockedReclaimablePct), which those lines already charge; a vesting lock is a weight-0 line with its dates, what unlocks within 30 days is scored on that ladder, and a vesting lock with an end earns no “supply locked” credit; a leftover the creator can withdraw, one payable at the graduation or only to the burn address, and a received leftover are weight-0 lines saying whose. On /v1/dev-tracker, a Jupiter Lock the dev made and can cancel is the dev's (holdingPercentage, lockedReclaimablePct), not totalLockedPct. Not on EVM chains: their holder answers keep lockedPct.

2026-10-29 · Changed · pump.fun's Mayhem mode

On Solana, a pump.fun coin launched in Mayhem mode (about one create in four) mints 2B, not 1B: 1B to its curve and 1B to pump.fun's agent wallet BwWK17cb…de6s, which trades the coin for 24 hours, after which what it still holds is burned. That wallet was read as a person: on JUMP (3id2nLYR…pump) /v1/snipers listed it as an instant sniper holding 15.64% (risk: "HIGH"), /v1/rug-score charged "Snipers hold 15.6%" +10, and /v1/holders tagged its 65.64% "Protocol/Infra". It is now named as pump.fun's and is no sniper, early buyer, bundle member, fresh wallet, insider, funder or whale on any endpoint, and neither is the wallet that signs its trades (Gygj9QQb…BUpA), which also leaves /v1/fee-fingerprint's groups (on wind Bw1wSw3V…pump it was grouped with a buyer at one CU price) and the traders /v1/snipers counts in activeTerminals. /v1/holders names its row (protocolType: "mayhem_agent") and carries a new mayhemAgent (address, pct, amount, or null); /v1/analyze carries token.timeline.mayhem (agent, program, mintedToAgent, endsAt), read off the curve's Mayhem flag while the coin is under 26 hours old: null on any other coin and once 26 hours old, absent when the curve could not be read. Only a coin whose timeline.mayhem is set reads as a Mayhem coin: the agent's wallet also receives airdrops of other coins (Bags DROP dNUciax4…BAGS sent it 0.06%), and there it is a protocol row like any other. The agent stays out of concentration, and /v1/rug-score charges +4 while its 24 hours run and it holds 1% of supply or more, whatever its share: "pump.fun's Mayhem agent holds 65.6% of supply and can sell it into the curve until 2026-10-30 20:29 UTC, 24 hours from launch — …" ("into the pool" once the coin graduated). That line carries endsAt, the end of the 24 hours, and a score is not served as the token's latest past it. Under 1% the share is said at 0, and once the 24 hours are over it is said at 0 as due to be burned, until the burn lands. Holders, bundles and snipers divide by the mint's own supply, 2B while the agent holds its share and less once it is burned. Market cap stays the price times the curve's 1B, as DexScreener and pump.fun price the coin: what the agent has not sold at 24 hours is burned, which leaves the 1B to within its net trades, and the market-cap floors the verdicts read are set on 1B. The holder read on such a coin no longer counts the agent's two million token accounts (17.7 s on JUMP, now under a second).

2026-10-29 · Added · uxento on Ethereum

On Ethereum, a token launched on Stroid whose launch names uxento's fee wallet as Stroid's partner now reads launched with uxento: summary.launchPlatform on /v1/bundles-pro has label: "uxento" and a new via, partner (launchpad, partner, creator, signature, detail, bundleInLaunchBlock), and the rug score carries its line on the same terms as on Solana: +10 only when a bundle bought in the launch block, otherwise said at 0.

2026-10-29 · Added · uxento as a launch tool

On Solana, a token whose create transaction pays uxento's fee wallet is now named as launched with uxento, a launch-bundling tool, beside Proxima and Sumo: summary.launchPlatform on /v1/bundles-pro has label: "uxento" and a new via, fee_wallet (feeWallet, feeSol, payer, creatorIncluded, signature, detail, bundleInLaunchBlock); launchPlatform on /v1/rug-score carries it, and signals its line ("Launched with uxento, a launch-bundling tool — the creator paid its 0.063 SOL launch fee inside the create transaction"). uxento's bundler is one option among its quick deploys, so the line weighs +10 only when a bundle group bought in the launch block (bundleInLaunchBlock: true); otherwise it is said at 0, ending "no bundle bought in the launch block, not scored". The wallet that paid it is listed in summary.launchToolWallets. A scan cached before this change names no tool until it is recomputed.

2026-10-29 · Changed · a launch that never passed $5,000 reads NEVER TOOK OFF

On /v1/rug-score, on every chain, a token off any bonding curve that failed at the $5,000 floor (over six hours old, under $5,000, no price collapse, not trading) read ABANDONED / DEAD whether or not its market cap had ever been above $5,000. One whose own candles, read from its launch on, show its market cap never got past $5,000 now reads NEVER TOOK OFF: BASIUS (9JBJPCC6…rbid on Solana, a based.bid launch that opened its Meteora DAMM v2 pool at $3,029) is $4,124 a week on, and its closes never held above $5,000. The floor counts as passed when the closes held above it for an hour or more, timed between trades (a close that stood two days until the next trade held for two days), when a candle with real trade reached $10,000, or when a scan DeFade filed saw the token above $5,000; a lone close or a launch wick at the line does not (BASIUS touched $5,079 once). Where the candles are too wide to tell whether a run above $5,000 lasted an hour (an hourly or daily candle), that pool is read again on finer candles while the feed keeps them (about 18 days of 15-minute candles and 50 of hourly); with none kept, what the candles surely show decides, so a token does not change verdict as it ages. rugScore is still 95 and verdictColor red, and scoreLabel is "NEVER TOOK OFF", as it is "NEVER BONDED" for a coin still on its curve: DeFade's own surfaces print the state in place of the percentage. Its line reads Never took off: never passed $5,000 — market cap $4,124 after 7 days, highest it held $4,824, $27 traded in 24h, $17 in the last 6h, liquidity only $4,019, the peak being the most the market cap held; on an EVM chain deadToken.peakMcap is that figure. ABANDONED / DEAD stays for a token that was once above $5,000 and fell back without a crash, and for one whose candles could not be read from its launch (the read failed or was still out, the series was cut at the read's limit, the token is older than the candle feed keeps, or an older pool of the token's returned no candles): without them there is no evidence it never passed the floor. A pool that opened or first traded hours after the token was created still covers its whole market when it is the token's oldest listed pool and its candles came back whole. RUGGED / DEAD and NEVER BONDED are unchanged, and so is the legacy safety score on /v1/analyze, which reads no candles (FAILED / ABANDONED). Like the other dead states, a stored NEVER TOOK OFF score is not served as the token's latest while the token trades, and it is served for six hours at most, since it says what the market cap never did; the token is scored again after that.

2026-10-29 · Changed · /v1/exit-playbook: each listed launch's whole-life peak

In earlier, peakMcap is now the highest the launch's pair closed at over its whole life, read from its hourly closes, not its first 16 hours only; peakFrom says whether its whole life was read yet, reachedMarket is new, and peaksPending counts the peaks still being read. sources.markets counts the earlier launches that reached a market.

2026-10-29 · Changed · /v1/exit-playbook lists every earlier launch, and sets exchange funders aside

/v1/exit-playbook reads one more link to the same hands: the wallet that first funded the deployer, with what it launched itself and what the other deployers it funded launched (sources.devFunder, via: "devFunder"). earlier is new: every earlier launch found, whether or not it reached a market, with its market cap now, its status and, once replayed, its peak. And a funder now links launches only once it is shown not to be a service: an exchange, a bridge or a payout service pays thousands of wallets, so two wallets it paid are not the same hands. Such a funder is listed in sources.setAside with its reason; so is a band of standing wallets funded a month or more before the launch. sources.funders counts the band funders that are not set aside. reason: "no_market_history" now also covers linked launches that never reached a market.

2026-10-29 · Changed · based.bid on Solana

A token launched through based.bid's Solana program, which opens the token's Meteora DAMM v2 pool at launch, is now named: token.timeline.launchPlatform on /v1/analyze is "based.bid" where it was "DEX", and token.timeline.launchpad is set (program: "based.bid", pool, quoteMint, creator, complete: true, dex: "Meteora", curve: false for a launch with no bonding curve, true for a token that left based.bid's curve for its DAMM v2 pool), with lock: the lock account, the position, permanentPct, the share of the pool's liquidity permanently locked in DAMM v2, and heldUnlocked. A token is named only when its pool was opened for a lock account of based.bid's program that holds that pool's position, never by its bid address suffix alone. /v1/liquidity reads that pool's lock from the chain: lpLockPct is the permanently locked share on launches since 2026-07-16, with lpVerified: true, lpEvidence: "onchain" and an lpNote naming based.bid's lock, where it read a locked pool by default with lpVerified: false. An older launch, whose position based.bid's lock account holds but DAMM v2 does not lock, keeps the protocol-held default with lpEvidence: "protocol", and its lpNote says the program can be upgraded. A dead-token verdict with no price collapse says liquidity only $X where it said liquidity collapsed to $X, on /v1/rug-score on every chain and in the base scan's risk flags.

2026-10-29 · Changed · a token under the $5,000 floor that is still trading is not dead

On /v1/rug-score, on every chain, a token over six hours old under a $5,000 market cap with no price collapse read NEVER BONDED (on its bonding curve) or ABANDONED / DEAD (off it) at 95, however much it traded. four.meme and flap.sh curves on BSC open at about $3,200–4,400 and nad.fun's at about $3,500, all under the floor, so a curve token that had not yet passed $5,000 read NEVER BONDED six hours after launch while it traded (0x6fdc…ffff on BSC: $30,449 traded in 24h, up 29.8% in 6h). A token whose most-traded pair traded $1,000 or more in the last six hours, and at that pace (about $167) in the last hour, now gets no dead state and is scored by its checks like any live token: a token that pumped and dumped back to its opening cap in its first hours still holds that trading in its six-hour figure, and its last hour tells it apart. RUGGED / DEAD is unchanged, and a token with no six-hour figure (a nad.fun curve no pair feed lists) is read as before. The same holds for the legacy safety score on /v1/analyze (FAILED / ABANDONED, NEVER BONDED). Where there is a six-hour figure, the dead line adds it after the 24h one: …, $11,319 traded in 24h, $0 in the last 6h, and the last hour's when that is the figure that settled it: …, $30,388 in the last 6h, $21 in the last hour. A score filed as NEVER BONDED or ABANDONED / DEAD is no longer served as the token's latest while the token trades. On an EVM chain /v1/analyze adds market.volume6h, the six-hour volume of the token's own pair that trades now (the pair the rug score's dead check reads) (null when the feed gives none), read from GeckoTerminal too when the pairs come from there.

2026-10-29 · Changed · a curve's figure in the pairs table, a selector the token only calls, and a launchpad's own vault among the holders

On an EVM chain pairs[].liquidityUsd is null for the token's own four.meme or flap.sh curve wherever it ranks, where it was blanked only when the curve was the main pair (a flap.sh curve's figure, which counts the tokens it has not sold, printed beside the pool the token trades in). A pair GeckoTerminal answers for reads as DexScreener names it: dex "pancakeswap" with the label v2 where it was "pancakeswap_v2", and "uniswap" with the label v4 for the frontier.fun and o1 Launchpad pools it files under the launchpad, where they read "frontier" and "o1". The bytecode flags token.mintable, token.hasBlacklist and token.hasWhitelist now count a function the contract dispatches, not one it only calls on another contract: four.meme's 13,584-byte build and its Token9 call the reward manager's isBlacklisted when a holder claims, and read hasBlacklist: true with the blacklist or blacklist_renounced warning; they read false now, and a contract whose dispatcher is not read is judged as before. On /v1/holders, the token's own curve or vault the launchpad lookup names (four.meme's FourCore vault, a Genius, Pons, Clank, Foci or Warp curve) carries the launchpad and curve tags where it read contract, on every chain, whatever the creation read names (a factory, or the deployer a launchpad creates tokens through): its share moves from contractsPct to launchpadPct, and the rug score loses the “supply sits in contracts” line (+10) it drew. The lookup's answer counts only when a listed launchpad reported it: a launch event the token or an unlisted contract emits, naming any contract its curve, leaves that contract a contract, and a launch distributor the lookup names stays a contract too. The rug score's dead check takes its price change from the token's own pairs: a pool the token is only the quote of moves with the other token's price. /v1/sybil-cluster's float (floatPct, and every figure restated against it) leaves out what the launchpad's own contracts hold (launchpadPct on /v1/holders), as it leaves out the pools and lockers. On Solana a graduated token's live pool GeckoTerminal lists without a reserve figure has token.liquidity: null on /v1/analyze where it read 0.

2026-10-29 · Changed · a launch protocol's contract as the owner, the same on /v1/analyze and /v1/rug-score

token.ownerLaunchpad on /v1/analyze, added on 2026-10-28 for four.meme's TokenManager, now names every owner /v1/rug-score names at weight 0, and only those: a launch protocol's contract that owns the token only to launch it ("Doppler's Airlock"; "flap.sh's Portal" on BSC, Base, Robinhood and Monad, on the templates whose code lets it only step the move from the curve to the DEX; "Faze's launchpad" on Arc, whose token gives its owner no function but handing that ownership on), four.meme's TokenManager, Pangea's sealed peer controller, and an Argus launch token's owner, a label the contract gives no powers. A new field, token.ownerLaunchpadKind, says which: protocol, curve, controller or label (null when ownerLaunchpad is). For each of them warnings carries the info owner_launchpad in place of the owner_not_renounced warning, and a mintable, blacklist or whitelist warning reads as its _renounced info, as for the TokenManager: until now /v1/rug-score did not count Doppler's Airlock, flap.sh's Portal on Base, Robinhood and Monad, Pangea's sealed controller or Argus' label while /v1/analyze warned that the owner “may retain privileged functions”. On /v1/rug-score, flap.sh's Portal is named by the token's template, not by the Portal's address: a token on flap.sh's first BSC template, whose owner can mint and burn from any holder, keeps Ownership NOT renounced (+18) and now names the Portal; flap.sh tokens on BSC on its four later templates, and Faze tokens on Arc, move from +18 to weight 0. On Monad, where the Portal was named by its address at weight 0 whatever the token's code, it is named by the template too: a token on its three templates (TokenV2, FlapTaxToken and FlapTaxTokenV3, every Monad launch but one) stays at weight 0, the line naming the template, and a token on any other code, such as the one launch on an unverified template (0xef07…7777), moves to Ownership NOT renounced (+18) and names the Portal. nad.fun's own tokens have no owner, so a token owned by a nad.fun contract was handed over to it: it moves from weight 0 to Ownership NOT renounced (+18) and is named. A token owned by four.meme's fee Safe, a 2-of-4 multisig whose signers can call any owner function, moves from weight 0 to Ownership NOT renounced (+18) and is named. A token on one of flap.sh's weight-0 templates is weight 0, and named in token.ownerLaunchpad, only when flap.sh's Portal itself records it as a token it launched: anyone can clone a template and hand the clone to the Portal, and such a token moves from weight 0 to Ownership NOT renounced (+18), the line naming “flap.sh's Portal, which has no record of launching this token”, with owner_not_renounced on /v1/analyze; while the Portal cannot be read the token is scored as any live owner. A LiquidLaunch token on HyperEVM keeps Ownership NOT renounced (+18), and the line now names the launchpad: “LiquidLaunch's launchpad, which this token's code lets move any holder's tokens without their approval” on the build its launches run now, “LiquidLaunch's launchpad” on its earlier ones. Pangea's sealed controller and an Argus label read “no powers” on the cards, the other kinds “launch only”. Under such an owner the mint line reads “its owner is …, not a private key” where it read “ownership renounced”.

2026-10-29 · Changed · a four.meme curve, and a pool with no figure, when the pairs come from GeckoTerminal

On an EVM chain the pairs come from GeckoTerminal when DexScreener lists none for the token or does not answer in time. A four.meme token still on its curve read there now answers as it does from DexScreener (the 2026-10-28 entries below): market.dex and pairs[].dex are "fourmeme" where they were "four", and /v1/analyze has launchpad.onCurve: true, market.liquidityUsd: null and the bonding_curve info where it had a low_liquidity or thin_liquidity warning off GeckoTerminal's figure for the curve, which counts the tokens the curve has not sold yet. /v1/liquidity answers lpStatus: "BONDING CURVE", /v1/stress-test no_pool, and the rug score carries the weight-0 Still on bonding curve line in place of the LP-unlocked and low-liquidity lines. Its market.pairAddress is GeckoTerminal's id for the curve, the token's own address, where DexScreener's is <token>:4meme. A pool GeckoTerminal lists without a reserve figure now has liquidityUsd: null where it read 0, with what the 2026-10-28 entry says of a pair listed with no liquidity figure. A GeckoTerminal pool the token is only the quote of (another token's pool or curve priced in it) is no longer read as the token's own, as on DexScreener: never its curve, and behind its own pools on a tie. Its base and quote now come from the pool itself, so pairedWith is filled for a GeckoTerminal pair quoted in a token outside the usual quotes, as it is from DexScreener.

2026-10-29 · Changed · curve tokens: the deployer in the holder book without a Blockscout explorer, the launch on /v1/fresh-wallets, and a graduated curve's holders

On BSC, Hyperliquid and Monad, /v1/holders now names the deployer. Its creator and launchpad were always null there, so no holder carried the creator tag. They come from the deployer lookup /v1/deployer-reputation reads (the wallet that launched the token, and the launchpad contract it called), when it answers within five seconds of the holder read; one still running then leaves both null, as before, and a later read names them. 0x4c99…7777 on Monad, a nad.fun token, reads creator 0x8e54…71a0 and launchpad nad.fun's router, 0x8986…6f91. A deployer that still holds the token is now tagged creator in holders on those chains.

On EVM chains, /v1/fresh-wallets dates a token that no pair feed lists by the block its launchpad curve launched it in, as Bundle Detection and Snipers do: launchSource has a new value, "launchpad_curve", and tokenCreatedAt is that block's time. On Monad and Hyperliquid, which have no Blockscout explorer, such a token answered tokenCreatedAt: null and launchSource: null, so its wallets were aged with no launch to measure them against (0x99fe…7777 on Monad now reads 2026-10-28T20:12:23Z); where there is one, it answers "launchpad_curve" in place of "contract_creation", for the same time, as a launchpad token is created in its launch transaction. The curve then counts as the token's market, so a fresh wallet's sale into it is in soldPct where it was in transferredPct.

Where /v1/holders reads the holder book off the chain, a token whose launchpad curve graduated to a pair a feed lists is now read from the block the curve launched it in. It was read from its first pair's time less 12 hours, which missed the curve's buyers who have not moved since when the curve ran longer than that. derived.launchAnchor is "launchpad_curve" for such a token, and a token with no curve is read as before.

2026-10-29 · Changed · the holder book of a token on a launchpad curve no pair feed lists

A token still on a launchpad curve that no pair feed lists (nad.fun's curves on Monad, LiquidLaunch on Hyperliquid, Faze, Warp and Peach on Arc, among others) now has its holder book read off the chain from the block its launchpad launched it in, where the chain has no holder index (Monad, Hyperliquid) or its index has no rows for the token yet. That read was anchored on the pair feed alone, so /v1/holders answered available: false, reason: "holder_data_unavailable" for such a token, and /v1/rug-score available: false, reason: "holders_unavailable". Both now answer: 0x4c99…7777 on Monad reads 109 holders, with the nad.fun curve's 99.29% tagged launchpad and curve. derived on /v1/holders carries a new field, launchAnchor: "launchpad_curve" when the launchpad's launch block dated the read, "pair" when the pair feed's earliest pair did.

2026-10-28 · Changed · a launchpad's bonding curve among the holders, and four.meme's TokenManager as the owner

On an EVM chain the holder row of a launchpad's shared bonding curve (four.meme's TokenManager2 and TokenManager v1 and flap.sh's Portal on BSC, LiquidLaunch on Hyperliquid, Faze on Arc, flap.sh's Portal on Base, Robinhood and Monad, nad.fun's curves on Monad) now carries the launchpad tag and a new curve tag on /v1/holders on every chain, for the tokens that curve launched: the token is owned by it, or the token's creation or its launchpad lookup names it. Supply any other token sends to that address keeps the tags it had. On BSC and Hyperliquid it carried none (or only owner) and was counted as a wallet: a four.meme token on its curve had the curve's 84.35% as largestRealPct and insiderPct (0x6fdc…ffff), and now has 3.86% and 0. The row stays out of top5RealPct, top10RealPct, top20RealPct, largestRealPct and insiderPct, as a pool's does, and a new field, launchpadPct, is what the launchpad's own contracts hold, as a share of circulating supply. /v1/whales, /v1/copy-traders and /v1/holder-overlap leave such a row out of the wallets as they leave a pool out (on /v1/whales it is one of protocolAccounts). The rug score no longer counts it as a whale or a top holder. When a four.meme token's owner is the TokenManager it launched on, which owns every four.meme token on its curve, can only set the pre-listing transfer limits and renounces at graduation, /v1/analyze carries a new field, token.ownerLaunchpad: "four.meme's TokenManager" (null for any other owner); warnings carries the info owner_launchpad in place of the owner_not_renounced warning, and a mintable, blacklist or whitelist warning reads as its _renounced info, since that owner cannot call them. /v1/rug-score names it at weight 0 where it scored Ownership NOT renounced (+18).

2026-10-28 · Changed · a launchpad curve no pair feed lists, and a pair listed with no liquidity figure

A token still on a launchpad curve that no pair feed lists (Genius, four.meme's FourCore, Virtuals, flap.sh on Monad, LiquidLaunch, Faze, Warp, Peach, Pons and its forks, among others; nad.fun's curve is read as before) now has launchpad.onCurve: true and bondingProgress: null on /v1/analyze when the curve launchpad.curve names still holds a tenth of the supply or more. market stays null, since nothing prices it, and warnings carries bonding_curve where it carried no_pairs. /v1/liquidity answers lpStatus: "BONDING CURVE" for it, with totalLiquidityUsd and marketCap null, where it answered NO LP FOUND, and the rug score no longer charges it for having no DEX liquidity. When that holding could not be read within the call's wait, /v1/analyze answers marketDataUnavailable: true and /v1/liquidity available: false, reason: "curve_unread". A main pair the pair feed lists with no liquidity figure (some Uniswap v4 pools) now has market.liquidityUsd: null where it read 0, and the liquidity_unvalued info where it had the critical low_liquidity; pairs[].liquidityUsd is null for any pool listed with none. On /v1/liquidity the same pool's pools[].liquidityUsd is null where it read 0, totalLiquidityUsd counts only the pools listed with a figure and is null when none has one (it read 0), and note says so. /v1/stress-test answers reason: "liquidity_unvalued" for it where it answered no_pool, and the rug score's dead-token check no longer reads it as liquidity drained to $0. A token whose main pair on the pair feed is its own four.meme or flap.sh bonding curve (four.meme's <token>:4meme pair on BSC, listed with no figure; flap.sh's on BSC, Base and Robinhood, whose figure counts the tokens the curve has not sold yet) trades on that curve, whatever figure the feed gives it. /v1/liquidity answers lpStatus: "BONDING CURVE" for it, as for a nad.fun curve, with totalLiquidityUsd: null, pools: [], dex the launchpad and marketCap the curve's, where it answered POSITION-BASED LIQUIDITY for a four.meme curve and a pool verdict and depth off a flap.sh curve's figure (LP NOT VERIFIED, $9,280 on a $4,191 market cap); any DEX pool the token also trades in beside the curve is named in note and counted in a new besidePools field. A curve of its own behind a deeper pool of its own is left out of pools and totalLiquidityUsd, and note names it. /v1/stress-test answers no_pool for it, where it priced a flap.sh curve's figure. The rug score carries the weight-0 Still on bonding curve line in place of the v3/v4, low-liquidity and LP-not-verified lines, and calls such a token at the launch floor NEVER BONDED, where it read ABANDONED / DEAD. When the pair feed lists a pool at a known $0 beside one with no figure, the one with no figure is the main pair on every endpoint, and totalLiquidityUsd is null.

2026-10-28 · Added · Monad: ?chain=monad

Monad joins the chains every plan covers. ?chain=monad works on every endpoint that takes a chain, on every plan on sale and on the free trial key, and is metered like the other EVM chains (an EVM rug-score is 5 units). Gas and pools are in MON. Monad has no hosted indexer, so its holder book is read off the chain, as on Hyperliquid; launches on nad.fun, flap.sh and Doppler are named.

2026-10-28 · Added · more launchpads on /v1/analyze, and a nad.fun curve as the market

On an EVM chain /v1/analyze has carried launchpad and pairedWith since 2026-10-20; the reference now describes them, with every name launchpad.name answers. Beside the Monad launchpads the entry above names, those now include Stockereum.fun on Ethereum, Genius and four.meme's FourCore launches (as four.meme) on BSC, Virtuals, Pons V1 (as Pons) and flap.sh on Robinhood, flap.sh and o1 Launchpad's Tax and wstO launches on Base, Argus V5 on Arc, and Pangea on Ethereum, Base, BSC and Robinhood. A nad.fun token still on its bonding curve, which no pair feed lists, answered with no market; it is now priced from the curve, with market.source: "curve" and market.curve, and onCurve and bondingProgress on launchpad. On Solana the launchpad is token.timeline.launchPlatform, with token.timeline.launchpad beside it (curve: false for Pangea, which has no bonding curve) and token.mintAuthorityBridge, "Pangea" when the mint authority is Pangea's bridge store. The launchpad on /v1/holders, /v1/dev-tracker and /v1/wallet-reputation is the launchpad's contract address, not its name, and the reference now says so.

2026-10-28 · Changed · a token on its bonding curve on an EVM chain

A launchpad coin still on its curve now reads on an EVM chain as it does on Solana. /v1/rug-score carries scoreLabel there too: "NEVER BONDED" when that is the verdict, else null. A four.meme or flap.sh token whose main pair on the pair feed is the launchpad's own curve has launchpad.onCurve: true on /v1/analyze, with bondingProgress: null (the curve's progress was not read). On Monad, a nad.fun curve that could not be read within the call's wait answers marketDataUnavailable: true on /v1/analyze and available: false, reason: "curve_unread" on /v1/liquidity, where it read NO LP FOUND; the rug score leaves liquidity out of that read. The bonding_curve warning carries detail, its message without the stage.

2026-10-26 · Added · the same-block rotation at launch on /v1/bundles-pro and /v1/snipers

On a busy pool the rotation read (new wallets buying the sells back over the sell minutes) can run out of budget, and the Rotated figure read "?" even where the launch window showed the rotation whole. summary.sameBlockRotation on /v1/bundles-pro and sameBlockRotation on /v1/snipers are new, on Solana: the sales in the launch window whose proceeds paid for another wallet's buy in the same block, two or more, with hops, sellers, wallets (the wallets that bought in a hop), pct (the supply they bought with the sales' proceeds, each token once: a hop that passes on supply bought in an earlier hop is counted in handedOn, not again in pct), label (the launch tool the hops name, such as Proxima, or null) and, once read, heldPct and holding, what those wallets hold now. null or absent when the window shows none. The scan page prints it on the Rotated figure where the rotation read found no rotation. The rug score does not read it.

2026-10-25 · Added · /v1/exit-playbook, /v1/insider-pressure and /v1/stress-test

The scan page's three trader tools, on every paid plan and every chain. /v1/exit-playbook replays the earlier launches by the same hands (the deployer, its operator bands' funders, shared bundle wallets): where they usually peaked, how fast, and how far they fell after, and where this token is on that timeline. /v1/insider-pressure sets what the bundles and snipers paid against today's market cap: the multiple they sit on and what selling now would bring. /v1/stress-test prices a buy of ?size= dollars sold after each insider group sells first. Each is one unit; stress-test is five on an EVM chain, where it reads the rug score, and is listed in units.heavyOnEvm. The plan tables now count 30 endpoints.

2026-10-24 · Added · /v1/deployer-reputation reads the record of the wallet that funded the creator

A creator that launches each token from a fresh wallet has no record of its own. funderHistory is new, on Solana and every EVM chain: the wallet that first funded the creator, the tokens it launched itself, and those of the other deployer wallets it first funded, with how each ended. DeFade keeps each deployer's first funder from every lookup on, so the record grows as tokens are scanned. An exchange, a bridge or another service is never matched. /v1/rug-score reads it on the deployer line, in the first 48 hours of a token: one earlier rug +7, two +14, three or more +22; what the creator's own history already charged comes off it.

2026-10-23 · Changed · a tool that bundled a token after its launch reads "Bundled with"

A launch tool was always named as the tool the token was launched with, even when nothing in the launch showed it: a token created on pump.fun with a plain dev buy and bundled through Sumo 20 hours later read "Launched with Sumo", on the evidence of its creator's later transactions. summary.launchPlatform on /v1/bundles-pro and launchPlatform on /v1/rug-score now carry atLaunch: true when the launch itself shows the tool (its program in the launch window, its launch fee there, its own metadata gateway, its one-transaction EVM launch, or a launch bundle that bought through it), false when only the creator's history or a later bundle does. The rug-score line, the scan page and the badge beside the token name read "Bundled with Sumo" for the second. A new via, bundle, names the tool off a bundle group that bought through it, three or more of its wallets and at least half of the group, with wallets, groupSize, groupType, afterSec and detail; it is read after the launch's own evidence and ahead of the creator's history, on every chain. A result cached before the change carries atLaunch too, read off via. The score's weight is unchanged: +10 either way.

2026-10-23 · Docs · the launch tool, the terminals and the known bundlers on /v1/bundles-pro

No API behaviour changed here. /v1/bundles-pro has carried five summary fields the reference did not describe, and its field list now does: launchPlatform, the launch tool the token was launched with (Proxima, Sumo …) and what showed it; terminals, which trading terminals the launch buyers came through and how concentrated on one of them; knownBundlers, the wallets in the token seen bundling other launches, by tool; launchToolWallets, every wallet in the scan known to have run a launch tool; and redFlags, the launch red flags with the sentences the scan page prints. launchPlatform on /v1/rug-score is described too: the same tool, cut to label and via, read from the bundle scan.

2026-10-23 · Fixed · an EVM token whose pool was funded days before its first trade is read from that trade

On an EVM chain, Bundle Detection and Token Snipers date a launch by the first transfer of the token into or out of a pool, which for nearly every token is the moment trading opens. A pool funded days before its first trade broke that: AXIS on Base had its pool created on 19 October and its first trade on 21 October at 11:00 UTC, $11.5M in that hour. The scans read the quiet day after the pool, and the page said "No Buys Found" and "No Snipers Detected", /v1/bundles-pro answered risk NONE and /v1/fee-fingerprint no_buyers, on a token trading 60,000 times a day. When the first day from the pool holds no trade, both scans now move the launch to the token's first trade and read from there: launch.anchor is first_trade, with firstTradeAfterSec and poolAnchor. When that first trade lies past what one scan reads while the token trades now, the answer says so instead: summary.launchNotReached on Bundle Detection, read as unread: "launch_not_reached" with risk UNKNOWN on /v1/bundles-pro and as that reason on /v1/fee-fingerprint, and launchNotReached with scanDegraded on Token Snipers. A token that has never traded keeps "No Buys Found".

2026-10-23 · Fixed · an EVM bundle sweep that stopped inside the launch window is no longer a clean result

On an EVM chain, a bundle sweep cut off before the end of the launch window (by its transfer cap or by the RPC) that found nothing in what it read answered risk: "NONE" in green on /v1/bundles-pro, and the scan page read it "No Bundles Detected" over a partial-coverage warning. On Solana the same scan, with seconds of its launch window unread, reads risk: "UNKNOWN" with summary.unread: "window_gap", and the page says "No Bundles In What Was Read — Part Of The Window Unread". The EVM answer now says the same: window_gap on /v1/bundles-pro, the same final reason on /v1/fee-fingerprint (before no_buyers, as on Solana: no buyer in a window read in part is not none at launch), the same headline on the page and in the Telegram bot, and the score's caveat naming the seconds not read. The unread stretch runs from coveredSeconds to the end of the launch window (launchWindowSeconds, or the token's age when that is less). A sweep that read the whole launch window and stopped later is still a clean answer, with coverageFull: false and coveredSeconds saying how far it read.

2026-10-23 · Fixed · an EVM bundle scan that could not read the launch is no longer a clean result

On an EVM chain, /v1/bundles-pro answered a scan with no groups as risk: "NONE" in green even when the scan itself said it had not tested the token: no transfer of the token in the window it swept, transfers but no buyer set built from them, or most funder lookups failed. The scan page already said "Scan Incomplete" for each. These answers now read risk: "UNKNOWN" with summary.unread (no_transactions, no_buyer_set or scan_degraded), as Solana's do, and /v1/fee-fingerprint gives the same word as a final reason where it answered pending: true (reason: "stale_scan") on every call. A sweep that read the launch window, stopped short of its horizon and found nothing is unchanged: the page reads it "No Bundles Detected" with a partial-coverage warning, and the answer carries coverageFull: false, coveredSeconds and degradedReasons. One that stopped inside the launch window reads window_gap (the entry above).

2026-10-23 · Fixed · a Solana bundle scan that read no transactions is no longer a clean result

When Bundle Detection could not read a single transaction of a token — the RPC did not answer, or had not indexed a token created moments before — /v1/bundles-pro answered risk: "NONE" in green with no groups, held for 15 minutes, and the scan page read "No Bundles Detected". Every token has at least the transaction that created it, so nothing had been checked. The answer now reads risk: "UNKNOWN" with summary.unread: "no_transactions" and summary.noTransactionsRead: true, is held one minute so that a call after that scans again, and the page says "Scan Incomplete — No Transactions Read". /v1/fee-fingerprint answers such a scan with reason: "no_transactions" rather than pending. A scan that read part of the token's history and none of it near the launch reads unread: "launch_not_reached", as one that reached no launch already did.

2026-10-23 · Added · holderBook on /v1/funding-origin, /v1/funding-graph and /v1/sybil-cluster

These three trace the top holders taken from the token's holder list. When that list was read only in part — a Solana token with more token accounts than one scan reads (about 10,000), a page of the list that could not be read, or an EVM chain whose holder index served only part of its list, or none, so that it was rebuilt from recent transfers — the holders traced were the largest of those read: the true largest could be missing and coordination among the rest could go unseen, and the answer did not say so. Each answer now carries holderBook: null when the list was read whole, otherwise why it was not (reason), how many holder accounts were read (read) and whether the 20 largest token accounts were read as well (largestRead). The scan page prints the same note on the three cards, on every chain. The read limit itself is unchanged.

2026-10-23 · Fixed · /v1/sybil-cluster bands no longer depend on which scan finished first

Sybil Cluster extends a band with wallets that share its bot fee settings, which Bundle Detection reads. On a new token both start together, and Sybil Cluster usually finished first: its bands were clustered without those links and kept for half an hour, on the scan page and on the API alike, so the same token could read differently depending on which scan finished first. The answer now carries feeEdgesRead, false while no bundle scan was there to read. Once Bundle Detection has landed, the next request clusters the bands again: the scan page asks for that by itself, and so does /v1/rug-score, which names sybil-cluster in pending until the new bands are in, on every chain. The new bands can hold more wallets and more supply than the first answer did. If your integration calls /v1/sybil-cluster directly, call it again after /v1/bundles-pro has answered when feeEdgesRead is false.

2026-10-23 · Fixed · a wallet address on an EVM chain answers 400, not a retryable 502

A wallet address sent to an EVM endpoint with ?chain= was read as a token. /v1/holders and the endpoints that read the holder list answered it the 502 holders_unavailable — "token not indexed yet" — which a client retries, and the others answered it as a token with no pool, no socials or an empty chart, and charged it. Every EVM endpoint that takes a token address now checks the address first, as the Solana endpoints check for a token mint. An address that holds no contract and has sent a transaction is a wallet, and answers 400 { "error": "Not a token contract", "detail", "addressType": "wallet" }, not charged; an EIP-7702 delegated wallet is one too. An address that holds no contract and has never sent a transaction is answered as before: a token deployed seconds ago can read that way on a node a block behind. The check takes one read per token, kept for six hours, and never holds a call more than three seconds. If your integration retried a 502 on a wallet address, handle this 400 as a bad address instead.

2026-10-23 · Changed · /v1/deployer-reputation grades the creator's whole launch history

On Solana the grade was drawn from up to 20 of the creator's newest launches. A serial deployer's newest launches are the ones that died on the bonding curve, so a wallet whose older launches reached a market and collapsed could read as a Serial Launcher instead of a Serial Rugger. DeFade now keeps every launch it reads for a creator and judges each one, and the grade, the counts in reputation and previousTokensChecked cover all of them; previousTokens still lists up to 20, now the ones that say the most, each with launchedAt. The new launchHistory says how many launches are kept and judged. Grades can change for creators with long histories.

2026-10-22 · Changed · /v1/bundles-pro reads the earliest 400 launch-window transactions

On Solana, a launch window with more landed transactions than the parse budget is read from its start, and the budget is now 400, up from 200. Figures on busy launches can rise as groups past the 200th transaction come into the read. summary.scanIntegrity.parse.readToSec is new: the second, counted from the launch, that the last transaction read landed in (null when a parse request did not come back). With truncated: true, a result covers the launch to that second only; the scan page says so ("the scan read the earliest 400, to +45s").

2026-10-22 · Fixed · /v1/bundles-pro on a launch window with seconds left unread

On Solana, Bundle Detection can reach a launch and still leave seconds of its 180-second window unread, on a launch too busy to page through or when a read there fails. Such a result now carries summary.scanIntegrity.window ({ gaps: [{ fromSec, toSec }], complete }, offsets from the launch) and summary.completeness.gaps. When nothing was found in the rest, the scan page says "No Bundles In What Was Read — Part Of The Window Unread", but /v1/bundles-pro answered risk: "NONE". It now reads risk: "UNKNOWN" with summary.unread: "window_gap", after the three earlier reasons, and /v1/fee-fingerprint answers such a scan with reason: "window_gap" where it answered no_buyers with noBuys: true. Groups found in what was read are reported as before. On /v1/rug-score a warning names the seconds ("Bundle scan could not read +36s to +62s of the launch window …"); it carries no weight, so the score does not change.

2026-10-20 · Docs · the reference shows what the endpoints send

No API behaviour changed here; the reference was checked against the routes and corrected. /v1/bundles is the lighter detector the scan page stopped showing on 2026-07-18: its bundledPct is what the groups bought in the first 60 seconds, not what they hold and not Bundle Detection's figure, so call /v1/bundles-pro for the figure the page shows. On Solana, /v1/bundles-pro called without ?wait waits for the whole scan (a cold scan usually takes 60–80 s; past 150 s it answers the unbilled 504), where the reference said it answered at once; summary.bundledBasis is null rather than absent for the plain launch share, and summary.pending is absent rather than empty once the scan is complete; postWindowScan, fundersUnvetted, routersResolved and a pending linkedHolders are EVM-only. The samples for /v1/bundles, /v1/bundles-pro, /v1/historical-bundles, /v1/insider-network and /v1/copy-traders, and terminalUsage on /v1/whales, showed keys no chain sends (bundle wallets as strings, pctSupply, bundleCount, stillHeldPct, spike startedAt, cluster size, numeric wallet1Pct on Solana); they now show the real ones. /v1/wallet-reputation's tier of UNKNOWN was described as "never flagged": it means no scan has seen the wallet as a holder, and the answer's deployer, bundler and operators records, now documented, can still name a serial deployer or a known bundler. creatorSource: "caller_supplied" on /v1/dev-tracker is the website's value. And the 2026-10-19 Infinity entry named /v1/bundles where it meant /v1/bundles-pro.

2026-10-20 · Fixed · /v1/snipers on a launch it could not read; an unpaid card subscription's key

On Solana, /v1/snipers answered a token whose transactions it could not read, and whose launch it did not reach, with risk: "UNKNOWN" in riskColor: "green" and no partial flag. It now carries partial: true and riskColor: "gray", as the full answer does. And a card subscription that Stripe marks unpaid once its payment retries run out (a setting used in place of cancelling it) kept its API key, carried into each new period unpaid; the key now stops at that point, and starts again as soon as the invoice is paid. While Stripe is still retrying a payment the key keeps working, as the payment-failed email says.

2026-10-20 · Fixed · /v1/fee-fingerprint answers a scan with no buys; /v1/dev-tracker answers an unknown creator; the scan page scores what /v1/rug-score reads

/v1/fee-fingerprint answered pending: true (reason: "stale_scan") for good, charged on every call, for a token whose bundle scan ran and had nothing to fingerprint: no buy in the launch window, or a launch it could not read. Calling /v1/bundles-pro first, as the docs said, changed nothing. It now answers empty groups, stats: null and the reason (no_buyers with noBuys: true, too_few_buyers, launch_not_reached, no_buyer_set or scan_degraded); on an EVM chain a bundle scan that could not run answers available: false with its reason. pending now means only that no bundle scan has run. /v1/dev-tracker answered a token whose creator could not be identified with a 400 { "error": "Invalid address format" }, which blamed the address you sent; it now answers status: "UNKNOWN CREATOR", as documented. On Solana, /v1/rug-score no longer names dev-tracker in failed for such a token: there is no dev wallet to read, and the score goes on without one, as on the scan page. And on Solana the scan page scored a token without four of the dev tracker's fields (how many wallets the dev's supply went to, whether that was a distribution, and a third-party launch payer's position) and without the snipers' terminals, all of which /v1/rug-score reads. The two share a five-minute score cache, so a call soon after someone scanned the token could return the page's figure instead of its own. The page now reads them too.

2026-10-20 · Fixed · /v1/bundles-pro and /v1/snipers carry the scan page's transferred figure; /v1/token-price charts the page's pool and does not charge an outage

/v1/bundles-pro on every chain and /v1/snipers returned only transferredPct: every transfer out of the wallets, counted again each time a token moved on, which the scan page does not print. On a launch whose bundle wallets passed their supply to wallets that then sold it, the API read 79.8% where the page's Bundle Detection card read 37.4% (and 79.68% beside the page's 0% on another). Both now carry the page's figure too: summary.transferredUnsoldPct on /v1/bundles-pro and stats.transferredUnsoldPct on /v1/snipers, the transfers less what the recipients sold on, sent back or still hold, never past the supply nor, for the bundles, past bundledPct. transferredPct is unchanged. On Solana, /v1/token-price charted the pool DexScreener lists with the most liquidity, which for a token that has just graduated is its retired bonding curve, and charted nothing when DexScreener listed no pool; it now charts the pool the scan page charts, found through GeckoTerminal when DexScreener lists none. And a chart no price source answered for (every source down, not a market with nothing to trade) was a 200 with no candles, charged, on every chain; it is now a 502 { "error": "price_unavailable", "reason" }, not charged. If your integration read unavailable: true from /v1/token-price on an EVM chain, handle the 502 and retry.

2026-10-20 · Fixed · a read that failed is no longer answered as a clean result

On Solana, /v1/bundles-pro answered a launch its scan could not read (never reached, or reached with no buyer set built from it, or read degraded) with the empty result's risk: "NONE", where the scan page says the result is not a clean one; it now reads risk: "UNKNOWN" with summary.unread naming why. /v1/copy-traders answered portfolios it could not read as "0 copiers", and /v1/smart-money histories it could not read as INSUFFICIENT DATA, cached for an hour and half an hour; when too little could be read they now answer a 502 (portfolios_unavailable, history_unavailable), not charged and not cached, and a result missing some reads says how many (summary.walletsUnreachable, summary.walletsUnreadable) and is held five minutes. /v1/funding-origin served from its 30-minute store dropped resolvedCount and unknownCount and rebuilt risk as if every holder had been traced, so the same token could read lowConfidence: true on one call and false on the next; both counts are now kept. And /v1/dev-tracker held the transient INDEXING status for an hour: it is now held a minute, and NOT TRACKED five.

2026-10-20 · Fixed · credits survive a renewal and a resubscription, and a bad key on /v1 is a 401 for every client

A USDC renewal of a key that had already expired brought the key back with a balance of 0 credits and its usage reset, and a renewal after a call had found the key expired issued a second key at 0 credits; either way the credits you had bought were lost. A renewal now extends the same key, balance and usage intact. When a mailbox is issued a new key, by card or USDC, any credits left on its keys that no longer work move onto it, as the cancellation emails have always promised. A missing, mistyped or expired key sent to /v1 from a script (curl, python-requests, httpx, Go, Java) was answered 403 { "error": "Forbidden" } before the key was read; it is now the documented 401 (API key required, Invalid API key or API key has expired) for every client. And these docs described the overage switch as what lets credits pay for requests past your limits: credits do that on their own, and the switch turns on automatic credit-pack charges to your card, uncapped. If you switched overage on only to use credits you bought, you can switch it off.

2026-10-20 · Fixed · /v1/snipers, /v1/fresh-wallets, /v1/whales, /v1/smart-money and /v1/copy-traders on Solana read as the scan page reads them

The scan page runs Bundle Detection on every Pro scan and, once it is in, asks Snipers again and relinks Fresh Wallets to the bundlers. The standalone endpoints never ran it: on a token nobody had scanned, /v1/snipers counted the bundle wallets as strangers, so its relays to them read as transferred supply (stats.bundleCohort: false, cached two hours), and /v1/fresh-wallets never linked a fresh holder to the bundlers that funded it, so its risk could miss the CRITICAL floor. Both now start Bundle Detection when their answer was read without it, and name bundles-pro in a new pending field with complete: false; when the bundle scan is already in, the call asks again or relinks at once. /v1/whales labels a holder the dev sent supply to Dev-linked (received from dev), danger, from the Dev Wallet Tracker's answer, which the API never ran: it now runs the tracker first, as the page has it. And /v1/whales, /v1/smart-money and /v1/copy-traders shared one cached answer per token with the scan page whatever holder list it was read from (the deep owner list, or the 20 largest token accounts on a token too big to walk whole), so each answered the other's; they are now kept apart, as /v1/kol already was. On those 20-account lists /v1/copy-traders printed every wallet1Pct and wallet2Pct as "?"; it now prints the holder's share. If your integration treats a Snipers or Fresh Wallets answer as final, check complete.

2026-10-20 · Fixed · four things you were charged for that were not answers

On Solana, an address that is not a token (a wallet, a program, a pool) sent to a module endpoint was charged and answered as if it were one: /v1/liquidity read it as NO LP FOUND with risk CRITICAL, /v1/socials with every link null, /v1/token-price with an empty chart, /v1/snipers with 0 snipers, /v1/fee-fingerprint as pending for good. Every Solana module endpoint now answers it as /v1/analyze does: 400 { "error": "Not a token mint" }, or { "error": "Address not found on-chain" } for an address that does not exist, not charged. On an EVM chain, a holder list that could not be read was a refunded 502 on /v1/holders, /v1/kol, /v1/fresh-wallets and /v1/rug-score only; /v1/whales, /v1/insider-network, /v1/smart-money, /v1/copy-traders, /v1/funding-origin, /v1/funding-graph and /v1/sybil-cluster answered 200 available: false and charged it, five units on the last three. They now answer the same refunded 502 holders_unavailable. /v1/holder-overlap counted a mint named twice in ?mints= as two tokens, so every holder they share counted twice; it now counts it once, as /v1/wallet-overlap does. And /v1/usage (and the MCP get_usage tool) kept reporting last period's units after the monthly reset, until the key's next call: thisPeriod and remainingThisPeriod now start the new period at the reset. If your integration read available: false with reason: "holders_unavailable" on an EVM chain, handle the 502 and retry.

2026-10-20 · Fixed · an EVM /v1/rug-score no longer calls an unfinished liquidity or bundle read complete

On a Uniswap v4 or PancakeSwap Infinity pool (most Robinhood launches), the liquidity read answers after about 6 s while the check of who holds the pool's positions runs on for 13–27 s. The score read that first answer, charged "lock status not verifiable" (+6) where a locked pool reads −3, and the call answered complete: true. Bundle Detection likewise answers once its main scan is in while its late stages (the post-launch exit sweep and the linked holders) finish: a token scored 25 SOME RISK with the sweep out and 45 ELEVATED RISK once it was in, and asking again inside two minutes returned the 25. Now liquidity is named in pending while its lock check runs, and bundles-pro while its late stages do; the call gives the late stages what is left of its budget, and a score taken before they landed is never served after they have. If your integration waits for complete: true, it now waits for these as well; call again after 15 s or so.

2026-10-20 · Fixed · Solana answers read the holder count, the pump.fun state and the launch time the scan page reads

On Solana, totalHolders is the number of the largest accounts read for topHolders, so it stops at 20; these docs called it a holder count and showed 412, a value it cannot take. The scan page counts every holder instead, and scores that count. /v1/holders and the holders object of /v1/analyze now carry it as totalHolderCount, with holderCountCapped (true past 10,000, where counting stops); it is null when the count was not in within a few seconds, and a call a few seconds later has it. /v1/rug-score now scores that count as the page does. Without it the score could not charge "Low holders" (20 to 99 holders) or a thin holder base for the market cap, and when its own fallback read failed it charged "Only 20 holders" on any token; while the count is still being read the call names holders in pending. /v1/liquidity, and the liquidity read inside /v1/rug-score, now read a pump.fun token's curve state as the page does: a graduated coin reads pumpFunGraduated: true, and a coin still on its curve that DexScreener does not list yet reads BONDING CURVE where it read NO LP FOUND (and cost 15 points of rug score). /v1/dev-tracker, and the Dev Wallet Tracker read inside /v1/rug-score, now read the token's launch time as the page does. The MCP connector key included with DeFade Pro now scores with every Pro check that subscriber's own scans run, where it read two of the six. If your integration read totalHolders as the holder count, read totalHolderCount.

2026-10-20 · Fixed · /v1/rug-score answers within a bounded time, and a call you abandon is not charged

?wait= bounds the module scans, but the score's own prerequisites (the holder and liquidity reads on EVM chains, the analysis and liquidity on Solana) were awaited however long they took. They are read again whenever they are more than two minutes old, and on Robinhood a token's holder book often has to be rebuilt from the chain's transfers, which can take 30–60 s, so a call with ?wait=full could run well past 45 s with no answer. The call now waits for them 25 s at most, or your ?wait= if that is longer. Past that it answers 504 module_timeout with retryAfterSec and a pending array naming the reads still running; it is not charged, and the reads keep running, so the next call picks them up. A call now answers within about 25 s plus the score itself, a few seconds: give it 60 s. Separately, a call your client gave up on before the answer arrived (its own read timeout, a dropped connection) used to be charged, because the refund ran only once an answer had been sent. It is now given back, units or credit, and still counts toward the per-minute and per-day limits. If your integration retries on a client-side timeout, also retry on a 504 after retryAfterSec.

2026-10-20 · Fixed · /v1/rug-score on Solana runs Bundle Detection, Sybil Cluster, Funding Graph and Historical Bundles

On Solana the score read Bundle Detection only when a scan of the token on defade.org had left its result in the cache, and never read Sybil Cluster, Funding Graph or Historical Bundles. On a token nobody had opened on the site, the first call scored without a single bundle line (bundleEngine null, bundleSubScore 0, no bundles entry in moduleImpact) and still answered complete: true. The scan page's no-KYC rails line, a Sybil Cluster finding, never reached the API, and a score short of it could print a "Score floored to ELEVATED RISK" line the page did not. On every paid plan the call now starts all four with the other modules, posted as the scan page posts them, and names each in pending until it has landed: bundles-pro, sybil-cluster, funding-graph, historical-bundles. Bundle Detection on a token nobody has scanned can take a minute or more, longer than ?wait=full, so the first call on a new token usually answers with bundles-pro pending: the scan keeps running, and a later call reads it. As on the scan page, once Bundle Detection has landed the call reads Snipers again when its first read came before the bundle wallets were known, and relinks Fresh Wallets to the bundlers; until then snipers and fresh-wallets can be pending too, scored with their first answer. A module whose read fails during the call is now named in failed on Solana as on EVM chains, and complete can be true beside it. A key whose plan does not include these endpoints (the trial key, grandfathered 16-endpoint Starter keys) does not run them, and notOnPlan lists the six checks its call did not run. The call still costs 1 unit. If your integration waits for the final score, wait for complete: true with no failed.

2026-10-20 · Changed · a key sent to the website's own routes is an API call

The scan page on defade.org reads its modules from routes under /api/, which are not part of this API and are not documented here. A key sent to one of them is now handled as the /v1 call that route serves: your plan's endpoints and chains, its rate limits and the units that endpoint costs apply, a refusal is answered before anything is charged, and an answer of 400 or more gives the units back. On any other website route a key grants nothing. If your integration calls /api/… with your key, move it to /v1, whose responses are the documented ones.

2026-10-19 · Changed · PancakeSwap Infinity pools are read as Infinity pools

PancakeSwap Infinity keeps its pools in a CLPoolManager and their tokens in a separate Vault; a 32-byte Infinity pool id was read as a Uniswap v4 pool. On Base, BSC and Robinhood: /v1/liquidity now verifies an Infinity pool's positions (the pool's version reads "infinity", and positionLock.venue says which singleton was checked), where it answered "position-based, lock not verifiable" for liquidity held in a locker; /v1/bundles-pro reads an Infinity launch's buys out of the Vault, where it saw none; /v1/holders tags the Vault pool, outside the concentration figures, where it counted as a contract. Pools no pair feed lists include Infinity pools too, and /v1/bundles-pro now reads a launch from them instead of answering reason: "no_pair". (This entry named /v1/bundles until 2026-10-20; on an EVM chain bundle analysis has only ever been /v1/bundles-pro.)

2026-10-19 · Added · pools the pair feeds do not list yet are read on-chain

A young token whose pool DexScreener and GeckoTerminal had not indexed read NO LP FOUND on /v1/liquidity (and +15 on /v1/rug-score), with no price or market cap on /v1/analyze and no candles on /v1/token-price, while it traded on-chain. On an EVM chain those calls now find the token's Uniswap v4 pools from the chain when the feeds list none: /v1/liquidity values each pool from its live positions at the pool's own price (source: "onchain"), /v1/analyze's market carries the same pool with source: "onchain", and /v1/token-price builds its candles from the pool's swaps (source: "onchain", partial: true when the oldest trades were past the read's budget). A pool found but not valued answers available: false, reason: "onchain_pool_unvalued" on /v1/liquidity and liquidityUsd: null on /v1/analyze, never as missing liquidity.

2026-10-19 · Added · swapFees on /v1/rug-score for EVM tokens traded through a fee hook

A token launched through based.bid has no tax in its own contract: its pool's Uniswap v4 or PancakeSwap Infinity hook charges the fee, and the launcher can change it at any time, up to 20%. The EVM answer now carries swapFees: buyBps and sellBps (the total charged on a trade now), the buy / sell split into builderBps, protectionBps, adminBps and totalBps, maxTotalBps (the cap), feeMode, controller and controllerKind, read from the hook itself. It is null for every other token. The fee is also named in signals; a wallet that can change it and is not the token's live owner scores 10.

2026-10-19 · Fixed · /v1/rug-score on an EVM chain no longer names smart-money pending

The EVM score has not read Smart Money since 2026-10-14, but the call still waited for it inside its budget and named it in pending whenever its read had not finished, so every ?wait=0 call answered coverage: "partial" and complete: false, even when every module the score reads was cached. The call still starts Smart Money, so the /v1/smart-money call that follows answers from cache (or joins the read already running), but it no longer waits for it, with ?wait=full included, and never names it in pending or failed. A score whose modules are all cached now answers complete: true with ?wait=0. Smart Money held back on a young chain is still named in skipped.

2026-10-19 · Docs · every endpoint entry describes its EVM answer

No API behaviour changed here. The reference described each endpoint's Solana answer, and the entries without an On EVM chains note read as if their EVM answer were the same. Every entry that runs on an EVM chain now has one, saying what that answer carries and what it lacks, and the notes written on 2026-10-14 were checked again. Documented fields an EVM chain never sends: on /v1/socials the link strings, linkCount and socialScore (its twitter is the X sentiment object); on /v1/liquidity lpBurned, lpLocked, poolCount, poolLocks, lpLockable, lpNote, lpMint, pumpFunGraduated, rugCheckScore and lpEvidence; on /v1/dev-tracker the token amounts, creatorSource, creatorInferred, walletBalance and the lock, treasury, custodial and launch-platform fields; on /v1/snipers firstTxTime (which the earlier note said reads the same), terminals, activeTerminals and migrationCrankersExcluded; on /v1/whales terminalUsage; on /v1/insider-network connectionsTotal; on /v1/funding-origin totalKnownSupply, unknownSupply, resolvedCount and unknownCount; on /v1/bundles-pro hiddenBundleCount; on /v1/rug-score scoreLabel, bundleSubScore, bundleEngine and proChecksLocked. Fields that mean something else there: a /v1/historical-bundles bundle's totalPct is a share of the window's buys, not of supply; the coveragePct of /v1/funding-origin counts the bridged share; /v1/token-price?type=30m returns hourly candles; and on /v1/rug-score smart-money can be pending although the score does not read it. The Error Handling table said /v1/kol answers 503 on a chain with no holder indexer: it answers the 502. Some Solana descriptions were wrong as well: socialScore is a label (STRONG, MODERATE, WEAK, NONE), not a number; lpStatus reads LP BURNED, LP LOCKED and so on; /v1/copy-traders returns pairs of wallets (wallet1, wallet2, sharedTokens …); the /v1/holder-overlap edges join each shared token to an input, with a weight; and several samples showed keys no chain sends. Every :mint that takes a 0x address now says so.

2026-10-19 · Changed · /v1/analyze on an EVM chain no longer carries proEvm or beta

Both were the website's own flags. proEvm was worked out for DeFade's internal call, not for your key, so it read false on every API call whatever the plan; every /v1 call already runs the Pro checks on every chain. beta was a constant. Neither gated anything. The EVM answer, documented in the /v1/analyze entry, is the contract and market read and has no risk object: on an EVM chain the score is /v1/rug-score.

2026-10-19 · Fixed · /v1/fresh-wallets on an EVM chain without holder data is not charged

When the holder book could not be read, /v1/fresh-wallets on an EVM chain answered 200 { "available": false, "reason": "holders_unavailable" } and charged its 5 units. It now answers 502 { "error": "holders_unavailable", "reason", "message" }, not charged, as it does on Solana and as /v1/holders, /v1/kol and /v1/rug-score do.

2026-10-18 · Changed · /v1/deployer-reputation and /v1/fresh-wallets on every paid plan

Lite and Starter keys now reach both endpoints, on every chain, and no longer get the 403 with requiredTier: "growth_all". On Solana, /v1/rug-score reads Deployer Reputation and Fresh Wallets on every paid plan, so its pending can name them there too. notOnPlan now appears only for a key whose plan does not include the two endpoints: the free trial key, and grandfathered Starter keys with the 16-endpoint list. The plan tables and /api/pricing count all 27 endpoints on every plan on sale, and the growthEndpoints fields that /v1 and /api/pricing carried for a day are gone.

2026-10-17 · Added · /v1/deployer-reputation and /v1/fresh-wallets, from the Growth plan up

The scan page's Deployer Reputation (the creator's earlier launches: how many, how many are alive or dead, and whether the record reads as a serial rugger) and Fresh Wallets (the share of supply held by wallets opened shortly before the launch) are now on the API, on every chain, for Growth, Pro and Enterprise keys. On Lite and Starter both answer 403 with requiredTier: "growth_all", before the meter, so asking costs nothing. Each costs 1 unit, except fresh-wallets on an EVM chain, which costs 5 and is now listed in units.heavyOnEvm. On Solana, from Growth up, /v1/rug-score reads both checks too, posted as the website posts them, and pending can name them while they compute; below Growth the score is unchanged and a new notOnPlan field names the two checks it did not read. The plan tables and /api/pricing count 27 endpoints: all 27 from Growth up, 25 on Lite and Starter.

2026-10-14 · Fixed · an EVM rug score with no holder data is not charged

When the chain's holder indexer could not be read, /v1/rug-score on an EVM chain answered 200 { "available": false, "reason": "holders_unavailable" } with no score, and charged it. It now answers 502 { "error": "holders_unavailable", "reason", "message" }, as /v1/holders does for the same token, and gives back the 5 units. Call again in a few seconds.

2026-10-14 · Changed · /v1/rug-score on an EVM chain costs 5 units

With the composition below, an EVM rug score reads every module for the token — holders, liquidity, snipers, deployer, historical bundles, creator, dev tracker, insider network, fresh wallets, bundles, funding graph, smart money and sybil clusters — before it reads the score, and a cold call costs about 2.5 times a funding-origin call to serve. It is now metered like the other heavy EVM calls: 5 units on Ethereum, Base, BSC, Robinhood, Arc and Hyperliquid, on every plan and on the free trial key (whose 3,000 units buy 600 EVM scores). The MCP tool get_rug_score is metered the same way. On Solana it stays at 1 unit. A score that fails on our side gives back all 5 units, and units.heavyOnEvm on /v1 and /v1/usage now lists rug-score. Past your monthly allowance an EVM rug score takes 5 overage credits ($0.125), not 1. With 1–4 units left and fewer than 5 credits it is refused with 429: the body names its cost and your unitsLeft, credits.creditsNeeded is 5, and a note says whether your 1-unit calls still go through. The monthly refusal's limit now reads in units (“750 units/month”), and X-RateLimit-Remaining is the units left. If you budget an EVM integration by calls, count each rug score as five units.

2026-10-14 · Changed · /v1/whales, /v1/kol, /v1/smart-money and /v1/copy-traders read the holder list the website reads

On Solana these four endpoints used to read the 20 largest token accounts. /v1/whales and /v1/kol now read the full deep holder list the website reads (about 300 holders, summed by owner, pools tagged), so a whale or a notable wallet below the twentieth account is no longer missed. /v1/smart-money and /v1/copy-traders are sent its first 50, but they still read only their top 12 and top 6 holders: what changes for them is that those holders are now counted by owner, with pools tagged, not how deep they read. Their cost and summary.analyzed are unchanged. On a token with too many holder accounts to read in full, or when the deep read fails, all four read the 20 largest accounts as before. /v1/kol's percentages are computed against the token's real supply; it was dividing by 1. /v1/whales now also labels a whale the creator funded “Dev-linked”, as the website does. Field names and shapes are unchanged, and so are the EVM chains.

2026-10-14 · Changed · /v1/rug-score runs the same composition on every chain

The time-budgeted composition introduced on 2026-10-01 for Solana now runs on Ethereum, Base, BSC, Robinhood, Arc and Hyperliquid too: the module scans start at once, the call waits its budget (5 s by default, ?wait=<seconds> 0–25, ?wait=full up to 25 s) and scores what has landed; the rest is named in pending and keeps running server-side, so a second call — or one with ?wait=full — returns the complete score. The budget bounds the Pro modules only: the holder and liquidity reads (and on Solana the base analysis) are awaited outside it, so they are never pending — liquidity no longer appears in Solana's pending. On EVM, pending names snipers, deployer, historical-bundles, creator, dev-tracker, insider-network, fresh-wallets, bundles-pro, funding-graph, smart-money or sybil-cluster. coverage is the string full | partial | free on every chain — full when the Pro modules fed the score and nothing is pending, not that each module did — and complete is true when pending is empty. On EVM, pending lists only the modules the score has not read yet: a module whose result is already cached is never pending, even with ?wait=0. An EVM answer also carries modules (an object of per-module booleans: which fed the score), modulesIncluded, modulesTotal, modulesReportedEmpty, emptyModules, skipped (modules not run on that chain) and failed (modules whose read failed during the call, so the score did not read them: not pending, and calling again retries them); the former EVM-only expectedModules, revealAfter and proFindingsAvailable are gone. proChecksLocked is a per-response count and reads 0 for every API key: every /v1 call is scored with the Pro checks. If your EVM integration read expectedModules or revealAfter, read pending and complete instead. Calling rug-score first warms every module for that token, so per-module calls that follow answer from cache.

2026-10-14 · Breaking · a module's refusal answers with its own status, and is not charged

When a module inside the analysis refused a request, the API used to answer 200 with the module's error field in the body, and charge the unit. It now passes the module's status through: a 400 (Not a token mint, Address not found on-chain …), a 404, a 429 from the module's own throttle, or a 504 when the module did not answer within the API's 150 s time limit (body { "error": "module_timeout", "retryAfterSec": 10 }) comes back as that status with the module's body, and the unit is given back. A module's own 200 — pending, unavailable, available: false, an empty list — is unchanged: it is a result and stays charged. If your integration parsed error out of a 200 body, check the status code instead. See Error Handling.

2026-10-14 · Breaking · a holder list that could not be read is a 502, not an empty one

When the holder read did not finish, /v1/holders and /v1/kol used to answer 200 with an empty result — 0 holders, 0 KOLs — and charge the unit. On every chain they now answer 502 { "error": "holders_unavailable", "reason" }, not charged; on an EVM chain with no holder indexer configured the status is 503 with reason: "no_holder_source". On Solana, /v1/whales, /v1/smart-money, /v1/copy-traders and /v1/insider-network need the holder list too: they answer the same 502 when it could not be read, where whales, smart-money and copy-traders used to answer an empty result and charge it (insider-network refused the empty list itself, with its own Invalid holders data). A Solana address that is valid base58 but not a token mint answers 400 { "error": "Not a token mint" } on those endpoints, and one that does not exist on-chain 400 { "error": "Address not found on-chain" } — not charged, and never the 502. If your integration read totalHolders: 0 or an empty list as the answer, handle the 502 and retry.

2026-10-14 · Changed · /v1/bundles-pro takes ?wait= on both chains and reports complete

?wait=launch returns the progressive launch snapshot on Solana as well as EVM (it was EVM-only). On EVM, ?wait=full or ?wait=<seconds> waits up to 25 s for the late linked-holders / post-window stage before answering, and every EVM answer carries a top-level complete boolean — false while summary.pending has stages, summary.linkedHolders.pending is true or summary.postWindowScan is pending. The summary also names what the scan's budget left undone: fundersUnvetted, fundingProbesSkipped, fundingLookupsFailed, routersResolved / routersPending, and bundledBasis (peak when bundledPct is the most the groups held at once). Nothing was removed.

2026-10-14 · Added · completeness and budget fields on the per-module endpoints

Each module now says what its time budget cut, so a short answer can be told from an empty one. /v1/smart-money on EVM: wallets[].nativeLegsCut (the legs budget cut that wallet's read; its profile is not cached, so the next call reads it again) beside nativeLegsMissing, and summary.legsCut counting the cut wallets. /v1/funding-origin on EVM: stats.deepWalk { total, walked, refined, unread, pending, done } for hops 2–3 of the funders' own funders. /v1/holders on EVM: holdersCount (not totalHolders), holdersCountIsFloor, warnings, and derived with its harvestWindows / harvestComplete. /v1/snipers on EVM: partial, scanDegraded. /v1/dev-tracker: platformLaunches.pending, devHistory.truncated. Where an EVM payload differs from the Solana shape, the endpoint entry now carries an On EVM chains note instead of claiming the shapes are identical. Existing fields are unchanged.

2026-10-14 · Changed · /v1/trending?category= on every chain; /v1/token-price?type= rejects unknown values on EVM too

?category= is honoured on every chain: Solana serves trending, new, gainers, losers, traded and viewed; the EVM chains trending, new and gainers. An empty ?category= is treated as absent (the trending feed); on an EVM chain the value is case-insensitive, on Solana it must match exactly. Anything else is a 400 before the meter, so it is not charged (until now the Solana handler dropped the parameter and every call got the trending feed). An unknown /v1/token-price?type= is likewise a 400 on every chain, EVM included, before the meter.

2026-10-14 · Docs · limits table and endpoint count

The Limits by Plan table listed three plans and no monthly allowance; it now lists the five plans on sale with their per-minute, per-day and unit figures, read live from the same table the meter enforces. The endpoint count on this page is derived from the reference below rather than typed (it read 22 against 25 entries). No API behaviour changed here.

2026-10-01 · Changed · /v1/rug-score answers within a time budget

The call used to run the full analysis first, then its Pro modules, and wait for the slowest of them — a median of 11–13 s and a 95th percentile at the 25 s ceiling. It now starts the launch modules alongside the analysis and answers after a budget, 5 s by default: the free checks and every module that has landed are scored, and the rest is named in a new pending array while it keeps computing server-side. complete is true when nothing is pending, and coverage reads partial until then. Pass ?wait=full to wait for every module as before (up to 25 s), or ?wait=<seconds> to choose your own budget. If your integration needs the complete score in one call, add ?wait=full. The MCP tool always waits for the complete answer.

2026-09-30 · Added · /v1/wallet-reputation/:wallet and /v1/wallet-overlap

/v1/wallet-reputation/:wallet is the Wallet Lookup page on the API: one wallet's record across every token DeFade scanned — tokens flagged in, confirmed rugs, the role on each, a tier verdict — with a labelGlossary that says what each role means. It is about a wallet rather than a token, so its envelope carries wallet and chain in place of token. /v1/wallet-overlap?mints=A,B(,C) returns the wallets holding two or more of the given tokens. Nothing about existing endpoints changed.

2026-09-07 · Breaking · /v1/trending?chain= returns a named array on EVM chains too

The 2026-08-28 fix below landed on the Solana path only. On ethereum, base and robinhood the feed was still spread into the envelope, so the same endpoint answered two different shapes depending on ?chain= — a named trending array on Solana, numeric keys everywhere else. The EVM response now carries the same trending array. If your integration reads numeric keys off an EVM trending call, change it to res.trending; the Solana path is unaffected, and an error still puts error at the top level rather than inside trending.

2026-09-07 · Added · trial keys reach every chain

The free 7-day trial key was Solana-only. It now covers every chain the API covers — Solana, Ethereum, Base and Robinhood at the time; BSC, Arc and Hyperliquid followed as they launched — on the same six endpoints, at the same 10 req/min, 100 req/day and 3,000 units/month. An EVM call from a trial key costs one unit, the same as a Solana one (since 2026-10-14 an EVM rug-score costs 5; see above). Paid plans were already all-chains and are unchanged.

2026-08-28 · Added · MCP connector at /mcp

The /v1 surface is now also reachable over the Model Context Protocol, so Claude, ChatGPT and other MCP clients can run scans in-conversation. Fifteen read-only tools, metered against your existing key exactly like REST calls. Nothing about the REST API changed. See MCP Connector.

2026-08-28 · Breaking · /v1/trending returns a named array

The feed is answered as a JSON array, and the endpoint used to spread it into the response envelope. That scattered the tokens across numeric keys — "0", "1", "2" … — next to timestamp and poweredBy, so reading the list meant subtracting the envelope and collecting whatever was left. The tokens now arrive in a trending array.

// before
{ "timestamp": "…", "0": { "symbol": "EX" }, "1": { "symbol": "FOO" }, "poweredBy": "DeFade.org" }

// after
{ "timestamp": "…", "trending": [ { "symbol": "EX" }, { "symbol": "FOO" } ], "poweredBy": "DeFade.org" }

If you read numeric keys, you must change your code. Anywhere you filtered the envelope out and took the rest — Object.entries(res).filter(([k]) => !isNaN(k)) or similar — becomes res.trending. An error response is unaffected: a failure still puts error at the top level rather than inside trending.

2026-08-28 · Added · /v1/dev-tracker says where the dev wallet came from

Two new fields. creatorSource names the signal that identified the wallet, and creatorInferred is true when that signal does not identify a person — a launchpad stamps one authority across every token it mints, so an authority-derived address is a guess, not a dev. Treat an inferred wallet's position as unconfirmed. Existing fields are unchanged.

2026-08-28 · Fixed · /v1/dev-tracker lastActivity is populated

It had always been null. It is now the unix timestamp of the dev's most recent move of the token, across every bucket the endpoint tracks, and null only when the wallet has never moved it.

2026-08-28 · Docs · response schemas rewritten against the endpoints

No API behaviour changed here, but the reference on this page did. Every response sample used to open with a "mint" key that no endpoint returns — responses carry token, timestamp and poweredBy — and several field lists named fields that do not exist (/v1/analyze listed rugScore and riskLevel; /v1/holders listed top10Pct; /v1/whales, /v1/bundles and /v1/snipers listed counts that live inside summary). Every entry has been rewritten against the response its endpoint actually sends. If you built against the old schemas and something never worked, this is why.

Older changes

This log starts on 2026-08-28. Earlier changes were not recorded. For anything before that, the endpoint reference above describes current behaviour.