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 the same analysis on Ethereum, Base, BSC, Robinhood, Arc or Hyperliquid, on every plan — 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.

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

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 25 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 and rug-score on an EVM chain, which cost 5. See Authentication for details.

API Endpoints

25 endpoints covering every angle of on-chain risk. Click any endpoint to expand full details, parameters, and response schema. Every paid plan unlocks all 25 endpoints on every chain — plans differ on included units and rate limit. The second badge shows chain support: 23 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.

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 same analysis 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 (holders counts in holdersCount and lists in holders, kol carries its totals at the top level rather than under a summary, the funding modules stamp fetchedAt in place of computedAt / fromCache, funding-origin and smart-money add budget fields, snipers has no reachedGenesis, rug-score adds a per-module modules map with skipped and failed). A good pattern on any chain: call /v1/rug-score first — it warms every module for that token, so the 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

23 of the 25 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. With overage credits enabled, those requests are fulfilled using credits instead of being blocked. 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. Enable overage on your API key (opt-in via dashboard toggle). 3. When you pass your monthly allowance or daily limit, requests automatically consume credits. 4. When credits run out, the standard 429 response resumes.

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": "Enable overage credits in your dashboard..."
  }
}

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 you have overage credits enabled — 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 and rug-score 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. 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: get_token_scan returns risk.score, a safety score where 100 is clean, 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-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.