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 or Hyperliquid, 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 and Hyperliquid.

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 — at 10 req/min, 100 req/day and 3,000 units/month. A trial call costs 1 unit, except rug-score on an EVM chain, which draws 5 of the trial's 3,000: the EVM score reads every module.

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. 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.025. Past the monthly allowance a request takes as many credits as it costs units: 1 credit for most calls, 5 credits ($0.125) for the heavy EVM calls listed in units.heavyOnEvm. Past the daily limit alone, every request takes 1 credit.

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 200-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.025",
    "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 1 credit ($0.025). 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.

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.

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.

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-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.