Token Launch Radar — DEX Liquidity, Volume & Risk Score

Is this token worth a second look, or a stat you can skip? Point this Actor at a token contract address or ticker and get back liquidity, 24h volume, pair age, a 0-100 quality score and plain-English risk flags — read straight from DexScreener's public API.

⚠️ Not financial advice. qualityScore is a heuristic built from liquidity, volume and age — it is not a signal to buy, sell, or trust a token. Always do your own research.

What you get

• A consistent score instead of a gut feeling. 0-100 qualityScore from liquidity, 24h volume and pair age, plus plain-English riskFlags (very low liquidity, abnormal volume/liquidity ratio, brand-new pair, sharp 24h decline, large uncirculated supply).
• Filters built in. Drop anything below a liquidity floor (minLiquidityUsd) or older than a freshness window (maxAgeHours) — hunt fresh launches without eyeballing a hundred pairs by hand.
• Works on contract addresses or tickers — EVM 0x…, Solana base58, or a plain search term like PEPE. One row per entry.
• Chain-fork noise filtered out. PulseChain is a full state-fork of Ethereum, so pre-fork Ethereum addresses have an unrelated "twin" there with completely different liquidity — that twin is dropped unless it's the only match for the input.
• Ticker ambiguity is disclosed, not hidden. A contract address supplies stronger identity evidence; a ticker like TRUMP or PEPE is not unique and can resolve to an unrelated project using the same symbol. When you search by ticker/name, the row tells you how many distinct tokens it found under that symbol (candidateTokenCount), the real name of the one it scored (in summary and name), and the alternates it passed over (candidates). Pass a contract address instead and there's nothing to disambiguate — matchBasis: "address".
• Ticker search is not exhaustive, and the token found can carry a different symbol than you typed. The Actor queries both bare and $-prefixed forms and merges the bounded responses, but the upstream search is still not a complete token census. candidateTokenCount means "found within DexScreener's own (capped) search," not "every token that exists." A selected candidate can also carry a symbol that differs from the query. Read tokenAddress, name and symbol; never assume any one field matches your query.
• No key, no wallet, no on-chain node — just DexScreener's free public API.
• Runs on Apify: schedule it, monitor it, call it from the API or the MCP server, export to JSON, CSV or Excel, or push results straight into your own pipeline.

How to run it

1. Click Try for free — no card needed on the free plan.
2. Paste contract addresses or tickers into Tokens, one per line. Optionally set a liquidity floor or an age ceiling.
3. Press Start. Results appear in the dataset — read them in the UI, pull them from the API, or push them onward with a webhook.

Pricing

Pay-per-event: $0.005 per run start + $0.005 per token checked. No monthly seat. 100 tokens cost about $0.51; 1,000 tokens about $5.01.

A token with no usable pair, or one filtered out by minLiquidityUsd / maxAgeHours, is still returned with found: false and the reason — and it is not charged. You pay for pairs that actually exist, not for lookups.

简体中文说明

输入代币合约地址（EVM 0x… 或 Solana base58）或代币代码（如 PEPE），此 Actor 会直接从 DexScreener 的公开 API 读取该代币当前交易对的流动性、24 小时交易量、交易对存在时长，并汇总成一个 0-100 的 qualityScore（质量评分），同时给出通俗易懂的风险提示 riskFlags（例如流动性过低、成交量/流动性比例异常、交易对刚创建、24 小时跌幅过大、未流通供应量过大）。qualityScore 不构成财务建议，只是基于流动性、成交量和交易对年龄这三项公开指标的启发式打分，请自行研究（DYOR）。

可以设置 minLiquidityUsd（流动性下限）和 maxAgeHours（只看多长时间内新建的交易对）两个过滤条件，方便筛选新上线的代币。同一枚代币若在多条链上有交易对，本 Actor 会取流动性最高的一个；PulseChain 是以太坊主网的完整分叉，同一个合约地址在 PulseChain 上会有一个流动性完全不同的"分身"交易对，除非这是唯一匹配结果，否则会被过滤掉，避免这个分身干扰对知名代币的判断。

计费为按事件付费：每次运行 $0.005，每个成功查到交易对的代币 $0.005（result-found）。查不到可用交易对，或被 minLiquidityUsd/maxAgeHours 过滤掉的代币，会以 found: false 返回原因，不计费。100 个代币约 $0.51，1000 个约 $5.01。

这不是什么。 本 Actor 不审计合约代码、不检查所有者/铸币权限，也不模拟买卖来检测蜜罐（honeypot）——这些属于 Rug-Pull Risk Scorer（见下方 Related Actors）的范围。

Input

Field	Type	Description
tokens	array of strings	Contract addresses (EVM 0x… or Solana base58) or tickers/search terms. One row per entry. Up to 100.
minLiquidityUsd	integer	Drop the token's best pair if its liquidity is below this. 0 = no filter (default).
maxAgeHours	integer	Only keep pairs created within this many hours — hunt fresh launches. Leave empty for no age filter.
maxConcurrency	integer	Parallelism (1–20, default 5).

{
    "tokens": [
        "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
        "PEPE"
    ]
}

Output

One Dataset row is emitted per unique processed input. Exact market values are intentionally not embedded as evergreen claims: they change continuously. The release receipt ties a bounded canary Dataset and KVS OUTPUT to the exact production build. Use the field contract below to integrate, then inspect the canary-linked evidence for a live example.

Field	Description
input	The address or search term you passed
found	Whether a usable pair was found (and passed your filters)
chainId / dexId / pairAddress	Where the best pair trades
matchBasis	"address" — the input itself was the identifier, nothing to disambiguate. "ticker-search" — the input was free text matched by DexScreener's search index; a symbol is not unique, see candidates.
candidateTokenCount	Only set for matchBasis: "ticker-search": how many DISTINCT tokens (not pools) this Actor found under this symbol/name within DexScreener's own search results at query time — that search is capped (~30 raw pairs per query, up to ~60 once the bare and $-prefixed forms are merged) and not exhaustive, so this is a lower bound on real usage of the symbol, never a claim that no other token exists. null for an address lookup.
candidates	Only set for matchBasis: "ticker-search" with more than one match: up to 5 of the other distinct tokens found under the same symbol/name within that same (capped) search, ranked by liquidity, that were NOT picked — each with its own chainId, tokenAddress, name, symbol and liquidityUsd. The token you actually meant can be missing from this list entirely if DexScreener's own search never surfaced it.
name / symbol / tokenAddress	The token itself — name is the field that catches a symbol-only mismatch a ticker alone can hide (e.g. symbol: "TRUMP" can be the real thing or, live-verified, a token actually named "MAGA")
priceUsd	Current price in USD
liquidityUsd / volumeH24 / priceChangeH24	Pool liquidity, 24h volume, 24h price change
ageHours	Hours since the pair was created
qualityScore	0-100 heuristic from liquidity, volume and age
riskFlags	Plain-English warnings (low liquidity, abnormal volume ratio, brand-new, sharp decline, large uncirculated supply)
summary	Human-readable one-liner, always says how the token was matched — by address, or by ticker search among N candidates with the real name it found — and ends with a not-financial-advice disclaimer
error	Present only when found: false — why no row was returned

How the best pair is picked

A token can trade on many pairs across many chains. This Actor takes the one with the highest liquidity — with one guardrail: PulseChain is a full state-fork of Ethereum mainnet, so pre-fork Ethereum contract addresses have an unrelated "twin" on PulseChain with completely different liquidity and holders. Left in, that twin can silently outrank the real chain by liquidity for well-known tokens. PulseChain pairs are excluded unless they're the only match for that input.

When you search by contract address, the caller supplies a stronger identifier, but must still confirm chain, venue and intended asset independently. When you search by ticker or name, "highest liquidity" is picking among every DISTINCT TOKEN found under that symbol within DexScreener's own search results — DexScreener enforces no ticker uniqueness, so a fresh memecoin can and does launch under a well-known symbol. This Actor does not try to guess which one you "really" meant: it reports the token it picked by name (name, and inline in summary), how many other tokens it found sharing the symbol (candidateTokenCount), and up to 5 of the ones it passed over (candidates) — so a mismatch is visible in the row instead of hiding behind a ticker that looked right.

"Found under that symbol" is not the same as "every token that exists." The Actor queries both bare and $-prefixed search forms and merges the bounded responses. That widens the observed candidate set but does not make it exhaustive. candidateTokenCount means only "distinct contracts retained from these source responses." A returned token can also carry a different symbol from the query. Verify the selected contract, chain, name and symbol rather than treating the search term as identity.

API

Start a run with a bearer token and explicit JSON input:

curl -sS -X POST 'https://api.apify.com/v2/acts/zinin~token-launch-radar/runs?waitForFinish=60' \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"tokens":["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","PEPE"]}'

Read Dataset rows using the returned defaultDatasetId:

curl -sS "https://api.apify.com/v2/datasets/$DEFAULT_DATASET_ID/items?clean=true&format=json" \
  -H "Authorization: Bearer $APIFY_TOKEN"

MCP

For an Apify MCP client exposing the standard call-actor tool, send this exact payload:

{
  "name": "call-actor",
  "arguments": {
    "actor": "zinin/token-launch-radar",
    "input": {
      "tokens": ["0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48", "PEPE"]
    }
  }
}

Related tools

Related tools for adjacent workflows in crypto and wallets.

Actor	What it does
Live Price Oracle	Pair it in the crypto and wallets workflow: Current USD price for any token by contract address or ticker: 24h change, liquidity, volume, best DEX pair
Wallet Airdrop Readiness Score	Pair it in the crypto and wallets workflow: Profile a wallet on-chain: age, tx activity, contract & token diversity -> a 0-100 airdrop-farming...
Rug Pull Risk Scorer	Pair it in the crypto and wallets workflow: Score ERC-20/BEP-20 token rug-pull risk from honeypot.is simulation + DexScreener liquidity/age
Whale Wallet Tracker	Pair it in the crypto and wallets workflow: Track large native ETH and ERC-20 token movements for any wallet(s) via Etherscan's multichain API (bring...

FAQ

Does it need an API key or wallet? No — DexScreener's public API is free and keyless.

How fresh is the data? Every row records its observation time and computes freshness at run time. Upstream latency is controlled by DexScreener and is not guaranteed by this Actor.

Is qualityScore financial advice? No. It's a heuristic built from three public metrics (liquidity, volume, age). It does not account for contract risk, team behavior, or anything off-chain. Always DYOR.

I searched by ticker — is qualityScore definitely scoring the token I meant? Not necessarily, and the row tells you so. Check matchBasis: "ticker-search" means the symbol/name you searched matched several distinct tokens and this Actor scored the highest-liquidity one, not the one it "knows" you meant (it doesn't know). Read name and symbol (a found token's own symbol can differ from what you typed — see PEOPLE → PRN below) and candidates (the others it passed over) before trusting the score. Pass the contract address instead (matchBasis: "address") whenever you have it — that removes the ambiguity entirely.

Is candidateTokenCount a complete count of every token using this symbol? No. It counts distinct contracts retained from the bounded bare and $-prefixed source responses. Treat it as "at least this many observed," never a census. Verify contract, chain, name and symbol together.

Can I call it from an AI agent? Yes — it's a standard Apify Actor, callable via the Apify API or the Apify MCP server.

What this is NOT. It does not audit contract code, check ownership/mint functions, or simulate a buy/sell to detect a honeypot — for that on EVM tokens, see Rug-Pull Risk Scorer below.

Found a wrong result, or need a check we don't run? Open an issue on this Actor's page.

---

Built by zinin. Questions? Telegram @timzinin.

What this Actor is — and is not

Token Launch Radar is a bounded market-observation and review-routing tool. It turns a contract address or a non-unique search term into one structured row containing the best pair observed, the matching basis, point-in-time market fields, heuristic flags, confidence, evidence gaps and a manual next action. It is useful when a research queue needs the same transparent fields for every candidate instead of screenshots and untraceable notes.

It is not contract due diligence, holder analysis, code review, honeypot simulation, identity verification, valuation, a listing guarantee, a complete token census or an investment recommendation. qualityScore and riskFlags are documented heuristics over the observed pair. They do not prove legitimacy or predict returns. safeToAutomate is always false because no row is sufficient to trigger a purchase, sale, listing decision or customer communication on its own.

Evidence, confidence, and honest boundaries

The strongest input is a contract address. It identifies what was requested, although the caller must still verify chain, contract, pool and source freshness. A ticker or name is only free-text search. Symbols are reusable, search results are capped, rankings move with liquidity, and the intended asset may be absent. For that path, inspect name, symbol, tokenAddress, candidateTokenCount, candidates and matchBasis together.

Every paid row contains observedAt, sourceEvidence, confidenceScore, confidenceBand, confidenceReasons, confidenceRisks, dataGaps, recommendedAction, actionPriority, actionReason, interpretationBoundary, failureType, retryable, partial, billing and safeToAutomate. These fields are additive: existing market fields keep their meanings.

Confidence describes the strength of the observed identity and source path, not whether the token is safe or attractive. A high-confidence contract match can still describe an illiquid, malicious or rapidly moving market. A low-confidence ticker match can carry numerically precise market values for the wrong asset. Precision is not identity.

Decision playbook

1. Prefer contract-address inputs and retain the chain outside this Actor when building a watchlist.
2. For ticker searches, verify the selected tokenAddress against a trusted first-party source.
3. Open the pair evidence and confirm quote asset, venue, liquidity and observation time.
4. Treat risk flags as questions for review, never as pass/fail certification.
5. Record the independent checks that resolved each dataGaps item.
6. Only then route the row into a monitored research list. Do not automate a trade from this output.

Recommended-action values are deliberately operational. VERIFY_TOKEN_IDENTITY_BEFORE_USING_MARKET_FIELDS means the row came from an ambiguous search path. VERIFY_CONTRACT_AND_REVIEW_PRIMARY_MARKET_EVIDENCE means identity is stronger, but the market and risk interpretation still requires review. REVIEW_OR_CORRECT_TOKEN_INPUT means no usable observation was delivered.

Run-level OUTPUT contract

Dataset rows answer what was observed for each processed token. The Key-Value Store record OUTPUT answers whether the run completed safely. It reports requested, unique, duplicate, attempted, delivered, paid, local-non-monetized, free, source-failure and withheld counts. It also reports partial, budgetStopped, fatalError, replaySafe, status and resultsUrl.

• COMPLETE means every unique item reached a terminal delivered state without a recorded gap.
• PARTIAL means at least one source, policy or budget condition prevented a complete result set.
• FAILED means linked delivery or money state became unsafe or unknown.
• replaySafe: false means a push-and-charge outcome may be ambiguous; do not retry blindly.

The billing critical section is serialized across workers. Remaining budget is checked immediately before the linked pushData(row, "result-found") operation. A paid row increments the paid count only after delivery reports at least one charged result event. Free advisory rows never masquerade as paid market evidence.

Examples to branch on

Happy path: found:true, matchBasis:"address", a retained pair and token address, confidenceBand:"high", billing.billable:true, and a manual verification action. This means an address-based observation was delivered, not that the asset passed due diligence.

Ambiguous path: found:true, matchBasis:"ticker-search", several observed candidates, confidenceBand:"low", and identity gaps. Keep the row for triage, but resolve the intended contract before using any price, liquidity, volume, FDV or market-cap field.

Failure path: found:false, recordType:"advisory", a populated failureType, retryable and billing.billable:false. Retry only when the diagnostic says the source condition is transient. Correct invalid or ambiguous inputs instead of creating an automatic retry loop.

Source, privacy, and operating policy

The Actor uses the public DexScreener API with bounded requests, timeouts and response-size caps. It does not use a wallet, request seed phrases, submit transactions, bypass authentication, scrape private accounts or collect contact data. Inputs and outputs can still reveal a research watchlist; apply your own workspace retention and access controls.

Source availability, response shape, ranking and terms can change. Keep source attribution and the observation timestamp with every exported row. If a downstream product republishes the evidence, review the current source terms and avoid implying endorsement or completeness.

Integration checklist

• API clients should read Dataset rows and OUTPUT together.
• Store the original input, entityId, observedAt and sourceEvidence for auditability.
• Deduplicate by your canonical chain-and-contract identity, not by ticker.
• Alert on partial:true, retryable:true, low confidence or replaySafe:false.
• Keep a human approval step before financial action.
• Schedule new runs for freshness; never overwrite the prior observation without its timestamp.

Release evidence contract

The production release is accepted only when one bounded no-retry canary ties the exact build to a Dataset and KVS OUTPUT. The receipt must reconcile requested, unique, successful, failed, delivered, paid, free and withheld rows, charged events, usage and cheapest-tier cost coverage. Duplicate inputs are not billed twice. If linked delivery has an unknown outcome, replaySafe:false prevents a blind retry. These controls prove delivery integrity; they do not increase token-quality confidence or authorize a trade.