DeFade — Multi-Chain Memecoin Analyzer

Run a full DeFade scan on one token contract: token metadata, holder distribution, creator history (wallet age, previous token launches) and the headline risk verdict. Start here for any "is this token safe", "is this a rug pull" or "should I buy this" question. Returns risk.score as a SAFETY score where 100 is clean and low numbers are dangerous, with a rating label. For the inverse — a rug pull

Rug pull probability for one token: a 0-100 score where HIGHER MEANS MORE DANGEROUS, a verdict label, and the individual signals that drove it. This is the opposite direction from get_token_scan's safety score. Call this tool ONLY when the user explicitly asks for a rug probability or rug likelihood; every general "is this safe" or "should I buy" question goes to get_token_scan instead. Not for th

Holder distribution for one token, with liquidity pools, burn addresses, lockers, exchange wallets and contracts classified out, so the top-holder list reflects actual holders. Returns the classified top holders with each wallet's supply share in a single response — no pagination. Use it to answer how concentrated the supply is and whether a few wallets could collapse the chart. Not for what large

Wallets holding at least 1% of supply once pools, lockers, treasuries and custodial accounts are removed. Each row carries the balance, share of supply, any attribution label (known KOL, dev-linked stash, exchange), the 24-hour transaction count and recent buys and sells; the summary counts dangerous and active whales and gives a whale-risk verdict. One response, no pagination; cached for 15 minut

Liquidity pool analysis for one token: which DEX holds the deepest pool, its depth in USD, and whether the LP tokens are burned, locked or still in someone's hands. lpStatus is the verdict — LP BURNED, LP LOCKED, LP UNLOCKED, PARTIALLY BURNED, LP NOT LOCKABLE, BONDING CURVE (still on a launchpad curve, no pool yet) or NO LP FOUND, with combinations spelled out — and lpBurnPct, lpLockPct and poolLo

Bundle detection for one token: coordinated buys in the launch window plus delayed sweeps, accounted on peak net exposure rather than raw buy count, so wallets that bought and flipped are not counted as holders. Heavy bundling that is still held is one of the strongest rug predictors. Use it for any "was this launch bundled" question. Not for lone fast buyers with no coordination (get_launch_snipe

Bots that bought in the first block or first seconds of this token's launch, and whether they are connected to the deployer. The window is the first 120 seconds after the first transaction; at most 30 rows are returned and totalEarlyBuyers carries the full count. Migration-crank MEV bots are excluded and named rather than silently dropped. Check reachedGenesis: when false the walk did not reach th

The graph of proven on-chain links between wallets around one token — who funded whom, who transferred to whom, and coordinated timing — typically the deployer's supply fanned out to look like organic demand. Use it when the holder list looks distributed and you want to know whether it really is. This is the hard-evidence member of the four "who is really behind this token" tools — a link counts o

Wallets with a track record of profitable entries that are holding or trading this token, classified from their historical trade win rates — a "verified" smart-money tag requires a known win rate of 50% or better. Computed live from the current holder set and cached for about five minutes. Use it for the bullish side of a scan: who informed is in, and when they got in. Not for risk assessment — in

What the token's creator has done with their supply: the share they still hold, what left through sales versus transfers, and where the transfers went. Read the state carefully: still holding is neutral, a dev who simply sold out is statusColor gray — the standard launch pattern, not a rug — fully exited on a fresh token is a warning, and transferred out to fresh wallets (red) is the single strong

Multi-hop tracing of where the money behind this token's key wallets actually came from, walking each funding chain back and tiering the source by whether it is a KYC'd exchange. Use it to test whether several "unrelated" holders share one funding source. It answers provenance only — money in, one dimension: it does not build the wallet-to-wallet transfer graph (get_wallet_links), group look-alike

Clusters of wallets around one token that behave as a single actor — buys sized and timed alike so demand looks organic — even when no transfer or funding trail connects them. That behavioural inference is what separates it from get_wallet_links, which only reports proven links. Use it when supply looks distributed across many small wallets and the insider graph comes back clean; corroborate with

Wallets whose transactions pin an identical fee setting — compute-unit price or Jito tip on Solana, priority fee or legacy gas price on EVM chains — one operator's bot settings showing up across every wallet it drives. This is the shared-CONFIGURATION member of the "who is really behind this token" family (proven transfers: get_wallet_links; funding origin: get_funding_sources; behavioural twins:

Price history for one token as OHLCV candles, plus the latest price, the window's high and low with their timestamps, and the percent change across the window — prices in USD (the *Usd fields), volume as the market source quotes it. Aggregated from DEX market sources and cached for about a minute. Intervals with no trades are omitted rather than zero-filled, so consecutive candles can sit more tha

Report the calling API key's plan, rate limits and how much of its monthly allowance is left. Takes no arguments. Use it when a call fails on quota, or when the user asks what their DeFade plan includes. Not for anything about a token — every other tool takes an address; this one reports on the key itself.