Connection check
verified live · 26h ago
defade
Rug pull risk and on-chain forensics for tokens on Solana, Ethereum, Base and Robinhood.
Tools
15
GitHub stars
—
Installs / wk
—
Licence
—
Transport
streamable-http
Last checked
26h ago
Tools & capabilities
15 toolsRead from the running server on 26h ago.
get_dev_tracker
read-only
chainaddress*
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: st… 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, fully exited on a fresh token is a warning, and transferred out to fresh wallets is the single strongest rug signal DeFade tracks. Not for wallets other than the creator (get_whales, get_wallet_links) or for the creator's earlier tokens. Arguments: address and chain; one API unit on any chain.
get_fee_fingerprint
read-only
chainaddress*
Wallets whose transactions pin an identical compute-unit price or Jito tip — one operator's bot settings showing up across every wallet it drives. This is a shared-CONFIGURATION li… Wallets whose transactions pin an identical compute-unit price or Jito tip — one operator's bot settings showing up across every wallet it drives. This is a shared-CONFIGURATION link, not a timing one: it never proves bundling, and two wallets can match days apart. Use it to corroborate get_lookalike_clusters, and to catch the operator who sold their launch wallets and re-entered through fresh ones. Solana only. Do not call it for EVM addresses — pass chain solana or omit chain — and do not read a match as proof of coordinated buying; it is corroboration only. Arguments: address only in practice — chain must be solana or omitted, and an EVM chain is rejected with an error before any request is spent. One API unit.
get_funding_sources
read-only
chainaddress*
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. U… 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 graph (that is get_wallet_links) or group look-alike behaviour (get_lookalike_clusters). Not for the creator's own activity (get_dev_tracker) or launch-window buying (get_launch_bundles, get_launch_snipers). Arguments: address and chain; on an EVM chain this call costs 5 API units instead of 1, because the trace runs against paid indexers.
get_holders
read-only
chainaddress*
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. Ret… 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 holders are doing right now (get_whales), whether holders are secretly one actor (get_wallet_links or get_lookalike_clusters), or pool depth and locks (get_liquidity). Arguments: address and chain; one API unit on any chain.
get_launch_bundles
read-only
chainaddress*
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 flip… 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_snipers), clusters that formed after launch (get_lookalike_clusters), or the creator's own selling (get_dev_tracker). Arguments: address and chain; one API unit on any chain.
get_launch_snipers
read-only
chainaddress*
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 tra… 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 the true first transaction, the result is partial, and it is cached for only 10 minutes instead of 2 hours. Use it to tell an organic launch from a pre-arranged one. Not for coordinated multi-wallet launch buying (get_launch_bundles) or the deployer's funding of other wallets (get_wallet_links). Arguments: address and chain; one API unit on any chain.
get_liquidity
read-only
chainaddress*
Liquidity pool analysis for one token, including burn and lock verification and pool depth. Use it to answer whether liquidity is locked, how deep it is, and whether the position c… Liquidity pool analysis for one token, including burn and lock verification and pool depth. Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled. Not for price, market cap or volume (get_token_price) or holder concentration (get_holders). A token with no pool returns empty liquidity data, which is itself a warning on a token that is trading. Arguments: address and chain; one API unit on any chain.
get_lookalike_clusters
read-only
chainaddress*
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… 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 get_fee_fingerprint on Solana. Not for proven transfer or funding links (get_wallet_links) or launch-window coordination (get_launch_bundles). Arguments: address and chain; on an EVM chain this call costs 5 API units instead of 1, because the trace runs against paid indexers.
get_rug_score
read-only
chainaddress*
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… 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 the evidence behind the number — it names the signals but does not list the wallets; for who is behind the risk call get_wallet_links, get_dev_tracker or get_launch_bundles. Arguments: address and chain; one API unit on any chain.
get_smart_money
read-only
chainaddress*
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… 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 — informed wallets present never offsets a rug signal, and a clean result is not a buy signal — and not for wallet size (get_whales). Arguments: address and chain; one API unit on any chain.
get_token_price
read-only
chainaddress*
Current market data for one token — price, market cap, liquidity, volume and recent OHLCV candles — aggregated from DEX market sources and cached for about a minute, so figures are… Current market data for one token — price, market cap, liquidity, volume and recent OHLCV candles — aggregated from DEX market sources and cached for about a minute, so figures are near-live but not a tick-by-tick trading feed. A token with no liquidity pool returns empty market data rather than an error. Use it for the market context around a risk verdict. Not for risk of any kind — market data carries no forensic signal — and not for long price history beyond the recent candles. Arguments: address and chain; one API unit on any chain.
get_token_scan
read-only
chainaddress*
Run a full DeFade scan on one token contract: token metadata, holder distribution, creator info and the headline risk verdict. Start here for any "is this token safe", "is this a r… Run a full DeFade scan on one token contract: token metadata, holder distribution, creator info 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 probability where high means dangerous — call get_rug_score. Not for a single module in isolation (call that module's tool directly), price or market-cap questions (get_token_price), or checking the caller's own quota (get_usage). Arguments: address and chain; one API unit on any chain.
get_usage
read-only
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 thei… 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.
get_wallet_links
read-only
chainaddress*
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… 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 tool of the forensic family: for wallets that merely behave alike with no provable link, call get_lookalike_clusters; for where the money entered the chain, get_funding_sources. Not for the creator wallet's own sales and transfers (get_dev_tracker) or for market data of any kind. Arguments: address and chain; one API unit on any chain.
get_whales
read-only
chainaddress*