Nansen

Read the authenticated account's saved automatic feedback preference. Free; no report quota. Before a new automatic report about useful Nansen friction, draft a concise report without secrets or unnecessary conversation details and call this tool. Enabled permits sending subject to host and local-deny controls and account rollout. If off, unconfigured or unavailable, show the report and ask first. Refusal, host denial or inability to ask means no submission. An explicit request or approval permits only that report. Never enable the preference automatically. Direct lasting changes to Superapp settings. Reads are fresh, use this account only, and do not authorize another account or server key.

Submit product feedback for the authenticated Nansen account. Costs zero credits, including with zero balance. Send when the user requests or approves this report. Before a new automatic report, call get_feedback_preferences for a fresh account preference. If it is off, unconfigured or unavailable, show the report and ask before sending. If the user refuses or you cannot ask, do not send. Enabled permits sending subject to host controls. One report approval does not change the preference. Never enable it yourself. Host denial means no submission. A feedback_not_enabled refusal means stop automatic retries and tell the user the feature is not enabled for this account. Approval and saved preferences do not override rollout. Seven accepted reports per account per week across all clients, resetting Monday 00:00 UTC. Generate submission_id once per new report; reuse it and the exact report for retries and re-invocations. Never replace an ID after a timeout. Limits: description/goal/expected/observed/workaround 2,000 Unicode characters each; endpoint/tool 256; 10 distinct request IDs of 128 characters; client name/version 64; total JSON body 16 KiB UTF-8. Missing capabilities need no endpoint, tool, or request ID. Omit secrets. Received means saved, not fixed. Failures preserve recovery guidance. No alternate-account or server-key fallback. Do not redirect failed submissions to unrelated feedback channels.

Read a Nansen feedback receipt for the same authenticated account. Costs zero credits. Lookup uses feedback_id, consumes no report slot, and returns fresh status. Received means saved; reviewed means triaged; closed has a public disposition. No fix or delivery date is promised. Unknown, expired, and other-account IDs return the same not-found response. Never create a replacement report or use another account or an internal server key when lookup fails. Do not redirect failed lookups to unrelated feedback channels.

Get aggregated (not per wallet) smart trader and fund (EXCLUDES whales, large holders, influencers, etc.) token balances and 24h change per chain for all chains (default is ['all'], which queries all supported chains) or specific chain(s). Use filters to narrow down the results.

Get recent Hyperliquid perpetual futures trades from Smart Money addresses across all tokens. Optional labels narrow this cohort; they do not search all addresses with that label. For a broad view of Smart Money activity across all tokens, use token_discovery_screener with traderType="sm". **Note:** This endpoint is Hyperliquid-only (perpetual futures data). It returns recent trades only (no date filtering available). Columns returned: - **Time**: Timestamp when the trade occurred (datetime: YYYY-MM-DD HH:MM:SS) - **Side**: Position direction - Long or Short - **Action**: Order action - Add, Reduce, Open, Close - **Token**: Symbol of the perpetual contract - **Size**: Quantity of the perpetual contract (numeric) - **Price USD**: Price per token at time of trade (price formatted) - **Value USD**: Total USD value of the trade (currency formatted) - **Trader**: Nansen label of the trading address - **Address**: Full trading wallet address - **Tx Hash**: Blockchain transaction hash for verification Sorting Options (all fields support "asc"/"desc"): Available for sorting: timestamp, amount, price_usd Examples: # Get recent smart money perp trades (sorted by amount) ``` { "orderBy": "amount", "order_by_direction": "desc" } ``` # Filter by action and side ``` { "action": "Open", "side": "Long" } ```

Get aggregated (not per wallet) smart trader and fund (EXCLUDES whales, large holders, influencers, etc.) net USD flow per token over 1h/24h/7d/30d, per chain for all chains (default is ['all']) or specific chain(s). Use this for what smart money is buying or selling right now; use smart_traders_and_funds_token_balances for what they hold.

Get individual (per wallet, per transaction) DEX trades made by smart traders and funds (EXCLUDES whales, large holders, influencers, etc.) across all chains (default is ['all']) or specific chain(s). Use this to see exactly which wallet bought or sold what; use smart_traders_and_funds_netflow for the aggregated view.

Get Jupiter DCA (dollar-cost-averaging) orders opened by smart traders and funds on Solana, including deposit size, amount spent so far and order status. Use this for scheduled accumulation intent; use smart_traders_and_funds_dex_trades for one-off swaps.

Get the day-by-day history of aggregated smart trader and fund token balances (EXCLUDES whales, large holders, influencers, etc.) for a date range on base, bnb, ethereum, monad, robinhood or solana. Use this to see how smart money holdings changed over time; use smart_traders_and_funds_token_balances for the current snapshot. This endpoint uses inclusive UTC calendar dates, not rolling timestamps.

Rank smart trader and fund addresses (EXCLUDES whales, large holders, influencers, etc.) by realized, unrealized and total USD PnL over a 1/7/30/90/180 day window, with ROI, win rate and trade counts. Use this to find the best performing smart money wallets; use token_pnl_leaderboard for the best performers on one specific token.

Get upto 25 (per page) top holders information for a specific token. **Note:** Using `labelType: smart_money` is not a good proxy for an overall market view. Use it only if user explicitly requests it, or to combine it with other non smart money data. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") Columns returned (onchain_tokens mode): - **Address**: Wallet/contract address of the token holder - **Label**: Nansen label (e.g., exchange, whale, etc.) - **Balance**: Current balance held (numeric with K/M/B formatting) - **Balance USD**: USD value of token holdings (currency formatted) - **Ownership %**: Percentage of total token supply owned (percentage, 2 decimal places) - **Sent**: Total tokens sent from this address historically (numeric) - **Received**: Total tokens received by this address historically (numeric) - **24h Change**: Balance change in last 24 hours (numeric, can be negative) - **7d Change**: Balance change in last 7 days (numeric, can be negative) - **30d Change**: Balance change in last 30 days (numeric, can be negative) Columns returned (perps mode): - **Trader Address**: Address of the trader - **Trader Label**: Nansen label for the trader - **Side**: Position direction (Long/Short) - **Position Value USD**: Total USD value of the position (currency formatted) - **Position Size**: Size of the position in tokens (numeric) - **Leverage**: Leverage multiplier (e.g., "20X") - **Leverage Type**: Type of leverage (cross/isolated) - **Entry Price**: Average entry price (price formatted) - **Mark Price**: Current mark price (price formatted) - **Liquidation Price**: Liquidation price (price formatted) - **Funding USD**: Cumulative funding payments (currency formatted) - **Unrealized PnL USD**: Unrealized profit/loss (currency formatted) Sorting Options (default: holding_size desc): onchain_tokens mode: holding_size, t

Get DEX trades for a specific token. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") **NOTE:** In onchain_tokens mode, only ETH is supported among native tokens. For other native tokens (SOL, BTC, BNB, etc.), use perps mode instead.

Get 25 token transfers (per page) for a specific token based on the sort order. Default: the last 24 hours, largest transfers first (orderBy "amount", "desc"). Direction rules (fromAddress = the sender, toAddress = the receiver): - "Transfers of X", "X's transfers", "track X", and "what is X doing" do not name a direction. For these, make two calls with the same address: one with fromAddress, one with toAddress. Sort both by amount. Each call then shows different transactions: the largest sent and the largest received. - Use only fromAddress when the user asks what X sent (outflows, withdrawals, "sent to", "moved to an exchange"). - Use only toAddress when the user asks what X received (inflows, deposits, "where did X get"). - Do not put the same address in fromAddress and toAddress of one call. The filters combine with AND, so the call returns only transfers from the wallet to itself (usually none). - If the user names no wallet, do not add an address filter. **NOTE:** This tool does not support native tokens (so11111111111111111111111111111111111111112, 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee). Columns returned: - **Time**: Timestamp when the transfer occurred (block_timestamp: ISO 8601 format) - **From Label**: Source address label (from_address_label: sender of tokens) - **To Label**: Destination address label (to_address_label: receiver of tokens) - **From Address**: Raw source address (from_address: hex address) - **To Address**: Raw destination address (to_address: hex address) - **Amount**: Quantity of tokens transferred (transfer_amount: numeric) - **Value USD**: USD value of the transfer at time of transaction (transfer_value_usd: currency formatted) - **Type**: Transfer category (transaction_type: DEX, CEX, transfer, etc.) - **Tx Hash**: Blockchain transaction hash for verification (transaction_hash) Sorting Options (all fields support "asc"/"desc"): Available for sorting: timestamp, amount - amount (default): largest transfer

Get hourly token-flow history for ONE holder segment over a date range. Use `token_recent_flows_summary` instead for an on-chain snapshot across ALL wallet categories. **Note:** Using `holder_segment: smart_money` is not a good proxy for an overall market view. Use it only if user explicitly requests it, or to combine it with other non smart money data. This is a **more granular** tool than `token_recent_flows_summary` and provides the TOTAL flows over the entire time frame broken down by segment. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") — supports native tokens **NOTE:** Native tokens (0xeee…, So111…) cannot be queried in `onchain_tokens` mode. If a native placeholder address is supplied, this tool returns Hyperliquid perpetual-futures flows for that chain's native coin instead (e.g. hyperevm → HYPE, bnb → BNB, base → ETH) and prepends a prominent data-source warning. For native-token wallet-category flows on-chain, use `token_recent_flows_summary`.

Upto 25 results (per page) of trader PnL for a token. Use the sorting and filtering options to narrow down the results. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") — supports native tokens **NOTE:** This tool does not support native tokens (so11111111111111111111111111111111111111112, 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee) in `onchain_tokens` mode. Native tokens (by symbol - SOL, ETH, ARB etc) ARE fully supported in `perps` mode. Returns: Trader performance rankings as markdown. Returns empty string if no trading data found. Columns returned: - **Address**: Trader's wallet address - **Label**: Nansen label of the trader - **Total PnL**: Combined realized and unrealized PnL (currency formatted, can be negative) - **Total ROI**: Total return on investment as percentage (percentage formatted) - **Realized PnL**: Profit/loss from completed trades (currency formatted, can be negative) - **Realized ROI**: Return on investment from realized trades only (percentage formatted) - **Unrealized PnL**: Current profit/loss on open positions (currency formatted, can be negative) - **Unrealized ROI**: Return on investment from unrealized positions only (percentage formatted) - **Token Holdings**: Current token quantity held (numeric formatted) - **Holdings USD**: Current USD value of token holdings (currency formatted) - **Token Price**: Current price per token (price formatted) - **Peak Token Holdings**: Maximum token quantity ever held in the date range (numeric formatted) - **Peak Holdings USD**: Maximum USD value ever held in the date range (currency formatted) - **Still Holding %**: Percentage of peak holdings still held (percentage formatted) - **Total Trades**: Number of trades executed by this address - **Net Flow**: Net money flow - negative means net seller (cu

Get TOTAL amount of tokens bought/sold by address for a token on DEX (Decentralised Exchanges) ONLY. Use this tool to find out WHO is buying or selling a token (on DEX) AND then you can check if they are liquidating profits or accumulating more. Returns: Aggregated buyer/seller activity as markdown. Returns empty string if no trading data found. Columns returned: - **Address**: Trader's wallet address - **Label**: Nansen label of the address - **Bought Token Volume**: Total quantity of tokens purchased - **Sold Token Volume**: Total quantity of tokens sold - **Gross Token Volume**: Combined buy and sell volume in tokens - **Bought Volume USD**: USD value of all token purchases - **Sold Volume USD**: USD value of all token sales - **Gross Volume USD**: Combined USD trading volume Sorting Options: You can sort asc or desc by bought_volume_usd or sold_volume_usd Notes: - buy_or_sell parameter filters for "BUY" (net buyers) or "SELL" (net sellers) - Aggregates all trading activity within the specified time range

Get an on-chain flow snapshot across **ALL** wallet categories in one call. This tool supports native ETH on Ethereum and native SOL on Solana, and is the correct choice for standard lookbacks such as 1d. Returns **TOTAL** token flows per segment: 1. Public Figures 2. Top PnL Traders 3. Whales 4. Smart Traders 5. Exchanges 6. Fresh Wallets Inflow and outflow of tokens between the segments is CRITICAL in identifying token price trends. The values provided are **aggregated over the specific lookback period (last 5min, 1d, 7d etc) specified**. If you have SPECIFIC date ranges in mind, use `token_flows` instead. **NOTE** Use `token_flows` for more granular data as it can filter between exact dates and provides HOURLY breakdowns. Returns: Categorized token flow analysis as markdown. For each segment, returns: - Flow amount in USD - Ratio compared to average flow - Number of wallets Format: "{Segment} wallet flow of {amount} ({ratio}x average, from {count} wallets)" Notes: - Positive flow = net buying, negative flow = net selling - For Exchange Flow, positive means more inflow to exchanges, negative means more outflow from exchanges - Categorizes market participants by their historical behavior and characteristics NOTE: Bitcoin is not supported. DO NOT use this tool for bitcoin. **Modes:** - `onchain_tokens` (default): On-chain token flow intelligence across cohorts - `perps`: Hyperliquid perpetual futures — returns position intelligence (current aggregate long/short/total USD by cohort: Smart Money, Whales, Public Figures). Native tokens (SOL, ETH, BTC etc) are fully supported in perps mode.

Get comprehensive token screening data across multiple blockchain networks with advanced filtering. A maximum of 25 results per page are returned out of 1000s of tokens. Use the sorting and filtering options to narrow down the results. In a mixed spot + hyperliquid request, `page` applies to both the spot and perps sections. A maximum of 5 chains can be specified per request (excess chains are automatically trimmed). This tool helps with token discovery and finding trending tokens by combining different metrics: volume, liquidity, market cap, smart money activity, and token age. **IMPORTANT - Hyperliquid Special Case:** - Hyperliquid chain queries perpetual futures (perps), not spot tokens - When hyperliquid is mixed with other chains, two sections of up to 25 results each are returned - one for spot tokens and one for perps. - For perps, only these filters are supported: volume, buyVolume, sellVolume, openInterest, netflow, nofTraders, traderType - Perps support orderBy='price_change' for every traderType. Prices use completed 5-minute buckets at the timeframe boundaries. - Additional orderBy fields for perps: open_interest, funding (e.g. orderBy 'funding' ascending finds perps that pay longs) - Unsupported filters/orderBy will fallback to defaults INPUT EXAMPLES: # Find tokens which are going up in price. # Added some liquidity filter to remove spam and low quality tokens. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "nofTraders": {"from": 10}, "orderBy": "price_change", "orderByDirection": "desc" } ``` # Find top stablecoins by market cap ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["Stablecoin"], "orderBy": "market_cap_usd", "orderByDirection": "desc" } ``` # Find AI memecoins with high trading activity { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["AI Meme"], "li

Get OHLCV (Open, High, Low, Close, Volume) price data for a token with automatic interval resolution. Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass `chain="hyperliquid"` and use the perp symbol as `tokenAddress` (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically). **YOU MUST USE THIS** over `general_search` to get prices. **`general_search` prices are delayed and often incorrect.** To get **LATEST** price set from to '5MIN_AGO' and to to 'NOW'. Resolution is automatically calculated based on the date range - < 6 hours: 5 minutes - 6 hours - 1 day: 15 minutes - 1-3 days: 30 minutes - 3-7 days: 60 minutes (1 hour) - 7-90 days: Daily - 90+ days: Weekly Columns returned: - **Interval Start**: Timestamp of the start of the interval (datetime: YYYY-MM-DD HH:MM:SS) - **Open**: Opening price of the interval - **High**: Highest price of the interval - **Low**: Lowest price of the interval - **Close**: Closing price of the interval - **Volume USD**: Volume in USD of the interval Additional columns (when includeMarketCap=true): - **Open Market Cap**: Opening market cap in USD - **Close Market Cap**: Closing market cap in USD - **High Market Cap**: Highest market cap in USD - **Low Market Cap**: Lowest market cap in USD Example Usage: Get OHLCV for WETH over the past week (auto-resolution): ``` { "chain": "ethereum", "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196", "date": { "from": "7D_AGO", "to": "NOW" } } ``` Get OHLCV for WETH over 30 days (will use daily resolution): ``` { "chain": "ethereum", "tokenAddress": "0xba5ddd1f9d7f570dc94a51479a000e3bce967196", "date": { "from": "30D_AGO", "to": "NOW" } } ``` Get OHLCV for WETH for last 20 minutes (will use 5 minute resolution):

Get a technical-analysis snapshot for a token: SMA(20/50/200), EMA(12/26), RSI(14), MACD(12,26,9), Bollinger Bands(20, 2σ), ATR(14), and rolling VWAP(20), computed from the last 260 closed candles at an explicit timeframe. Supports EVM chains and Solana for on-chain tokens, AND Hyperliquid perpetual futures. For Hyperliquid perps, pass `chain="hyperliquid"` and use the perp symbol as `tokenAddress` (e.g. "BTC", "HYPE" for native perps; "XYZ:ORDI" for XYZ-namespaced perps — prefix is normalized automatically). **YOU MUST USE THIS** for technical analysis instead of computing indicators from raw `token_ohlcv` candles — it uses far more history (260 closed candles) and charting-platform conventions (SMA-seeded EMA, Wilder RSI/ATR, population-σ Bollinger). Timeframes (explicit, no auto-resolution): - 5m / 15m / 30m / 1h / 4h: intraday and short-horizon analysis - 1d (default): swing/position horizon - 1w: long-term trend Output: a snapshot header (candles used, date range, last close, 5-candle price change) plus one row per indicator, each with a 5-candle trend delta so you can read direction, not just level: - **SMA 20/50/200**: values, price vs each, MA slopes - **EMA 12/26**: values, spread %, widening/narrowing - **RSI(14)**: level, prior candle, 5-candle change - **MACD(12,26,9)**: line/signal/histogram, rising/falling, candles since signal cross - **Bollinger(20,2σ)**: bands, %B, bandwidth and its change - **ATR(14)**: value and % of price (volatility), rising/falling - **VWAP(20)**: value, price vs VWAP Indicators without enough closed-candle history render as n/a (e.g. SMA200 on young tokens); the candle count used is always reported. VWAP is n/a on Hyperliquid 5m-1h timeframes (volume is NULL in those views) — use 4h or 1d for Hyperliquid VWAP. Example Usage: Daily technical snapshot for WETH: ``` { "chain": "ethereum", "tokenAddress": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", "timeframe": "1d" } ``` 4-

Get token information — spot on-chain details or Hyperliquid perpetual futures stats. On-chain tokens mode (default): Returns token details (name, symbol, market cap, FDV, supply, deployment date, socials) and spot trading metrics (volume, buys/sells, buyers/sellers, holders, liquidity). Perps mode: Returns Hyperliquid perp stats — mark price, funding, open interest, buy/sell pressure, trader participation. Returns: Token information as markdown. On-chain tokens fields: - **Market Cap / FDV**: Market capitalization and fully diluted valuation - **Circulating / Total Supply**: Token supply metrics - **Deployed**: When the token was deployed - **Volume (Total / Buy / Sell)**: Trading volume in USD - **Buys / Sells**: Number of buy/sell transactions - **Unique Buyers / Sellers**: Distinct trading addresses - **Total Holders**: Number of token holders - **Liquidity**: Available liquidity in USD Perps fields: - **Mark Price**: Current perp mark price - **Price Change**: Change vs previous price - **Max Leverage**: Maximum leverage offered for the perp on Hyperliquid (e.g. "40x") - **Funding Rate (hourly/annualized)**: Current funding rate - **Open Interest**: Total current open interest in USD - **Volume (Total / Buy / Sell)**: Perp volume in USD - **Net Flow (Buy - Sell)**: Buy/sell pressure in USD - **Traders**: Number of traders Example: On-chain tokens (default mode): ``` { "mode": "onchain_tokens", "chain": "ethereum", "tokenAddress": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "timeframe": "1d" } ``` Hyperliquid perps: ``` { "mode": "perps", "tokenAddress": "BTC", "timeframe": "7d" } ``` Notes: - On-chain tokens mode uses contract addresses - Perps mode uses token symbols (e.g. BTC, ETH, HYPE) - Both modes use the same `timeframe` parameter

Get Nansen Score Indicators for a token - quantitative risk and reward signals. Use this tool when assessing a token's risk/reward profile, evaluating buy/sell decisions, or when the user needs quantitative data to make trading decisions. Returns: Token risk/reward indicators as markdown with interpretation guidance. Token info: - **Market Cap**: Current market cap in USD - **Market Cap Group**: largecap (>$1B), midcap ($100M-$1B), or lowcap (<$100M) - **Is Stablecoin**: Whether token is a stablecoin (some indicators don't apply to stablecoins) Fields returned per indicator: - **Score**: Signal classification (bullish/neutral/bearish for reward; low/medium/high for risk) - **Signal**: Raw numeric value of the indicator - **Percentile**: Rank vs same market cap group (0-100%) - **Last Trigger**: Date when signal was last calculated Indicator types: - **Reward Indicators**: price-momentum, funding-rate, chain-fees, chain-tvl, protocol-fees, trading-range - **Risk Indicators**: btc-reflexivity, liquidity-risk, token-supply-inflation, concentration-risk, cex-flows Notes: - Not all indicators available for every token/chain combination - Percentile compares against same market cap group (largecap >$1B, midcap $100M-$1B, lowcap <$100M)

Discover and filter a daily list of attractive tokens using Nansen Score Indicators weighted by coefficients (= Performance Score). Use this tool when you don't know which tokens to buy and need recommendations based on backtested indicators. For specific token analysis (e.g., "should I buy AAVE?"), use token_quant_scores instead. **When to use this tool vs token_discovery_screener**: - Use **this tool** when you want **pre-scored buying recommendations** without specifying criteria. It answers "what should I buy?" by returning tokens that already meet a quantitative buying threshold (Performance Score ≥15) based on alpha indicators like price momentum, chain fees, and protocol fees. Data is updated in batches. - Use **token_discovery_screener** when you want **live data** or to **explore tokens by specific criteria** like sectors (e.g., "AI memecoins"), token age (e.g., "new launches"), smart money activity, or custom volume/liquidity thresholds. It's a filtering tool with real-time metrics where you define what you're looking for. Returns tokens pre-filtered by: performance_score >= 15 (buying threshold). **Example queries**: "what tokens should I buy?", "which tokens look good?", "best tokens to buy today" **Scoring:** - **Performance Score** (range -60 to +75): Higher = better alpha opportunity. **Buy threshold: ≥15** - **Risk Score** (range -60 to +80): Higher = safer token. >0 indicates low to medium risk. Every time you give the Performance Score to the user, explain the scoring thresholds above. Same for the Risk Score. Every time quote the underlying indicators that contributed the most to the Performance/ Risk score and recall their definition to the user. Returns: A list of tokens with the highest Performance Score as markdown. Core fields: Token Address, Token Symbol, Chain, Performance Score, Risk Score. Indicator columns are included dynamically based on data availability (columns with all zeros are excluded).

Get Hyperliquid perpetual futures trader leaderboard with performance metrics. Returns: Trader performance rankings as markdown. Columns returned: - **Address** / **Label**: trader wallet, and its Nansen label if any - **Total PnL** (USD): realized + unrealized over the date range - **Realized PnL** (USD): net, from positions closed in the range. Being a net total it shows no per-trade outcome, so no win rate can be derived from it or any other column here - **Unrealized PnL** (USD): on positions still open, at the current mark price - **ROI** (%): Total PnL / (traded notional + open notional) — PnL per dollar traded, not return on capital - **Volume** (USD): traded notional; both fills of a position count - **Trades**: number of fills - **Account Value** (USD): only available for the top 500K traders This is an overview of top traders and their headline stats. For a trader's open positions, call `address_portfolio` with `mode='hyperliquid'`. **Sorting**: total_pnl, realized_pnl_usd, unrealized_pnl_usd, roi, volume_usd, total_trades, account_value **Filtering** (from/to): totalPnl (USD), accountValue (USD), roi (a fractional ratio, not the percent shown — pass 0.1 for "10% or better", not 10) Example: ``` { "date": {"from": "7D_AGO", "to": "NOW"}, "accountValue": {"from": 100000, "to": 1000000}, "totalPnl": {"from": 10000}, "order_by": "total_pnl", "orderByDirection": "DESC" } ``` Rank by traded volume instead: `"order_by": "volume_usd"` Notes: - Hyperliquid perpetual futures only - Dates use UTC calendar boundaries, not rolling timestamps. Calendar end dates retain the next-day API boundary. - Null/empty means data is not available — do not read it as zero

Get Jupiter DCA (dollar-cost-averaging) orders opened against a Solana token, with deposit size, amount spent so far, amount accumulated and order status. Use this to see scheduled buying or selling pressure that has not hit the market yet; use token_dex_trades for trades already executed. Solana tokens only.

Get historical native coin & token balances of address.

Get the standard labels for one wallet address. This tool returns identity, behavioural, and protocol labels. It does not return premium labels.

Get information about related addresses of an input address. Note: This only includes the the "special" connections 'First Funder', 'Signer', 'Previous Signer', 'Multisig Signer of', 'Previous Multisig Signer of', 'Deployed via', 'Deployed by', 'Deployed Contract', 'Created Contract', 'Created by'. To get related wallets, also check address counterparties. First funder exchange withdrawal address does usually NOT belong to the same entity as the address, only deposit addresses. Only information is that it has been funded by the exchange.

Get 25 (per page) addresses or entities with the most common interactions with input addresses Default sort is net value transferred between them. Also returns the top 3 tokens transferred by count for each counterparty Note: To get related wallets: - Focus on direct value transfers to get most likely addresses. - Include CEX deposit addresses (not withdrawal addresses!) as well. - Also go one level deeper: - Find addresses that interacted with the most likely addresses. - Find addresses that deposited to the same CEX deposit (NOT withdrawal!) addresses. - Address structure / string is not important, but the relationship is! Sorting Options (all fields support "ASC"/"DESC"): Available for sorting: total_volume_usd, volume_in_usd, volume_out_usd, interaction_count Examples: # Query by single address { "address": "0x123...", "sourceInput": "Combined", "groupBy": "wallet", "chain": "ethereum", "timeRange": {"from": "30D_AGO", "to": "NOW"}, "order_by": "total_volume_usd", "order_by_direction": "desc" } # Query by entity { "entity_id": "Binance", "sourceInput": "Combined", "groupBy": "entity", "chain": "all", "timeRange": {"from": "7D_AGO", "to": "NOW"} }

Get the top counterparties of up to 10 wallet addresses in one call. Every wallet gets its own counterparty list. The lists are NOT added together: the answer has one table for each wallet. Use this tool to compare wallets — counterparties that two wallets share, a group of wallets that sends to the same CEX deposit address, or one fund with many wallets. For one wallet, or for an entity name, use address_counterparties. Limits: - Maximum 10 distinct wallet addresses for each call. Repeated addresses are removed. - Maximum 90 days for the date range. A wider range is rejected — make more than one call. - One chain family for each call: every address must be EVM, or every address must be Solana, and so on. Do not mix families. Name a `chain` (for example ethereum) to read that chain only. Leave `chain` out to read every chain of the addresses' family at one time — then a counterparty met on more than one chain gets one row for each chain, so do not add those rows together. Sorting Options (all fields support "ASC"/"DESC"): Available for sorting: total_volume_usd, volume_in_usd, volume_out_usd, interaction_count. The sort is applied inside each wallet's block. Example (every key below is the name the request accepts, and the addresses are real — copy this shape as it stands): { "walletAddresses": [ "0x28c6c06298d514db089934071355e5743bf21d60", "0xd8da6bf26964af9d7eed9e03e53415d37aa96045" ], "chain": "ethereum", "timeRange": {"from": "30D_AGO", "to": "NOW"}, "sourceInput": "Combined", "orderBy": "total_volume_usd", "orderByDirection": "DESC", "perPage": 100 }

Get list of 20 MOST RECENT transactions made by an address or an entity (per page). Only the latest transactions according to the date range are returned. Provide exactly one of `address` or `entity_id`. An entity lookup returns transactions across all wallets of that entity and covers at most 7 days.

Get a wallet's individual trades on a single chain — DEX swaps (spot) or Hyperliquid perpetual trades, newest first. Wallet-centric companion to `token_dex_trades` (which is token-centric). Chain: one per call ('all'/'evm' unsupported). EVM wallets MUST pass `chain` explicitly (e.g. ethereum, base, arbitrum); non-EVM (e.g. Solana) is auto-detected. Use 'hyperliquid' for Hyperliquid perpetual trades (requires an EVM address). Call once per chain to span multiple networks. Spot columns: Time, Bought / Bought Amount, Sold / Sold Amount, Value USD, Tx Hash. Perp columns: Time, Token, Side, Action, Size, Price, Value USD, Fee USD, Closed PnL, Tx Hash. Sort (`order_by`, asc/desc): timestamp, value. Filter by `valueUsd`, `tokenAddressBought`, or `tokenAddressSold`. On spot chains the token fields take contract addresses. On Hyperliquid they take perp symbols and select Long or Short trades respectively; only one token field is allowed. Example: { "address": "0x1f2f10d1c40777ae1da742455c65828ff36df387", "chain": "ethereum", "dateRange": {"from": "7D_AGO", "to": "NOW"} }

Get a wallet's Hyperliquid positions and liquidation risk without a portfolio lookup.

Get PnL stats for a specific token traded by the input address during a specific date range. Use this tool for analysing the performance of the wallet for the specific token over a time period. Chain: pass 'hyperliquid' for a perp coin — there `tokenAddress` is the perp SYMBOL (e.g. 'BTC', 'HYPE', 'xyz:CL'), not a contract address. Every other chain expects a token contract address.

Get aggregate stats of overall realized PnL for the input address. For Hyperliquid perp traders (chain='hyperliquid'), includes realized PnL from fills plus a current unrealized snapshot of open positions. For chain='all'/'evm' on an EVM address, reports spot/on-chain and Hyperliquid perp results as separate sections (never summed). For a single named chain, this tool covers realized PnL only. Use this tool for analysing the performance of the wallet over a time period.

Get the first address that ever funded an EVM wallet, with the funding transaction hash, chain and timestamp. Use this to attribute an unlabelled wallet to a known entity — the first funder is often a CEX withdrawal or a wallet the same owner already controls. The funder is resolved across all chains, so no chain argument is needed.

Get comprehensive portfolio overview for a wallet address or entity. Hyperliquid perpetual positions include liquidation prices to support risk analysis workflows. For wallet addresses, supports different modes: - 'fast-mode-default': Wallet balances + Hyperliquid positions (skip defi, for fast mode only) - 'all': Wallet balances + DeFi positions + Hyperliquid positions - 'wallet_balances': Only token balances (tokens and native coins across all chains) - 'defi': Only DeFi positions (lending, staking, LP tokens, etc., excluding Hyperliquid) - 'hyperliquid': Only Hyperliquid data — perp positions (with liquidation prices and margin summary) plus HL spot wallet balances For entities (e.g., "Binance", "Paradigm Fund"), only on-chain token balances are returned, aggregated across all addresses associated with the entity. This tool provides flexible portfolio analysis in a single request, allowing users to focus on specific aspects of their holdings. The output is pre-formatted markdown that should be presented exactly as returned, preserving all tables, sections, and formatting without reinterpretation. Example Usage: Get full comprehensive portfolio for a wallet: ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "all" } ``` Get only DeFi positions (returns raw JSON): ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "defi" } ``` Get only Hyperliquid positions (returns raw JSON): ``` { "walletAddress": "0x28c6c06298d514db089934071355e5743bf21d60", "mode": "hyperliquid" } ``` Get token balances for an entity: ``` { "entity_id": "Binance" } ```

General search tool. This is your FIRST entry point to look up for possible tokens, entities, and addresses related to a query. Do NOT use this tool for prediction markets. For Polymarket names, topics, event slugs, or URLs, use `prediction_market_lookup` instead. Nansen MCP does not support NFTs, however check using this tool if the query relates to a token. Regular tokens and NFTs can have the same name. This tool allows you to: - Check if a (fungible) token exists by name, symbol, or contract address - Search information about a token - Current price in USD - Trading volume - Contract address and chain information - Market cap and supply data when available - Search information about an entity - Find the address behind a Nansen label (public figure, fund, exchange wallet) - Find Nansen labels of an address (EOA) or resolve a domain (.eth, .sol)

Search Nansen's entity names by a partial name and get back the exact entity names that match. Use this when a tool needs an exact entity name and the user gave an approximate one (e.g. "binance" -> "Binance 14"). Matching is case-insensitive and matches anywhere in the name. For tokens or addresses use `general_search` instead.

List valid token sectors for token discovery filters.

無需輸入參數。

Get chain growth rankings by active addresses, transactions, gas fees and DEX volume.

Get comprehensive transaction details including token transfers.

Search Polymarket for events and markets by name, topic, URL, or slug. **PM building blocks:** - An **event** is a grouped prediction topic containing many child markets. - A **market** is one tradable outcome with its own `marketId`. - Example: `2026 NCAA Tournament Winner` is an event; `Will Duke win the 2026 NCAA Tournament?` is a market. Detail tools require `marketId`, not `eventId`. **When to use:** - First tool when the user asks about a specific PM topic, event, slug, or Polymarket URL but does not provide `marketId`. - Optionally provide `queryVariant` as a cleaner short keyword version. - Set `includeEventMarkets` to true to also return child markets for the best-matching event. - Do NOT use `general_search` for prediction markets. - Results include current outcome prices, last trade price, and bid/ask inline — for a quick probability check you may not need `prediction_market_ohlcv`. For price *history* or dated moves, still use `prediction_market_ohlcv`. **Query tips:** - Uses Polymarket's search API — natural language queries work well. - Prefer short 1–3 keyword queries for best results. - Avoid broad multi-topic queries like `bitcoin ethereum politics`. **Output rules:** - If lookup returns no suitable market or a mismatched timeframe, say so explicitly — do not silently substitute a nearby market.

Browse and sort Polymarket markets, events, or categories. **When to use:** - Broad discovery, screening, and ranked browsing across many markets. - Do NOT use this to resolve one named market/event/slug/URL — use `prediction_market_lookup` instead. **Query tips:** - Literal-style matching on text and slugs, not fuzzy web search. - Prefer one short topic or slug fragment (e.g. `fed cuts`, `zelensky`, `ncaa tournament`). - Do not bundle unrelated topics (e.g. `bitcoin ethereum politics weather`). If a broad question spans several topics, run separate screener queries for each. - If a query returns no rows, do not invent a nearest match — try a narrower topic or say no data was returned. **Output rules:** - Superlatives (highest, leading, biggest, top, trending) must match the shown metric exactly. - Do not infer end dates, rankings, or category leadership from titles alone.

Historical odds/volume candles for a Polymarket market. **When to use:** - Current odds / implied probability, price history, and recent probability changes on a specific market. **Key fields:** - `Close` is the share price for the displayed outcome side. - In binary markets, Yes and No shares are complementary and sum to about $1. **Pitfalls:** - Each response is for one exact `marketId` — do not mix dates or prices across different markets. - If no candles are returned for the requested window, say so directly — do not estimate. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

Live orderbook for a Polymarket market. **When to use:** - Bid/ask depth, liquidity, and yes-share / no-share order structure. **Key fields:** - `Order Size` is share quantity, not USD. Do not describe share size as dollar depth unless you calculate `shares × price`. **Yes/No price relationship:** - Yes and No are complementary (Yes + No ≈ $1). A No bid at price $X means willingness to buy No when Yes is near $(1−X). - A cluster of No bids at low prices (e.g. $0.20) is resistance for Yes rallying to ~$0.80, NOT a support floor for the current Yes price. - When comparing OHLCV odds against orderbook depth, convert No-side prices to Yes-equivalent (1 − No price) before drawing divergence conclusions. **Pitfalls:** - Do not treat raw no-share prices as bearish yes-share odds — prefer `prediction_market_ohlcv` for current odds / implied probability. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

Largest current holders for a Polymarket market. **Key fields:** - Positions are share balances, not USD notional. - `Position Value USD` is current marked value, not payout at resolution. - `Side Held` is the share side currently held. **Pitfalls:** - The visible holder table is the source of truth for holder-side concentration — do not infer risk, max loss, or potential profit unless the tool output explicitly provides it. - Output summary is based only on shown rows, not the entire holder table. - Large visible positions or labels do not by themselves identify smart money unless Nansen smart-money-labelled data supports it. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

Recent trades for a Polymarket market. **When to use:** - Source of truth for recent fills and latest trade-tape pricing. - Do not overwrite recent trade prices with older OHLCV candles. **Key fields:** - `Share Size` is quantity; `Value USD` is dollar value. - Each row is one visible trade leg — `Value USD` applies to that row, not the whole transaction hash. **Pitfalls:** - Large visible trades do not by themselves identify smart money or institutions. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

PnL leaderboard for a Polymarket market. **When to use:** - Only for profitability claims. **Key fields:** - `Total PnL USD` = redemption + unrealized value + sell proceeds − buy cost, for this market only. - `Net Buy Cost USD` is what the wallet paid for shares. - `Net Sell Proceeds USD` is what it received for shares sold before resolution. - `Redemption Value USD` is the payout collected after the market settled. - `Unrealized Value USD` is the marked value of shares still held. - `Side Held` reflects current side exposure where the API provides it. **Pitfalls:** - The API gives no ROI, volume, or trade count here. Do not state them. - If PnL fields are blank, say profitability is unavailable — do not substitute top holders or position size. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

Detailed position breakdown for a Polymarket market. **Key fields:** - `Position Size (Shares)` is the share quantity still held. - `Buy Cost USD` and `Sell Proceeds USD` are the cash paid and received for this outcome token. - `Unrealized Value USD` is the marked value of shares still held; `Redemption Value USD` is the payout collected after settlement. - `Position PnL USD` applies to the displayed row only — not the wallet's total PM activity. **Pitfalls:** - Each row is one outcome token of one wallet. A wallet holding both sides appears twice. **Prerequisites:** If `marketId` is unknown, call `prediction_market_lookup` first.

Prediction market trade history for a Polygon wallet. **Key fields:** - `Share Size` is quantity traded in the displayed outcome side. - `Value USD` applies to that row only, not the whole transaction. **Pitfalls:** - Use this for wallet trade activity, not profitability.

Prediction market summary metrics for a Polygon wallet. **When to use:** - First wallet-level Polymarket tool for a quick trader overview. - Use before detailed address trades/PnL when the user asks for a general wallet profile, activity summary, or whether a wallet is active on Polymarket. **Key fields:** - `Markets Traded` and `Markets Won` are lifetime counts; `Win Rate` is won / traded. - `Total PnL USD` = realized + unrealized. - `First Seen` and `Wallet Age (Days)` show how long the wallet has been active on Polymarket. **Pitfalls:** - The API gives no trade count, volume, or ROI here. Do not state them. For per-market cost and proceeds use `prediction_market_address_pnl`. - Blank PnL fields mean unavailable data, not zero.

Prediction market PnL breakdown for a Polygon wallet, market by market. **When to use:** - Wallet-level Polymarket track record with per-market cost and proceeds. **Key fields:** - `Total PnL USD` = redemption + unrealized value + sell proceeds − buy cost, for that market only. - `Net Buy Cost USD` is what the wallet paid for shares. - `Net Sell Proceeds USD` is what it received for shares sold before resolution. - `Redemption Value USD` is the payout collected after the market settled. - `Unrealized Value USD` is the marked value of shares still held. - `Resolved` says whether the market has settled. **Pitfalls:** - Each row covers one market. Sum the rows for a wallet total, or use `prediction_market_address_summary` for the aggregate. - The API gives no ROI or share count here. Do not state them. - Blank PnL fields mean unavailable data, not zero.