ANALyzer69000
Analyzer69000 · Developer API v1

One API. Nine chains.
Every pool. Free.

Honeypot simulation - LP burn & lock verification - deployer rug-history - Solana Token-2022 controls - P-Token-aware indexing - ownership / proxy / verified source · dangerous-function scan · deterministic rug-risk & blue-chip scores · full deployer trail · launch-bundle detection · live holder map with roles (pump.fun curve, LP, burn, deployer, retail). Every pool across every chain a token ever touched. Built in-house. No auth. No wallet connect. CORS-open. Integrates in under sixty seconds.

FREE forever at this tier CORS: * 9 chains 30/min · 300/hour 12h server cache 7 embed variants · 9 themes
New: Telegram bot — paste any address, instant forensics in-chat
Add to DMs or any group · replies with verdict, score, bundle, safety in under 2s
Open bot →

🆕 What's new

Recent changes · click any entry to expand. Expand all · Collapse all

2026-08-16 · Grading fixes for established tokens · completed rugs no longer read as clean · Boosts on 10 chains, pay by phone or agent · trending accuracy
  • A token whose liquidity had already been pulled could be graded as clean. The check that flags drained liquidity only applied once a token was more than a day old, on the reasoning that a brand-new token has not had time to build a pool yet. But the most common rug happens inside that first day. Once every pool is gone there is also nothing left to measure for holder concentration, wash trading or price divergence, so a token that had already been rugged could come back with a low score and a reassuring label. That is the worst mistake a rug scanner can make, so age is no longer a defence: a token with real holders and no remaining pool is now graded as untradeable, whatever its age. A token with no holders and no pool is simply unlaunched and is left alone. Rescan any token you checked recently to pick this up.
  • Established, governance-run tokens were being over-graded as risky. Two parts of the grader disagreed with each other. One correctly recognised that a token whose admin controls sit behind a contract — a DAO, a multisig, a timelock — is far less exposed than one controlled by a single private key, and scored it gently. The other still treated the same setup as a single-key risk and could force the harshest label regardless of the score. Long-lived tokens with large holder bases, verified source and clean sell tests could therefore be labelled far more harshly than their own score justified. The two now agree. The underlying control is still scored and still visible — a live mint or admin lever keeps a token out of the top tiers — it just no longer overrides everything else.
  • A token is no longer penalised for someone else reusing its ticker on another chain. Two fixes here. First, a same-name deployment elsewhere is only evidence that a project has moved if the token being scanned is young enough for that to be plausible; when the scanned contract is years older and still trading, the newer namesake is the copy, and flagging the original pointed you at the wrong contract. Second, the comparison relied on reported pool size, which is trivial to fake — a pool can be made to report an enormous figure while doing almost no trading. Reported size must now be consistent with actual trading before it counts as evidence, and where it is not, we say so plainly instead of holding it against the token.
  • A mint function is counted once. The ability to mint new supply was being charged twice on some tokens — once as a property of the token and again as a finding in its source code — inflating the risk score for a single fact. It now counts once. Where nothing else concerning is found in verified source, that verification is credited as a positive signal, which it previously was not.
  • Official project accounts are no longer flagged as impersonators. The authenticity check compared a project's linked social account against its ticker only. Projects whose account is named after the project rather than the ticker were therefore flagged as impersonating themselves. It now considers the project's name as well.
  • Verified Boosts: any of 9 chains, and new ways to pay. Tokens on Solana, Ethereum, Base, BNB Chain, Arbitrum, Optimism, Polygon, Avalanche and Robinhood Chain can all be boosted. The chain a token trades on has never had to match the chain you pay from. New: scan to pay — open the boost page, tap “Pay from my phone”, scan the code with any wallet app and approve. No extension, no desktop, nothing to copy back. Payment today settles on Solana in SOL or USDC; further payment networks are rolling out, and each one only appears once it is genuinely accepting payments, so you are never offered a route that cannot complete.
  • The agent payment gateway now actually settles. Our x402 endpoint told agents to pay and then retry, but the retry required an order reference the response never handed out — so an agent that followed the documented flow could pay and have no way to redeem it. The order is now issued as part of the same response, and the amount quoted is the amount owed. Anything that paid against the old quote should contact us and will be honoured. No API key, OAuth or SDK is required, and the settlement step returns a receipt.
  • Refunds explained, and paid back automatically. There is now a plain table on the Boosts page covering every outcome: fail the gate before paying and nothing is charged at all; fail it after payment and the full amount comes back; stop passing the scan mid-window and the slot pauses with half returned. Refunds go on-chain to the wallet the payment came from — the destination is taken from the transaction you already signed, so it cannot be redirected, and there is no address to submit or ticket to open. The mid-window trigger is our quality gate, not price movement: a token whose price falls but still clears the scan keeps its slot.
  • Trending shows the right tokens, on every chain. Per-chain trending could return a thin or stale slice while better data existed, so a quieter chain showed low-activity pairs instead of its real movers; it now draws from the same source as the shareable trending card, and the two agree. Where several unrelated contracts share one ticker on a chain — a common copycat pattern that ordinary de-duplication misses because the addresses genuinely differ — only the strongest is listed, so a handful of clones can no longer crowd out the real movers. Requesting a chain we do not cover now returns a clear error rather than quietly returning everything. A brief gap in upstream data no longer sticks: the feed keeps its last good result rather than publishing a suddenly-empty one.
  • The trending ticker scrolls on every chain. It previously only animated when a chain had enough tokens to overflow the strip, so quieter chains showed a motionless bar that looked broken. It now scrolls regardless of how many tokens a chain has.
  • Wider token artwork coverage. Logos now resolve for tokens on newer networks that our previous sources did not index, including artwork a token publishes through its own contract — which is where several launchpads put it. Where a token genuinely has no artwork anywhere, the branded placeholder still stands in. Robinhood Chain tokens were the most affected and now show their real logos in trending, on scan pages and in share cards.
2026-08-15 · Corrected price on share cards · Rug Radar keeps its full history · richer news reports
  • Share cards showed the wrong price for very low-priced tokens. Prices below about $0.0001 are written in the compressed notation every major scanner uses, where a small digit stands for a run of leading zeros: $0.0₅6951 means five zeros then 6951, or $0.000006951. On the generated share images that small digit was being drawn as an ordinary one, so the same price read as $0.056951, roughly eight thousand times too high. It affected the token card, the trending card, the boost card and the receipt card, and only ever the price field; market cap, liquidity and volume were always correct. The notation is now drawn as real typography rather than a special character, so it renders correctly everywhere. Prices on the site itself, in the API and in the Telegram bot were never affected: this was only the generated images.
  • The Rug Radar now keeps every detection permanently. The public feed only reached back about two weeks, and older detections disappeared. Each detection was stored as a child record of the short-lived working queue that produced it, so when that queue row was cleaned up on its normal fortnightly cycle the detection was removed with it. Detections are now independent of the queue and are additionally written to a permanent archive, so the record only grows. Cleanup still reclaims the working space it always did, and now refuses to run at all unless the archive is current. Detections from before this fix could not be recovered; everything from 1 August onward is retained.
  • Sharing a token straight from the Buzz desk no longer risks a blank preview. A token that had not been scanned yet could be shared before its report existed, and social platforms cache whichever preview they see first, so an empty card could stick to that link permanently. The desk now shows whether a token has been scanned, and withholds the report link until it has.
  • News reports carry real images and cite their primary source directly. Published reports now show the publisher's own image where one exists, and reports drawn from official records (regulator, court and agency publications) additionally show a dated screenshot of the source page itself. Reports we research in-house render their own evidence card built from the measurements behind the story.
  • Two new kinds of in-house investigation appear in the news feed. One covers wallets minting tokens at industrial scale, verified on-chain across the operator's whole run rather than a recent sample. The other tracks what sanctioned addresses are actually holding right now across Bitcoin, Ethereum, Tron and Solana, naming the designated entity and linking every address to its own block explorer. Both publish the figures and addresses behind each claim so any reader can re-check them.
  • Headlines and figures in reports read correctly. Card headlines could be cut off mid-sentence, and occasionally mid-word; they now end on a complete sentence. A malformed money figure could also reach print (a truncated amount rendered as $3,.) and figures written as $110B were being missed entirely, so a report could lead on a trivial number instead of the one in its own headline. Figures are now validated and the headline's own figure is preferred.
  • Sanctions screening covers the full designated list. The scanner's sanctioned-address check was falling back to a small built-in list. It now reads the complete published designation list, refreshed daily.
  • A drained pool is now scored as the risk it is. Liquidity fed the radar, the trending feed and the buzz desk, but it never reached the rug score. A token whose pool had been emptied could therefore still return a high safety score and read as clean, because a burned LP counted in its favour while nothing checked whether the pool still held anything. A pool with no reserves behind real trading volume now carries a heavy penalty and is stated plainly in the risk factors. The check is deliberately narrow: it uses the deepest pool rather than the total (which can read near-zero on multi-pool tokens even when a real pool exists), requires a pool to actually exist so a pre-graduation launchpad token is never flagged, and requires real 24h volume, so the signal is the contradiction of a venue reporting trades while holding nothing.
  • Card headlines break on words, and badges no longer show empty boxes. A long token name could be split mid-word ("What 5 Years Does To Y / ou") because the card measured width per character to support Chinese, Japanese and Korean names, which wrap anywhere. Latin names now break at spaces, CJK is unchanged, and a title that fits no longer picks up a stray ellipsis. Separately, a few badges used emoji the card fonts have no glyph for, so they rendered as an empty box; those badges are now plain text.
  • Scope. The price and liquidity corrections change what is displayed and what the risk score reflects. No API response shape changed. Scores may move on tokens whose pools are empty, which is the intended correction.
2026-08-14 · Non-token addresses no longer graded · accurate LP-unlock signal · wider logo and wallet coverage
  • An address that is not a token is now identified as such, instead of being graded as one. Pasting a program address, a plain wallet, or a mistyped address previously ran the full token grading path anyway. With no pool and no holders to find, that produced a confident but meaningless LIKELY_RUG verdict complete with a "liquidity drained, LPs pulled their stake" reason, for something that never had liquidity because it was never a token. The scanner now confirms the address really is a token mint before grading it, and otherwise returns not_a_token with the account type it actually is. Any report previously cached for such an address is purged, so these also stop appearing in the live scan feed.
  • The prediction card's LP-unlock window now matches the report. A token whose liquidity lock expires in, say, 15 days could show "LP unlocks in 0 days" on the prediction card while the liquidity section of the same report correctly read 15. The two now read from the same value. Related: within a single risk area, a warning is no longer hidden behind a reassuring signal — a lock that is about to expire is surfaced rather than being masked by "LP locked".
  • More tokens show their real logo, especially on the EVM chains. Logo lookups that failed once were remembered as "no logo exists" for up to 30 days, so tokens that later became resolvable stayed blank. That memory has been cleared for the EVM chains and an additional logo source added. Tokens that genuinely have no logo published anywhere still fall back to the generated avatar, which is expected.
  • Wallet connect covers more wallets, with each wallet's official brand mark. Several wallets offered in the connect dialog had no icon and rendered as a plain coloured initial. All wallets now ship their official logo, taken from the wallet vendor's own published brand asset, and the in-chat connect dialog uses the same set as the main one.
  • Scope. No change to scoring, verdicts, or any existing API response shape. not_a_token is a new error response, returned only for addresses that are not token mints.
2026-08-12 · Reliable multi-chain market data · share links unfurl correctly for brand-new tokens
  • Live market data is flowing again on every supported EVM chain. Trade ingest on several EVM chains had stopped, which left volume, buy/sell split and the live trade tape thin or empty on those chains while Solana was unaffected. The cause was in how the ingest chose between its data sources: a source that was refusing requests was treated as a final answer instead of a reason to try the next one, so healthy sources further down the list were never reached. Source selection now rotates properly, and a source that is briefly refusing is skipped for a short cooldown rather than being retried on every request. All supported EVM chains are ingesting again, and the same fix makes the pipeline resilient the next time an individual source degrades.
  • Sharing a scan of a brand-new token now produces a proper preview card. Sharing the link to a token that had never been scanned before could show a broken image on social platforms, while previously-scanned tokens were fine. The report page was waiting on a first-time scan for longer than social platforms allow before they give up, so the preview never got read. The page now answers fast in every case, and the preview upgrades to the full detail once the first scan completes.
    If you shared a link while this was happening, the platform may have cached the broken preview. Re-sharing the link, or running it through the platform's own card validator, refreshes it.
  • Pool volume statistics are no longer silently dropped. A batch of pool volume updates could be discarded whole if it contained a single pool that had traded before it was catalogued. Those updates now apply, so 24h volume and swap counts on pool listings are more complete.
  • Scope. Data completeness and sharing only. No change to scoring, verdicts, or response shapes.
2026-07-25 · Trench Chat: repeat-message spam filtered, and chat is now limited to real token pages
  • Less spam in token chats. The same message posted over and over is now filtered out, so a token's chat stays readable. Normal fast back-and-forth is untouched: only literal repeats from the same sender are skipped.
  • Chat opens only on real token pages. A chat room now requires a valid token address, so a mistyped or non-existent address no longer creates an empty, confusing chat. Existing token chats are unaffected.
  • Scope. Trench Chat only. No change to scan results, scoring, verdicts, or any API response shape.
2026-07-21 · Social signal — see who is talking about a token, right on its scan page and via a new API
  • New "The Word on X" section on every token page. When a token has been mentioned by the established crypto accounts we track, its scan page now surfaces those posts — the account, follower reach, verified status, engagement, and a link to each — so you can see who is talking about a contract and how loudly, right next to the on-chain forensics. It stays hidden entirely when no tracked account has mentioned the token. Chatter is a signal, not safety: always read the full scan.
  • New public endpoint: GET /api/v1/chatter?addr=<address>. The same social chatter for any contract, as JSON (author, follower reach, verified flag, engagement, links). Served from a warm internal index and CDN-cached, so it is a single fast read that never rate-limits on your traffic. Full contract in the REST API reference below.
  • In the Telegram bot too. Drop a contract in a group and the scan reply now appends the top mentions from tracked accounts, inline with the verdict and metrics.
  • Scope + honesty. Mentions come from a curated set of established accounts and are attention, not endorsement — loud does not mean safe. Each post shows when it was actually made (historical social context, not a live ticker). Solana + all EVM chains; existing response shapes are unchanged.
2026-07-18 · Grading-fairness fixes: closed cases where established anti-bot / governance-owned tokens were still over-flagged
  • Closed a gap where a heavily-held, exchange-listed anti-bot token could still be force-flagged. The anti-bot-versus-honeypot distinction shipped earlier (see 2026-05-22) did not always fire: an established token with a large holder base and multiple exchange listings could still be pinned to a maximum-risk verdict when the checks that should have cleared it were briefly unavailable. The scanner now leans on the most reliable holder and market signals it already has for that call, so such a token is graded as an anti-bot advisory (anti_bot_suspected), not a honeypot. Genuine honeypots, where real holders cannot sell, still score as a hard fail.
  • Established, governance-owned tokens with live admin controls settle at HIGH RISK, not likely-rug. Building on the multisig-governance fairness from 2026-05-22: when an established, exchange-listed token keeps live admin powers (pausable transfers, a blacklist, or a mint function) under multisig, timelock or DAO governance, its verdict now settles at HIGH_RISK, real centralized risk, rather than LIKELY_RUG, which implies an imminent scam. The controls stay visible and still count toward the score. A token where a single private wallet holds those controls, or that does not clear the established bar, is unchanged, and honeypots, punitive taxes and confirmed deception still force LIKELY_RUG.
  • New: a static "hidden owner" signal is reconciled against the real on-chain owner. A generic "hidden owner" flag can fire whenever a contract is owned by another contract instead of a wallet, which is exactly what a governance owner looks like. When the owner resolves on-chain to a recognized governance contract (multisig, timelock or DAO), that flag now becomes an advisory (hidden_owner_is_governance) instead of a critical rug reason. The genuine "looks renounced but a hidden role still keeps control" case, where no governance owner resolves, stays critical.
  • Scope. Applies to EVM chains. Response shape is unchanged; the new reason kind hidden_owner_is_governance may appear, and reports carry a new schema version (135) so cached reports re-grade on the next scan.
2026-07-16 · News Desk: reported facts and our analysis clearly separated · more accurate categories · Trench Chat keeps more history
  • News Desk stories separate the reported facts from our analysis. Every story now leads with the source's reported facts, attributes them to the original outlet, and presents our independent read in its own clearly labeled section, so it is always obvious what the source said versus what we added. We do not republish the article: we summarize the substance, add context, and link the original. Stories now surface short context tags and pull the specific figures and parties into the read instead of generic filler.
  • More accurate story categories. Categorization is more precise, so an enforcement action or a market story is no longer mislabeled as a hack just because it mentions stolen funds, and the text generated for sharing reads more varied and specific to each story.
  • Trench Chat keeps more history in view. The per-token chat retains a larger window of recent messages, so more of a room's conversation stays visible on load.
  • Scope. Product updates to the News Desk and Trench Chat. No API or response-shape changes.
2026-07-08 · Robinhood Chain support — first-to-market, with tokenized-security recognition
  • Robinhood Chain is now a fully supported chain. Robinhood's new Ethereum L2 (mainnet since July 1) is wired into the scanner, the quick scan, trending, and the Telegram bot — pass chain=rh or just paste a Robinhood Chain contract and it auto-detects. Because the chain is brand new, we built a dedicated in-house data layer for it, so the full forensic surface — holder map, deployer trail, contract verification, market data, honeypot-style checks — works there from day one, at the same depth as every other chain.
  • Tokenized stocks are recognized as securities, not flagged as rugs. Robinhood Chain carries official tokenized-equity tokens (NVIDIA, Apple, Tesla, and 200+ more) alongside ordinary permissionless memecoins. Those stock tokens are issuer-controlled by design — the issuer can mint, burn and upgrade them — which a naive scanner would wrongly flag as a rug. We recognize the official tokens by their on-chain issuer (unspoofable: a fake clone deploying from a different address still scores as the memecoin it is) and mark them as a verified tokenized security, while honestly surfacing the caveat: Robinhood Stock Tokens are tokenized debt instruments giving economic exposure only, not the underlying shares or voting rights, self-custodied and not FDIC/SIPC insured.
  • Scope. Robinhood Chain (rh) joins Solana + 7 other EVM chains. Response shape is unchanged; a new token.rwa block and safety.rwa_caveat appear only on recognized tokenized securities.
2026-07-08 · Instant provisional scan · real-time watchlist alerts · Analyzer Live rug broadcast
  • Instant first answer while the deep scan runs. Paste a contract and you now get a provisional read — verdict, live price and liquidity, and the top red flags — in under a second, while the full forensic scan (launch bundle, dev-snipe, insider cluster, LP-lock, holder map) completes in the background and replaces it. In the Telegram bot, a contract dropped in a group gets that provisional card immediately instead of a wait. New public endpoint: GET /api/v1/quick (see below).
  • Real-time watchlist alerts. Watching a token in the Telegram bot (/watch) now pings you within minutes, not once a day, when its verdict degrades, an active rug or honeypot is detected, or the predictive model escalates it. Alerts are deduplicated and cooldown-limited, so a token can never spam you, and watching a token that is already flagged won't ping you for what you already know.
  • Analyzer Live — a public rug broadcast channel. The most clear-cut, human-verified rug calls now broadcast in real time to a public Telegram channel the moment they publish to /radar, each with the token, the verdict, and a link to the full forensic report. Follow it to see rugs as they get caught.
  • Scope. Applies across Solana and all 7 EVM chains. Existing endpoints and response shapes are unchanged; the quick endpoint is additive.
2026-07-08 · Full launch-window analysis on EVM · insider-cluster detection on EVM · same-chain copycat detection on EVM · expanded sanctions screening
  • Full launch-window analysis on EVM chains. Coordinated first-minute buying, dev-snipe, launch bundles and token age are graded on EVM launches (Ethereum, Base, BSC, Arbitrum, Optimism, Polygon, Avalanche) on the same scale the scanner already applies to Solana, with the same fairness treatment: a bundle that has already sold out is graded as historical rather than active risk. Long-established EVM tokens earn full track-record credit toward ESTABLISHED and BLUE_CHIP verdicts.
  • Insider-cluster detection on EVM launches. The scanner traces launch-window wallets to their funding source and flags coordinated groups that trace back to a single private wallet, the signature of one operator funding many wallets to buy their own launch. Funding from an exchange, a bridge or a public router is treated as normal activity and never counted as coordination.
  • Same-chain copycat detection now covers EVM. When a fresh contract clones the name or logo of a well-established token on the same chain, the report flags it and cites the genuine contract so users can find the real one. A same-ticker, different-project overlap is surfaced as a neutral informational note. Tuned conservatively so only clear clones are flagged.
  • More thorough launch-bot detection on EVM. Launch-window buys driven by automated sniper and sandwich bots are factored into the launch-quality read, so a launch dominated by bots reads as mechanical rather than organic adoption.
  • Expanded sanctions and watch-list screening. Reports screen the token deployer, the wallet that funded the deployer, and the top holders, across both Solana and EVM, against OFAC-designated entities, sanctioned mixers, state-actor-linked wallets and a curated high-risk-deployer list. Exchange, LP and burn addresses are excluded from the holder screen. Reports may now carry funder_sanctioned or holder_sanctioned reasons.
  • Broader contract-upgradeability coverage. The scanner recognizes the full range of upgradeable-proxy patterns on EVM contracts, so upgrade risk is graded consistently. The lighter treatment for bridge-standard and multisig-governed upgrades is unchanged.
  • Liquid-staking tokens graded on mechanics, not names. Tokens that present as liquid-staking assets are assessed on their actual on-chain staking setup, so the softer grade those assets receive applies where the on-chain structure supports it.
  • Scope. Applies across Solana and all 7 EVM chains. The response shape is unchanged aside from the new reason kinds above, and reports carry a new schema version so cached reports refresh on the next scan.
2026-06-28 · Trench Chat: non-custodial on-chain tipping · gasless option for token holders · public tips read API
  • Tip anyone in a token's chat, on-chain. A verified wallet can tip a message author — or any address in the room — in the room's own token, SOL, or USDC. Tips are non-custodial: the sender signs with their own wallet and the recipient is resolved from the message you tap, so no address is ever pasted by hand.
  • Gasless for holders with no SOL. A gasless option covers the network fee for users who hold the token but have no SOL, so they can still tip without topping up first.
  • Built into the embed, with a public read API. Tipping ships inside the <trench-chat> widget with no extra wiring. Read recent tips and a per-room leaderboard at GET /api/v1/chat/tips, check tip capabilities at GET /api/chat/tip/config, and listen for the trench-chat:tip event in your own UI. See Trench Chat.
  • Scope. Tipping is live in Trench Chat rooms; the chat, verified badges, and sentiment run on every token page across Solana and 7 EVM chains.
2026-06-26 · Trench Chat: per-token chat with on-chain forensic identity · embeddable widget + read API · clearer scan errors
  • Trench Chat now shows who is really talking. The per-token chat that lives on every scan stays anonymous by default, but a reader can verify a wallet with one free signature (no transaction) to earn on-chain badges that sit next to every message: DEV, SNIPER, BUNDLE, WHALE, and HOLDER with rank and supply share. So when a dev hops into a token's chat to hype his own bag, everyone sees the DEV tag. Sentiment is weighted by verified holders, with live message velocity, and the pulse is fused onto the scan card.
  • Embed it in any app in one line. A <trench-chat> tag drops the same shared per-token room into your site, with a public read API to pull a token's chat, sentiment, and verified-holder signal. See Trench Chat and the live demo.
  • Threads, permalinks, and share to X. Reply to any message, copy a link straight to it, and share a token's live chat pulse to X.
  • Clearer scan errors. A mistyped or lowercased address now returns a specific, helpful message (Solana addresses are case-sensitive) instead of a raw HTTP code.
  • Scope. Trench Chat works on every token page across Solana and 7 EVM chains.
2026-06-24 · LP lock expiry detection · curated News Desk · Rug Radar auto-publishes the clearest rugs · always-on share cards
  • LP lock expiry is now graded, not just "locked or not" — a locked LP is only safe until the lock expires. A short lock taken at launch, so a token passes a quick glance and the team then pulls liquidity a few days later, is a common rug setup. The report now reads each LP lock's actual unlock date and grades it: a lock that expires within 30 days is flagged as a pull risk and the card shows "LP lock expires in N days (date)" instead of a green "fully secured"; 30 to 90 days reads as a caution; a long lock, or a permanent burn, keeps full credit. New report fields: liquidity_lock.unlock_at and liquidity_lock.lock_days_remaining. Example: a fresh BSC token showing "LP 99.99% locked" but whose lock unlocks in 15 days now reads SUSPICIOUS instead of Safe.
  • News Desk is now hand-curated/news aggregates crypto crime, hacks, fraud, sanctions, seizures and enforcement from public records and reporting; the desk hand-picks what to publish. Each published story gets its own page and share card, and a source-attributed post ready for X. Allegations stay allegations until the record says otherwise.
  • Rug Radar publishes the clearest rugs automatically — the most clear-cut, corroborated detections with no person named now post to /radar on their own, around the clock. Anything less certain still waits for human review, naming a person always stays human-gated, and the desk can override, edit or unpublish any call at any time.
  • Share cards always show the token logo — the image that unfurls when you share a /check report link now reliably renders the token's logo on every platform.
  • Scope — LP lock expiry applies across all 7 EVM chains; News Desk and Rug Radar are platform features.
2026-06-23 · Accurate holder counts · full 8-chain coverage · accurate pricing on volatile-pair tokens · honest market cap on staked/rebasing tokens · human-verified Rug Radar
  • Accurate price & market cap on tokens that trade against volatile pairs — when a token's deepest pool trades against another volatile token rather than a stablecoin or a major asset, the displayed price could inherit that other token's value and come out wildly wrong, which then inflated the market cap and tripped risk flags. Price, market cap and fully-diluted value are now taken from a trusted reference pair (stablecoin or major-asset priced) whenever one exists. A widely-listed governance token that was reading an impossible multi-trillion-dollar cap (and being mislabeled high-risk as a result) now prices correctly and reads as the established asset it is. Pool-to-pool "price divergence" is likewise only compared between trusted reference pairs, so a healthy token with one exotic pair is no longer flagged for manipulation.
  • Holder counts cross-verified across multiple sources (EVM) — EVM holder counts are now triangulated across several independent sources, so the number stays accurate and complete even when one source is briefly rate-limited or unavailable — across all 7 EVM chains, including BSC and Avalanche. The count never silently collapses to just the visible top holders.
  • True holder counts on every Solana token — some tokens, especially newer Token-2022 and launchpad mints, could under-report their holder count (showing only the top wallets instead of the full set). Reports now enumerate the complete holder base and show the true number with a verified indicator. A token that actually has 500 holders no longer reads as 20.
  • Complete coverage across Solana + 7 EVM chains — on-chain reads (supply, decimals, holder balances, mint and freeze authority) now run directly against each chain, with Optimism fully wired alongside Ethereum, Base, BSC, Arbitrum, Polygon and Avalanche. You can also pass a chain by its common name (ethereum, arbitrum, polygon, binance) and it resolves correctly.
  • Honest market cap on staked / rebasing tokens — for staked or rebasing tokens (the OlympusDAO-style "(3,3)" model, where supply grows continuously through rebasing), the headline "market cap" is price × an ever-inflating supply — a nominal number, not money you could ever exit into. When that figure is an extreme multiple of the token's real exit liquidity with no independent corroboration, the report now labels it "nominal" with a plain-English caveat instead of presenting it as a real valuation, and tags the token as rebasing. Example: a token showing a $10B "cap" against $36K of pooled liquidity is now clearly marked unrealizable.
  • Launchpad mint & freeze authority read correctly — bonding-curve launchpad tokens (pump.fun and similar) revoke both mint and freeze authority at creation, which is a good property: the supply is fixed and can't be inflated, and accounts can't be frozen. The report no longer treats "no mint / no freeze authority" on these as a concern — absence by design is recognized as fixed-supply safety, while a genuinely active authority is still flagged.
  • Rug Radar — wider live coverage, fully human-verified — the radar now watches a far larger stream of brand-new launches across all 8 chains the moment they form real liquidity, prioritizing the most prominent and highest-risk ones for investigation. Every detection published to /radar is still reviewed and signed off by a person before it goes live; nothing reaches the public feed automatically. Card ages now reflect a token's true current age rather than its age at first detection, and the public feed adds search, a time-range filter (24h / 7d / all), per-card copy-address and one-tap share, alongside the existing chain, verdict and sort controls.
  • Scope — holder accuracy and launchpad-authority handling apply to Solana; the chain-coverage and market-cap honesty changes apply across Solana and all 7 EVM chains.
2026-06-22 · Copycat detection · multi-source corroboration · wrapped-asset identity · wash-aware organic score
  • Copycat / fake-token detection (new) — the most common memecoin scam is a fresh contract that clones the name and symbol of an established token on the same chain, riding its recognition to drain buyers. The existing imposter check only covered clones of registry-listed projects; this catches memecoin-against-memecoin copies. When a scanned token shares a name and symbol with an older, far larger, or verified token at a different address, the report flags it as a copycat and a copycat block surfaces the genuine contract so users can find the real one. Example: a day-old "Smoking Chicken Fish $SCF" with 112 holders cloning the verified two-year-old $SCF with 23,000 holders is now flagged, with a one-tap link to the real token. Tiers: copycat (a verified original of the same name exists elsewhere), likely_copycat (a much older, much larger same-name token exists), symbol_collision (informational — a verified token shares the symbol but not the name).
  • Multi-source corroboration (new) — every report is now cross-checked against several independent sources, surfaced in a corroboration block. It reports where the independent reads agree with the scan (price confirmed by an independent oracle, token identity confirmed, mint and freeze authority status confirmed) and, just as importantly, where they disagree. A price that diverges from an independent oracle, or a token whose identity does not line up across sources, is shown as a warning instead of being quietly trusted. Independent organic-activity, holder-count, top-holder-percentage and LP-locked figures are surfaced next to the scan's own numbers so you can see the call is triangulated, not single-source. Disagreements are surfaced, never hidden.
  • Wrapped / canonical assets identified correctly across chains — in some ecosystems the canonical wrapped-native token uses the same address on every chain (the identical address is Wrapped SOL on one chain and a different chain's wrapped native elsewhere). Registered canonical assets are now identified from a verified registry first, so a wrapped asset always carries its own name and symbol and is no longer mislabeled with another chain's identity or hit with cross-chain price-divergence or imposter flags that don't apply to it.
  • Wash-aware organic-activity score — the organic score now factors the ratio of 24-hour volume to pool liquidity. Recycling the same dollar through a thin pool to fake demand shows up in that ratio even when a token's market cap has been pumped, so a heavily wash-traded launch can no longer read as "organic adoption." The verdict is capped down to reflect the wash, with the reason shown on the report.
  • Scope — corroboration price + identity checks run on Solana and all 7 EVM chains; the wash-aware score and the wrapped-asset fix apply everywhere.
2026-06-21 · Fairer EVM grading · multi-chain tokens · faster, more reliable scans
  • Renounced contracts with compliance blacklists graded fairly. Many established ERC-20s ship a blacklist or pause function for exchange and regulatory reasons. On a contract whose ownership is verifiably renounced, with no hidden owner, those functions are inert code that nobody can ever call. The scanner no longer treats them as a live rug vector, so a renounced blue-chip like SPX6900 reads as BLUE_CHIP instead of being pinned to a rug verdict by a function that can never execute. A live, owner-callable blacklist on a contract that is not renounced still scores as the real risk it is.
  • Multi-chain and bridged tokens recognized as one asset. A token that lives on several chains through a bridge, for example SPX6900 (native to Ethereum, bridged to Solana and Base via Wormhole), used to look like a chain-hop abandonment when most of its liquidity sat on a busier chain. The report now recognizes bridged sibling deployments as the same asset across chains and surfaces that as informational multi-chain context, never a rug flag. Registered canonical tokens skip the abandonment check entirely.
  • SPX6900 and more established memes added to the canonical registry. Top-100, years-old, renounced memes now carry a verified canonical classification alongside PEPE, SHIB, FLOKI, MOG and others, so launch-window and LP-lock heuristics that only make sense for brand-new tokens no longer apply to them.
  • More accurate bundle detection on high-volume tokens. Tokens with very large transaction histories could previously exhaust the launch-window walk and fall back to showing an ORGANIC launch by default. The launch analyzer now reaches the true launch window on these tokens, so coordinated and sniped launches on high-volume names are flagged correctly instead of slipping through as organic.
  • Blue-chip tokens scan reliably. Fixed an edge case where a small number of mature, high-cap tokens could fail to return a full report. Established tokens now scan cleanly every time.
  • Faster and more reliable scans. Backend data routing was rebuilt with multi-endpoint failover and automatic recovery, so scans stay fast and keep working even when an upstream data provider is rate-limited or having a bad day.
  • Scope. The EVM grading changes apply across Ethereum, Base, BSC, Arbitrum, Optimism, Polygon and Avalanche. Multi-chain recognition is cross-chain by design, Solana included.
2026-05-22 · Imposter detection · chain-hop abandonment · canonical-chain compare
  • Canonical-chain compare (new) — when a token is verified as canonical on a secondary chain (e.g. the real PEPE deployment on BSC while ETH holds 98% of the project's liquidity), the report now resolves the canonical-chain contract address and surfaces a one-tap "scan the primary deployment" link. Lets users instantly compare two real deployments of the same brand that may have materially different security properties — for example, the ETH PEPE is fully renounced and immutable while the BSC PEPE has an active multisig that can mint. Same name, different controls. Now obvious at a glance instead of buried in the contract details.
  • Chain-hop abandonment detection (new) — when a project's main liquidity has migrated to a newer deployment on a different chain (the original-chain pool is shrinking while a fresh contract on another chain holds the majority of total cross-chain liquidity), the report flags the original chain as "holders may be stranded" and pushes the verdict to LIKELY_RUG. Catches the pattern of a team launching a new contract on a new chain and walking away from the original — the BSC → ETH chain-hop is the most common variant, but Base → Solana and the reverse all trigger.
  • Cross-chain liquidity share (new) — for canonical multi-chain tokens, the report now identifies which chain holds the dominant share of total cross-chain liquidity and surfaces the scanned chain's own share. If most liquidity lives on a different chain, the scanned instance is shown as a secondary deployment — informational, no penalty — and the single-chain structural mismatch detectors are softened accordingly.
  • Imposter / brand-squat detection (new · Tier-1 signal) — when a scanned token's name and symbol match an established real project but the contract address is not in that project's verified deployments across any chain, the report now flags it as an imposter and pushes the verdict to LIKELY_RUG. Catches the pump.fun PEPE / BSC SHIB / Base UNI epidemic where permissionless launchpads spawn brand-squats that drain users on name recognition. Severity tiers: confirmed_imposter (real project has a verified address on this same chain at a different address), likely_imposter (real project exists, scanned contract not in its deployments), suspected_imposter (symbol collision on a smaller-cap project). A canonical block surfaces the real project's name, market cap, official chains, and homepage so users can find the real contract.
  • Verified-canonical positive signal (new) — when the scanned address matches the canonical project's verified contract on this chain, a small blue-chip bump fires and the report shows a "verified canonical" chip. Distinguishes the real PEPE from copycat PEPEs.
  • Bridge-aware structural scoring (new) — cross-chain bridged tokens (LayerZero OFT, xERC20, Chainlink CCIP, OP Stack mintable, Arbitrum L2 gateway, ERC-4626 vaults) now have the new mcap-to-DEX-liquidity and CEX-volume-detached signals softened or skipped. Bridged tokens have liquidity primarily on their canonical chain; the scanned chain is a node in a multi-chain mesh, so single-chain liquidity is structurally a fraction of total market cap. Upgradeable proxies on bridge tokens with multisig governance get a softer penalty as well — being upgradeable is a protocol requirement for bridge mechanics, not a private-key rug vector.
  • Fairer scoring for multisig-governed tokens — when a token's mint or admin powers are held by a properly configured multisig (e.g. a Gnosis Safe with several signers and a meaningful threshold) or by a DAO governor / timelock contract, the report now treats those powers as multi-party governance levers rather than as a single-key rug vector. Visible-source findings like a mint function no longer stack on top of the same fact a second time. The control still shows on the report — it just no longer pushes a CEX-listed protocol token into a rug verdict on its own.
  • Multi-chain market cap and FDV accuracy — for tokens whose canonical supply lives on a different chain than the contract being scanned (e.g. a token native to Ethereum but also deployed on Base or BSC), the scanner now reconciles the displayed market cap and fully-diluted valuation with the canonical token's reported circulating and total supply. Previously these figures could appear out of order on cross-chain deployments; that's fixed.
  • Centralized-exchange listings contribute to the confidence score — broad listings across active centralized exchanges now register as a positive trust signal, with an extra bump when at least one tier-1 exchange is in the mix. Mirrors the listing scrutiny those venues already perform.
  • Concentrated-liquidity pools no longer penalized for being unmeasurable — Uniswap V3 (and forks like PancakeSwap V3 / Aerodrome Slipstream) hold liquidity as individually-owned NFT positions, so an aggregate "% locked" simply doesn't apply the same way it does for V2 pools. When no per-position locker data is available, the report now discloses that as informational instead of scoring it as unlocked liquidity. The position-holder advisory chip stays visible.
  • Anti-bot defenses better distinguished from honeypots — many legitimate ERC-20s ship anti-MEV / anti-sniper logic that can trip an automated sell test on bot-signature wallets. When independent cross-checks agree real users can sell — clean static analysis, broad holder base, active markets, or active centralized-exchange listings with real daily volume — the chip is shown as informational instead of contributing to rug risk. A real honeypot still scores as a hard fail.
  • Structural exit-liquidity mismatch detection — when a token's reported market cap is wildly larger than its actual on-chain DEX liquidity, the report surfaces that mismatch as a primary risk factor. Real exit at the displayed price is constrained or impossible regardless of what the static contract scan returns. (Auto-softened on confirmed bridged tokens and canonical multi-chain secondary deployments — see above.)
  • Detached CEX-volume detection — when centralized-exchange daily volume far exceeds the DEX exit liquidity that would have to settle it, the volume is flagged as likely synthetic or off-chain market-making rather than real trading.
  • Thin holder count on mature tokens — a token that has been live for months at a meaningful reported valuation but still shows only a handful of holders is no longer treated as "established" just because of its age. Distribution that doesn't support the reported market cap now penalizes the score directly.
  • Scope — these changes apply across Solana + all 7 EVM chains (Ethereum, Base, BSC, Arbitrum, Optimism, Polygon, Avalanche). Imposter detection and chain-hop abandonment are cross-chain by design.
2026-05-15 · News desk redesign · richer case pages · stable image loading
  • News desk redesigned/news now uses the same visual language as the rest of the site (typography, panels, accent system) with a clean lead story, side rail, category filter pills with live counts, and a search box. Each story keeps its source-trail and legal-posture pills visible.
  • Case pages rebuilt/news/<story> opens with a compact case header (status, category, case number, judge, venue) followed by reader-friendly panels: short version, why it matters, attack-vector summary, court tracker, verified facts, public record trail, named people and entities, business filings in the trail, named public social handles, on-chain leads, timeline, money / scale, case status, media pack, and citation chain.
  • More desk metrics — the news index now surfaces published stories, source-link total, agencies + courts cited, and an aggregate alleged-loss figure across the live queue.
  • Live breaking strip — a compact breaking ticker rolls the latest case numbers and headlines directly under the masthead.
  • Stable, hot-link-safe image loading — every news image (lead, evidence, gallery) now loads through Analyzer69000's own domain so it survives third-party hot-link protection, never leaks the reader's IP, and shows a loading shimmer instead of a broken-image icon while it's in flight.
  • More frequent desk refresh — the published news queue now refreshes several times per day instead of once.
  • Tighter responsive — both /news and the case pages now hold their layout cleanly down to very narrow viewports (~280-300px wide) for older / split-screen mobile.
  • Editorial constraint — every published item still uses charged / alleged / sued / seized / sanctioned / convicted exactly as the underlying public record supports it. Investigator claims (e.g. independent on-chain analysts) are labeled as such and are kept separate from agency or court findings.
2026-05-14 - Solana P-Token + Token-2022 scanner update
  • P-Token-aware Solana indexing - Solana optimized Token program keeps the classic Tokenkeg... program ID, so existing SPL tokens continue to scan normally. Analyzer treats this as a network-level performance upgrade, not as a token migration or new risk flag.
  • Instruction-log assumptions removed - Solana token parsing is documented around transaction metadata, parsed instructions, and token balance deltas instead of relying on instruction-name log lines that P-Token can omit.
  • Token-2022 controls surfaced - scans now expose extension-level controls such as transfer fees, transfer hooks, permanent delegates, default-frozen accounts, non-transferable mints, confidential transfer, pausable mints, mint close authority, and scaled UI amounts when present.
  • Fair scoring for issuer and bridge tokens - verified wrapped assets, stablecoins, and other canonical issuer-controlled tokens show their controls plainly without scoring standard custody mechanics like unknown memecoin admin keys.
2026-05-13 · Launch-guide share card · verified wrapped-token index
  • Launch-guide OG card refreshed/launch-guide now has a purpose-built 1200x630 share card that matches the scanner's premium report-card style, with accurate title/description metadata and cache-busted unfurls for X, Discord, Telegram, and Slack.
  • Verified wrapped-token registry expanded — canonical wrapped assets are now indexed in-house across Solana, Ethereum, Base, and BSC. Coverage includes WSOL, WETH, WBTC, cbBTC, Wormhole WETH on Solana, Coinbase wrapped assets on Base, and major Binance-Peg assets on BSC. Issuer-controlled mint/burn mechanics are shown as custody controls instead of memecoin rug vectors.
  • Fair scoring for canonical wrapped assets — verified wrapped assets now return VERIFIED_WRAPPED, a blue-chip floor, and a zero headline rug score unless a true hard-fail condition is present. Custody controls stay visible, but launch-bundle, LP-lock, thin-DEX, and holder-concentration heuristics no longer mislabel a real wrapped asset as a rug.
  • Canonical supply market caps — when market registries report a pool-local cap for a verified wrapped asset, the scanner derives the displayed market cap from live price times on-chain float so assets like Solana WBTC do not show misleadingly tiny caps.
2026-05-10 · Wallet and payment UX polish
  • Mobile wallet connection improved — mobile users now get clearer wallet-open actions, better reconnect behavior, and cleaner failure messages across public payment surfaces.
  • Payment previews are clearer — checkout flows now present plain-language wallet prompts and block invalid transactions before users are asked to sign.
  • Share cards refreshed — public service pages now render cleaner 1200x630 cards for X, Discord, Telegram, and Slack.
2026-05-12 · Fair scoring for established markets
  • CEX-aware liquidity scoring — established tokens with meaningful centralized-exchange activity no longer get over-penalized for intentionally thin DEX pools.
  • Holder labels improved — market-maker, exchange, bridge, vesting, and governance-style holders are classified more fairly so concentration warnings better match real holder risk.
2026-05-11 · Bridged-token and governance fairness
  • Bridge-controlled tokens score more fairly — mint/burn controls held by standard bridge or issuer contracts are treated differently from private-wallet control.
  • Governance-aware ownership labels — multisig, timelock, DAO, vesting, and lock-style ownership patterns now render as their actual role rather than generic owner risk.
  • Solana metadata fallback improved — established Solana tokens recover cleaner names and symbols during temporary metadata-provider issues.
Previous changes
  • Cross-chain trending feedGET /api/trending returns live trending tokens across all 8 chains. Shareable /trending + per-chain /trending/<chain>, OG cards at /api/og/trending.
  • Wash-trade detection — every scan reports a NET sniped supply % with a wash-trade flag when intra-wallet rotation dominates the launch window.
  • Fair-launch signal — top-level fair_launch struct combining 5 independent on-chain checks.
  • Deployer verification — multi-signal authenticity check on every deployer wallet.
  • Uniswap V4 support — V2, V3, and V4 swap events all decoded for EVM scans.
  • Team-wallet tracking (EVM) — pre-launch airdrop recipients + their post-launch trade activity surfaced on deployer.team_wallets / team_trades.
  • Official brand logos — 113 CEX + DEX brand marks served locally so the scan page never blocks on a third-party image fetch.
  • Cache-bust OG cards — append &v=<ts> to any OG URL for immutable cache.
  • Compact sub-penny prices$0.0₅616 notation everywhere.

⚡ Quickstart

Copy, paste, done. No API key required.

i Address formats. Solana mints are case-sensitive base58, so a lowercased copy is a different, invalid address. EVM contracts are 0x followed by 40 hex characters (case-insensitive). Pass ?chain= to skip auto-detection. Scans are cached 12h: a recently-scanned token returns instantly, a cold scan takes a few seconds and auto-retries on timeout.

Get a token report

curl https://analyzer69000.com/api/v1/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN

Embed a live scan card on any site

<div data-a69="<token_address>"></div>
<script src="https://analyzer69000.com/embed/scanner.js" async></script>

Per-token social preview card

<meta property="og:image"
  content="https://analyzer69000.com/api/og/token?address=<addr>">

🧪 Interactive playground

Hit a live endpoint from this page. Response format, timing, and cached-or-fresh state shown below. Counts against your IP rate limit.

Ready.

💠 Drop-in widgets

Shadow-DOM isolated — zero CSS conflict in either direction. Auto-mounts every [data-a69] on page load and on DOM mutation, so widgets injected by React / Vue / htmx / Astro "just work" without extra wiring.

Variants
7 widgets
Themes
9 themes
Customize
Brand color
Script size
~18 KB gzip
One <script>, every variant. Drop the tag once in your template — from then on, every new [data-a69] element on the page mounts itself the moment it appears in the DOM. Zero dependencies on your end.

🧬 Installation

<script src="https://analyzer69000.com/embed/scanner.js" async></script>

📦 Variant 1 · Full card (default)

Logo · name · symbol · chain · verdict · animated Safety Score ring · stats · critical-alert banner (honeypot, LP pullable, serial rugger) · copy-address · live indicator. Sizes: sm / md / lg.

<div data-a69="<addr>"></div>

⚡ Variant 2 · Mini card

Compact horizontal row. Perfect for dashboards, watchlists, reply threads.

<div data-a69="<addr>" data-variant="mini"></div>

🎖 Variant 3 · Badge pill

Inline verdict pill — at data-size="md" it shows the token logo + symbol; at sm it shrinks to a dot + verdict for tight inline slots. Ideal for chat, comments, articles, tweets.

Safe?
 vs. 
 · compact:
<div data-a69="<addr>" data-variant="badge"></div>

📊 Variant 4 · Stats strip

Full-width strip with token logo + verdict + any stats you choose. Pair above a trading widget, inside a token page, or at the top of a research post. Add data-show="safety,honeypot,lplock,dev,liq" for a scanner-grade safety strip.

<div data-a69="<addr>" data-variant="stats"></div>

🎚 Variant 5 · Animated gauge upgraded

270° Safety Score dial with gradient fill, count-up animation, token logo header, verdict pill, Tier-1 security chips (honeypot sim · LP locked % · dev rug history · renounced), and live price + 24h change. Drop into a hero, a token page, or a Discord-style bot reply card.

<div data-a69="<addr>" data-variant="gauge"></div>

📺 Variant 6 · Live ticker new

One-line price · 24h change · verdict pill · live pulse. Combine data-refresh="30" for auto-updating tickers. Site footer, news strip, sidebar widget — anywhere you want a living signal.

<div data-a69="<addr>" data-variant="ticker" data-refresh="30"></div>

🫧 Variant 7 · Live holder bubble map

Interactive D3 force-layout of the top 20 holders with token logo in the header. Drag bubbles; pump.fun curves / LPs / burn / dev / retail color-coded. Best single-glance view of supply concentration.

<div data-a69="<addr>" data-variant="bubbles" data-size="lg"></div>

🗂 Variant feature matrix

VariantLogoVerdictScoreStatsSecurity chipsLive priceBest for
cardringcustomalert bannervia data-showlanding pages, reports
mininumericliqwatchlists, sidebars
badgemd/lg onlyrug/100inline prose, chat
statsfullvia data-showvia data-showresearch pages, token pages
gaugedial + count-upprice/changehoneypot · LP · dev · renouncehero, Discord bot reply
tickerprice + 24hfooters, live strips
bubblesholders · top1 · top10 · LP · burnholder analysis

🎨 Theme gallery

Pick one of nine hand-tuned palettes or override any accent with your brand color. Every variant respects the theme.

dark (default)
light
midnight
cyber
terminal
ice
sunset
matrix
holo
<div data-a69="<addr>" data-theme="holo"></div>

🎛 Customize to your brand

Override the accent color, choose border style, pick exactly which stats to show, and enable live refresh.

Custom accent color

<div data-a69="<addr>" data-accent="#00ff9d"></div>

Gradient border + glow

<div data-a69="<addr>" data-border="gradient" data-theme="holo"></div>

Pick your stats

Use data-show with a comma-separated list. Options: rug, blue, safety, price, liq, vol, mc, age, holders, top10, honeypot, tax, lplock, dev.

<div data-a69="<addr>" data-variant="stats" data-show="price,liq,mc,holders"></div>

Safety-first stats strip

For scanner-style usage — surfaces the new Tier-1 security signals (honeypot sim, LP burn/lock %, deployer rug history) alongside price.

<div data-a69="<addr>" data-chain="eth" data-variant="stats" data-show="safety,honeypot,lplock,dev,liq"></div>

Live refresh

Re-pulls the report every N seconds (min 20s). Great for tickers, live dashboards, stream overlays.

<div data-a69="<addr>" data-variant="ticker" data-refresh="30"></div>

🧪 Live embed builder

Tweak options, preview instantly, copy-paste the snippet.

Variant
Theme
Size
Border
Preview

🎛 All attributes

AttributeValuesDefaultDescription
data-a69token addressrequired
data-variantcard · mini · badge · stats · gauge · ticker · bubblescardwidget style
data-themedark · light · midnight · cyber · terminal · ice · sunset · matrix · holodarkcolor palette
data-accenthex like #00ff9doverride theme accent with your brand color
data-sizesm · md · lgmdcontainer max-width
data-bordersolid · gradient · glow · nonesolidborder/glow style
data-radiussm · md · lg · fullmdcorner radius
data-refreshinteger seconds (≥ 20)0auto re-fetch interval; 0 = once
data-animatetrue · falsetrueentrance + count-up animations
data-showrug,blue,safety,price,liq,vol,mc,age,holders,top10,honeypot,tax,lplock,devautopick which stats to render (card / stats). New: honeypot, tax (buy/sell), lplock (LP secured %), dev (rug history).
data-linktrue · falsetruedisable click-through to full report

⚙️ Multiple on one page

Drop as many as you want — the script is idempotent and scans on DOM mutations, so widgets injected via React/Vue/htmx all mount automatically.

🛡 CSP note

The bubbles variant lazy-imports D3 from cdn.jsdelivr.net. If you run a strict CSP, add it to script-src. Every other variant runs standalone with no external deps.

🛰 GET /api/v1/token

GET /api/v1/token/<address> — or — /api/v1/token?address=<address>&chain=auto
ParamTypeRequiredDescription
addressstringyesSolana base58 mint or EVM 0x… contract
chainenumnoauto · solana · eth · base · bsc · arb · op · poly · avax · rh (default auto)

Returns a full report (see schema). Response is cached server-side for 12 hours — re-requesting the same address during that window is a cache hit with a _cached: true field.

⚡ GET /api/v1/quick

GET /api/v1/quick?address=<address>&chain=auto
ParamTypeRequiredDescription
addressstringyesSolana base58 mint or EVM 0x… contract
chainenumnoauto · solana · eth · base · bsc · arb · op · poly · avax · rh (default auto)

A sub-second provisional read for the moment you need an answer now: a verdict + score, live market (price / liquidity / volume / 24h change), and a short list of flags and positives — from the fast market + authority / honeypot surfaces only. Every response carries provisional: true. It is deliberately conservative and never claims a token is safe; the best it returns is CLEAN_ON_SURFACE. For the full forensic verdict (launch bundle, dev-snipe, insider cluster, LP-lock, holder map, serial rugger, imposter / copycat), follow up with /api/v1/token — the links.report and links.full_scan fields point straight to it. Ideal as the first paint in a bot or terminal while the full scan runs.

Rate limit: 60 req/min per IP. Short-cached (~60s). Verdict enum is a subset of the full ladder: LIKELY_RUG · HIGH_RISK · SUSPICIOUS · CAUTION · CLEAN_ON_SURFACE.

📈 GET /api/scan/candles

GET /api/scan/candles?address=<a>&interval=1h&limit=250

OHLCV candle backfill for the token's best-liquidity pool. Data structured for direct use with charting libraries.

ParamTypeDefaultDescription
addressstringToken address (or pass pair instead)
pairstringPool / pair address (skips auto-selection)
chainenumsolanaChain slug
intervalenum1h1m · 5m · 15m · 1h · 4h · 1d
limitint250Candles to return (20–1000)

Fallback chain: requests resolve through three stages so freshly-launched or micro-cap pairs still chart:

  1. Shared cache — per-pool bar store, refreshed nightly for the top-40 tokens by access count.
  2. Indexer — fresh bars appended to cache. Auto-retries with the top-liquidity pool when your pair address isn't indexed (covers Uniswap-V3 32-byte pool IDs, Aerodrome aggregated pools, Base/Arb micro-caps).
  3. On-chain replay — direct Swap-event pagination on Solana + EVM. Serves pump.fun launches and brand-new EVM pairs that no aggregator has indexed yet.

Per-pair soft rate limit: 30 req/min per IP. Cache is trimmed to the newest limit buckets on return, but deeper history can be retrieved by raising limit (max 1000).

🍯 GET /api/scan/honeypot

GET /api/scan/honeypot?address=<0x…>&chain=<c>

EVM-only buy/sell tax + honeypot detection. All 7 EVM chains supported (ETH, BSC, Base, Arbitrum, Optimism, Polygon, Avalanche). Read-only — no wallet, no signing, no on-chain state change. Returns the actual buy/sell tax %, transfer-tax %, owner address (renounced or not), proxy / open-source flags, and a severity band: clean · mild · moderate · heavy · extreme · honeypot · unknown.

ParamTypeRequiredDescription
addressstringyesEVM token contract 0x…
chainenumyeseth · bsc · base · arb · op · poly · avax

Response highlights:

  • severity, is_honeypot, can_buy, can_sell
  • buy_tax_pct, sell_tax_pct, transfer_tax_pct, round_trip_tax_pct
  • max_tx_amount, max_wallet — per-tx / per-wallet caps when enforced by the contract
  • owner, owner_renounced, is_proxy, open_source
  • risk_level, risk_flags[] — ranked warning list
  • holders, holders_top_10_pct, token_symbol, native_symbol
  • simulation_amount_native, router, pair_address — for the user-facing footer ("Simulation: 0.1 BNB round-trip via 0x10ED…")
  • source — opaque verification-path identifier (treated as a string by callers; severity bands are normalized so UI labels match regardless of value).

Cross-check: when independent verification paths disagree, the disagreement surfaces as a flag in risk_flags[] instead of silently overriding either signal — so the caller can decide based on full evidence.

Rate limit: 20 req/min per IP. Cache: 2 min response cache + SWR. Pair this with /api/scan/impact for the post-tax slippage view at concrete trade sizes.

📡 GET /api/scan/recent

GET /api/scan/recent?limit=30

Last-N tokens scanned across all users, plus 30-day roll-up: unique tokens, total scans, rugs caught, clean scans.

🖼 GET /api/og/token

GET /api/og/token?address=<addr>&v=<fetched_at_unix>

Returns a 1200×630 PNG social card (SVG available at ?format=svg) with the token's name, Safety Score dial, verdict banner, live market stats, and security flags (honeypot sim, LP lock, renounce, dev rug history).

Pass v=<unix_timestamp> (typically the scan's fetched_at) to get cache-immutable previews — the URL itself changes on every refresh, so CDN + Twitter/Discord unfurls stay in sync with the latest stats. Legacy unversioned URLs are cached only 60s.

Mirror endpoints:

  • /api/og/bundle — bundle-intel card. Severity · sniped % · wallet count · held/sold split. Auto-detects "BUNDLE RESOLVED" when ≥80% of the launch bag has dumped.
  • /api/og/boost-token — premium 1200×630 share card for any boosted token. Pulls live price, organic-score progress bar, forensic verdict pill, sparkline, tier badge. Bind it to a parent page by appending ?card=boost to the share URL: /check/<addr>?card=boost swaps the page's og:image to this endpoint so X / Discord / Telegram unfurl as the boost card instead of the standard scan card.
  • /api/og/trending — top-6 cross-chain trending grid with prices + 24h moves. Per-chain filter via ?chain=.
  • /api/og/boost — generic boost-page social card (3 tiers + refund policy line).
  • /api/og/page?p=<preset> — branded social cards for non-token pages (home, docs, comments).

💬 GET /api/v1/chatter

GET /api/v1/chatter?addr=<address> — optional — &sym=<TICKER>

Recent social chatter (X / Twitter posts) mentioning a token, drawn from a curated set of established crypto accounts. Author, follower count, verified flag, engagement, and a link to each post — so you can see who is talking about a contract and how loudly. Served from a warm internal index and CDN-cached, so it's a single fast read that never rate-limits on your traffic. Chatter is a signal, not safety — always scan the token itself.

Query params:

  • addr — required; the token contract address (Solana mint or 0x… EVM).
  • sym — optional ticker fallback (e.g. WIF) used when a post named the ticker without a contract. Lower-confidence than an address match.

Response:

{
  "ok": true,
  "count": 3,
  "symbol": "POMME",
  "updatedAt": "2026-07-21T14:21:07.973Z",
  "tweets": [
    {
      "handle":       "someCaller",
      "followers":    128400,
      "verified":     true,
      "text":         "$POMME looking strong here…",
      "url":          "https://x.com/someCaller/status/…",
      "createdAt":    "Mon Jul 21 14:02:11 +0000 2026",
      "replyCount":   42, "likeCount": 613, "retweetCount": 58
    }
    // …newest first, up to 30
  ]
}

Notes: empty tweets just means no tracked account has mentioned that contract yet (most obscure tokens have none). updatedAt reflects index freshness.

📦 GET /api/v1/bundle

GET /api/v1/bundle/<address> — or — /api/v1/bundle?address=<addr>&chain=auto

Compact bundle-intel payload — same data the scanner UI renders, without the full token report. Includes: severity · pct_60s · pct_10m · pct_5s_max · launch provenance (launch_block, launch_ts, source) · unique_buyers_60s/10m · swap_count · walker_error / walker_failed / predates_scan flags · sample wallets · full hold_analysis (retail vs pool/authority, still-holding / sold_all / partial / reaccumulated counts + USD values) · per-wallet rows (capped at 20) with status labels · mev_bots_detected · wash_ratio_60s/10m · redemption flags (bundle_resolved, adoption_organic).

Three no-bundle states: walker_failed: true (RPC issue on a fresh token — re-scan in ~10 min), predates_scan: true (token genuinely too old — current-state metrics still apply), or neither (organic launch with no bundle pattern). Each gets a distinct human-readable note. Cap: 10 sample wallets + 20 hold-analysis rows per response. Full per-wallet lists live on /api/v1/token.

curl -s 'https://analyzer69000.com/api/v1/bundle/<addr>' | jq '.hold_analysis'

🪪 GET /api/v1/token?summary=1

GET /api/v1/token/<address>?summary=1

1 KB agent-friendly response - verdict, rug_score, blue_chip_score, organic_score + organic_label, top risks, top positives, market snapshot, liquidity_lock, holder summary, deployer summary, bundle, redemption flags, website + socials_verified, launchpad, and Solana token-program / Token-2022 extension summary. Stable keys across schema bumps. Ideal for Claude/OpenAI/MCP tool-use. See Agents & LLMs for the full tool snippet.

Solana token programs

Analyzer separates Solana token-program mechanics from project risk. P-Token is a network-level replacement of the classic SPL Token implementation at the same Tokenkeg... program ID; it does not mean the mint migrated, relaunched, or became safer/riskier by itself. Token-2022 remains the separate extension-capable program at Tokenz..., and those extensions can materially change what holders can do.

i Indexer note. Solana token parsing should not depend on human-readable instruction logs. P-Token can omit instruction-name logs, and it adds batch, unwrap_lamports, and withdraw_excess_lamports. Use parsed instructions, account owners, token balance deltas, and current IDLs where available.
SurfaceWhat the API exposesHow to interpret it
Classic SPL / P-Tokentoken.token_program, token.token_program_id, token.standardSame classic program address. Treat P-Token as performance/indexing context, not a token-level red flag.
Token-2022token.token_extensions, token.token_extension_summary, security.solana_token_extensionsExtension controls are shown and scored when they affect sellability, transferability, fees, freezing, delegate power, or public holder visibility.
Verified issuers / bridgesVERIFIED_STABLECOIN, VERIFIED_WRAPPED, canonical registry metadataCustody controls remain visible, but normal issuer or bridge mechanics are not scored like unknown private-wallet memecoin controls.

Common Token-2022 controls include transfer fees, transfer hooks, permanent delegates, default frozen account state, non-transferable mints, confidential transfer, confidential transfer fees, pausable mints, mint close authority, metadata pointers, group pointers, and scaled UI amounts. Some are normal for regulated or issuer-controlled assets; on unknown tradable tokens, they can be material risk signals.

🛡 Verified Boosts

Paid trending slots that have to pass our forensic scan before they go live. Three tiers, priced in dollars and payable in whichever asset you hold. Agent-friendly via x402 — no API key, no OAuth, no SDK. If your token's organic score collapses mid-window, half your money comes back.

TierPlacementDurationPriceGate
FeaturedTop of cross-chain trending24h$79Passes organic-quality gate
TrendingPinned in per-chain trending12h$35Passes organic-quality gate
SpotlightDedicated card on /check/<addr>6h$15LP secured

Prices are USD-anchored. Paying in a volatile asset converts at the live rate at order time, so a SOL payer and a stablecoin payer are charged the same in real terms. Call /api/boost/prices for the current table.

Chains

Any chain we can grade can be boosted — Solana, Ethereum, Base, BNB Chain, Arbitrum, Optimism, Polygon, Avalanche and Robinhood Chain. A boost is gated on a forensic scan, so a chain we cannot yet scan is never offered. The chain a token trades on is independent of the chain you pay from: you can buy a slot for an Ethereum token and pay in SOL, or vice versa. GET /api/boost/x402 lists token_chains and the currently-open pay_rails.

Solana payment rails are live now. ETH/EVM rails are rolling out — a rail only appears in pay_rails once it is genuinely accepting payments, so you never get quoted a route that cannot settle.

Endpoints

GET/api/boost/x402 — discovery: tiers, prices, open payment rails, and the step-by-step settlement flow
GET/api/boost/prices — live per-tier price table
GET/api/boost/eligibility?address=&chain=&tier= — precheck before paying. Also returns a token summary (symbol, name, price, market cap, liquidity, 24h volume, holders, age, LP state, verdict) so you can confirm you have the right address
POST/api/boost/intent — open a single-use order (server pins receiver, amount, tier and buyer)
POST/api/boost/build-tx — server-built transaction ready for your wallet to sign
POST/api/boost/buy — settle. No payment attached → 402 with a payable order
GET/api/boost/poll?intent_id= — we find your payment for you; no tx hash to report
GET/api/boost/active?chain=&tier= — currently-live slots
GET/api/boost/history?limit=50&chain= — public slot history + totals
GET/api/og/boost-token?address=&chain=&tier= — 1200×630 share card for any boosted token

Flow

  1. /api/boost/eligibility — confirm the token passes the tier gate before spending anything.
  2. /api/boost/intent — open an order with token, tier, currency, pay chain and your wallet. You get back an intent_id and an exact amount.
  3. Pay it. Either let /api/boost/build-tx hand your wallet a ready-made transaction, or send the transfer yourself.
  4. /api/boost/buy with {intent_id, tx_signature} — or just poll /api/boost/poll and we will find the payment. We verify the sender, recipient, asset, amount and age on-chain, then re-run the gate.
  5. Pass → the slot is live. Fail after paying → full refund. Quality collapse mid-window → 50% back.

Refunds

Refunds are paid on-chain, back to the wallet the payment came from. There is no ticket to open and no address to supply — the destination is taken from the transaction you already signed, so it cannot be redirected.

SituationYou get backSlot
Token fails the gate before you payNothing is charged at allNever opens
Payment lands but the gate fails on re-check100%Never goes live
Token stops passing the scan mid-window50%Pauses immediately
Slot runs its full windowNothingRan as sold

The mid-window trigger is our quality gate, not price action. A token whose price falls but still clears the scan keeps its slot; a token that stops clearing the scan loses it, whatever the price is doing. Refund transactions appear on /boosted alongside the slot they belong to.

Refunds on the Solana rail are issued automatically. EVM refunds are processed manually while those payment rails are still rolling out.

The amount is exact. Every order carries a small unique offset in its trailing digits — that is what ties your payment to your order and to nobody else's. Rounding it, or adding a tip, makes it unmatchable.

Paying from a phone

Open an order and you also get a Solana Pay URL. Render it as a QR or open it directly on mobile, approve in any wallet app, and poll /api/boost/poll?intent_id=…. There is no transaction hash to copy back and no browser extension involved.

Stacking + extension

Buying any tier on a token that already has an active slot of the same tier extends the existing slot cumulatively. Buying a higher tier adds a new active slot alongside (a token can hold all 3 tiers concurrently). Only the original buyer can update tagline/link/accent; community-funded extensions add time without re-branding.

If verification stalls

Confirmation can lag. If it does, /boost remembers your open payment for 24 hours and offers a one-click re-verify next visit — you never pay twice. Settlement is idempotent on the transaction itself: replaying the same payment returns the same slot rather than charging again.

Custom fields (all optional, free during launch)

  • tagline — up to 60 chars. Server-sanitized (zero-width + control chars stripped).
  • link_url — https only, host must be x.com, t.me, discord.gg, discord.com, or subdomain thereof.
  • accent_color — strict #RRGGBB regex.
  • buyer_label — up to 40 chars display-only.

Agent quickstart (x402)

Two round-trips and a payment. No key to provision, nothing to sign up for.

# 1 · ask for an order. Returns 402 with a payable quote.
ORDER=$(curl -s -X POST https://analyzer69000.com/api/boost/buy \
  -H 'content-type: application/json' \
  -d '{"address":"<mint>","chain":"solana","tier":"spotlight",
       "pay_chain":"solana","currency":"sol","buyer_wallet":"<your-wallet>"}')

INTENT=$(echo "$ORDER" | jq -r '.accepts[0].extra.intent_id')
AMOUNT=$(echo "$ORDER" | jq -r '.accepts[0].extra.exact_amount')   # base units, EXACT
PAYTO=$( echo "$ORDER" | jq -r '.accepts[0].payTo')

# 2 · send exactly $AMOUNT to $PAYTO from <your-wallet>, keep the signature.
#     Attach .accepts[0].extra.reference as a read-only account if your
#     tooling supports it — otherwise the exact amount is the binding.

# 3 · settle. 200 = live slot, plus an X-PAYMENT-RESPONSE receipt header.
PAYLOAD=$(printf '{"intent_id":"%s","signature":"%s"}' "$INTENT" "<tx-sig>" | base64 -w0)
curl -s -X POST https://analyzer69000.com/api/boost/buy -H "X-PAYMENT: $PAYLOAD"

# …or skip step 3 entirely and let us find the payment:
curl -s "https://analyzer69000.com/api/boost/poll?intent_id=$INTENT"

Discovery only, no commitment: curl -s https://analyzer69000.com/api/boost/x402 | jq '.flow, .pay_rails'

Buy a boost → · Public history →

💬 Trench Chat

An anonymous, per-token chat that lives on every scan. A reader can verify a wallet with one free signature (no transaction) to earn on-chain badges that sit next to every message they send: DEV, SNIPER, BUNDLE, WHALE, and HOLDER (with rank and supply share). The room is keyed to the contract address, so every app that embeds a token surfaces the same conversation. Sentiment is weighted by verified holders, with live message velocity. Verified wallets can also tip each other on-chain (the room token, SOL, or USDC) and see their live holding of the token next to their badge.

Embed in one line

Drop the script once, then place a <trench-chat> tag per token. Sandboxed iframe, themeable, anonymous by default.

<script src="https://analyzer69000.com/embed.js" async></script>
<trench-chat chain="solana" token="<mint>" symbol="JUP" height="600"></trench-chat>

Attributes: chain (solana, eth, bsc, base, arb, op, poly, avax, rh), token (required), symbol, theme (dark / light), height, demo="1" for a sandboxed example conversation.

Read API

Pull a token's live conversation, sentiment, and verified-holder signal into your own app. CORS-open, no key required.

GET/api/v1/chat/pulse?chain=&token= — live: watchers online, message velocity, sentiment (overall + holder-weighted)
GET/api/v1/chat/messages?chain=&token=&limit= — recent messages with verified on-chain badges + reply context
GET/api/v1/chat/stats?chain=&token= — unique chatters, verified ratio, badge counts, top reactions
GET/api/v1/chat/tips?chain=&token=&limit= — recent on-chain tips (truncated wallets + amount + public tx signature) and a per-room tip leaderboard (top tippers + receivers)

On-chain tipping

Verified wallets can tip a message author (or any address in the room) directly on-chain, in the room's own token, SOL, or USDC. Tips are non-custodial: the transfer is signed by the sender's own wallet, and the recipient is resolved server-side from the message you tap, so no one pastes a wallet by hand. A gasless option covers the network fee for holders who have the token but no SOL. Tipping is built into the embed, so dropping the chat in gives your users tipping with no extra wiring.

GET/api/chat/tip/config — read-only tip capabilities for a client: whether tipping + the gasless path are live, the fee rate, and amount hints. CORS-open, no key.

The tip dialog shows the exact amount and fee before you sign. SOL and USDC tips carry a small, capped fee; tips in the room's own token are free on the standard (self-paid-gas) path. Tip activity surfaces inline in the chat and on a per-room leaderboard.

Live wallet holdings

Once a reader verifies a wallet, the chat shows their live holding of the room token (supply share + balance) next to their badge, plus their broader token portfolio on tap. It is read-only and per-session, and it is what drives the holder badges and the holder-weighted sentiment signal. Badges and holdings refresh as on-chain balances change.

React to chat activity (events)

The embed talks back. Listen for events on the <trench-chat> element and wire chat activity straight into your own UI: pop a toast when a tip lands, light up a counter on a new message, gate a feature on a verified wallet, react to sentiment swings. Every payload is public-only (truncated wallets, never a full address or secret).

const el = document.querySelector("trench-chat");
el.addEventListener("trench-chat:tip", e => {
  const t = e.detail.detail;            // { from, to, amount, symbol, gasless, signature }
  toast(`${t.from} tipped ${t.to} ${t.amount} ${t.symbol}`);
});
el.addEventListener("trench-chat:verified", e => unlock(e.detail.detail.wallet));
el.addEventListener("trench-chat:message",  e => bumpCounter());
el.addEventListener("trench-chat:sentiment",e => setBull(e.detail.detail.bull));

Event types: ready · message · tip · verified · sentiment. You can also drive the embed: el.open() focuses the chat, and el.openTip({ to, amount, asset }) opens the tip flow pre-filled. Commands only open UI, so the user always connects and signs in their own wallet.

Drop in a tip button

Want tipping without the whole chat? One tag renders a branded button that opens the tip flow (in the room token, SOL, or USDC) in a modal. Perfect for a creator page, a token profile, or a leaderboard. Pre-fill a recipient and amount, or leave it open for the user to pick someone in the room.

<script src="https://analyzer69000.com/embed.js" async></script>
<trench-tip chain="solana" token="<mint>" symbol="JUP"
            to="<wallet>" amount="1000" asset="token"></trench-tip>

All extra attributes are optional: to (recipient wallet), amount, asset (token / sol / usdc), label (button text). The same deep link works as a URL too: /embed?chain=&token=&tip=1&to=&amount=&asset=.

Full docs + live demo →

🚀 Launchpad detection

Every scan runs a multi-stage launchpad classifier. The token.launchpad field (null if none detected) reports the source platform and confidence so agents and UIs can frame the token in the right context (fair-launch meme vs tokenized venture round vs deterministic burn).

KeyTypeDescription
idstringCanonical platform slug — pump_fun · letsbonk · moonshot · believe · virtuals · jupiter_studio · daos_fun · raydium_launchpad · streamflow · meteora_m3m3 · four_meme · clanker · flaunch.
namestringHuman-readable display name.
urlstringOfficial launchpad homepage.
confidenceenumprimary (deterministic on-chain proof — mint suffix, program id, known creator) · inferred (pool listed on migration-burn DEX with matching base token) · hint (website / metadata / description match).
sourceenumWhere the match came from: mint_suffix · onchain · dex · website · metadata.
evidencestringThe specific signal that matched (program id, DEX name, matched phrase).
logo_svgstringInline SVG mark shipped directly in the payload so UIs render instantly with no remote image fetch.

confidence: 'primary' means the scan proved the launchpad deterministically (e.g. Solana mints ending in pump, bonk). inferred means a pair hosted on a migration-burn DEX where the factory deterministically burns LP (pumpswap, bonkswap, moonshot-swap). hint is website/metadata keyword matching — treat it as a weak signal, never a verdict.

🤖 For agents & LLMs

This API is built to be called from agents. The full token report is big (∼70 KB JSON) which is too much for a single tool-call round trip in a constrained context window. We ship two dedicated affordances so your agent can reason about a token in <1 KB per call, with every number still traceable back to on-chain facts.

No MCP-server token, no OAuth flow, no per-agent key: the same free public tier serves agents. Abuse protection lives at the API — 30 req/min · 300 req/hour per IP + server-side 12h cache. Agents that cache their own tool results against address + chain won't notice the limits.

🪪 Compact agent response — ?summary=1

Every /api/v1/token call accepts ?summary=1, which returns a distilled payload shaped for LLM tool use: verdict, numeric scores, top risks, top positives, market snapshot, launchpad, LP-lock verdict, deployer headline, and Solana token-program / Token-2022 extension summary when present. Stable keys across schema bumps - so a tool definition you ship once keeps working when we improve the engine.

curl -s 'https://analyzer69000.com/api/v1/token/JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN?summary=1' | jq

Sample shape (representative summary response — schema_version: 100):

{
  "address": "JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN",
  "chain": "solana",
  "token": {
    "name": "Jupiter", "symbol": "JUP",
    "age_hours": 19890.93, "launchpad": null,
    "mint_renounced": true, "freeze_renounced": true,
    "token_program": "spl_token", "token_extensions": null
  },
  "verdict": "BLUE_CHIP",
  "rug_score": 0,
  "blue_chip_score": 100,
  "organic_score": 81,
  "organic_label": "organic",
  "top_risks": [],
  "top_positives": [
    {"text": "Mint authority renounced ✓", "weight": 10},
    {"text": "Freeze authority renounced ✓", "weight": 10},
    {"text": "Token > 180 days old", "weight": 30},
    {"text": "Liquidity > $1M", "weight": 20},
    {"text": "Market cap > $10M", "weight": 20},
    {"text": "Listed on 3 DEXes", "weight": 5}
  ],
  "redemption": { "bundle_resolved": false, "adoption_organic": true },
  "market": {
    "price_usd": 0.2026,
    "market_cap_usd": 647915635,
    "fdv_usd": 1390329375,
    "liquidity_usd": 2439527.58,
    "volume_24h_usd": 4745625.73,
    "change_24h_pct": -0.82,
    "buys_24h": 32980, "sells_24h": 40591,
    "dex_count": 3, "chain_count": 1,
    "cex_exchange_count": 61,
    "cex_market_count": 84,
    "cex_volume_24h_usd": 60412023.77,
    "cex_exchanges": [
      { "name": "Binance", "markets": 4, "volume_24h_usd": 9990466 },
      { "name": "KuCoin", "markets": 2, "volume_24h_usd": 5515486 },
      ... 59 more exchanges
    ]
  },
  "liquidity_lock": { "verdict": null, "secured_pct": null, "burned_pct": null, "locked_pct": null },
  "holders": {
    "top_10_pct": 68.32, "adjusted_top10_pct": 68.32,
    "holder_count": 833460,
    "burn_pct": 0, "lp_pct": 0, "cex_pct": 2.19
  },
  "deployer": { "address": null, "dev_snipe_pct": 0, "serial_rugger": null },
  "bundle": null,
  "socials_verified": 5,
  "website": { "url": "https://jup.ag", "team_count": 0 },
  "schema_version": 100,
  "fetched_at": "2026-05-07T03:18:35.195Z",
  "_summary": true,
  "_cached": true
}

🔧 Tool-use snippet (Claude / OpenAI)

Drop this tool definition straight into Anthropic or OpenAI tool-calling. The agent can now scan any Solana or EVM token on demand, and the response fits in a single message body.

{
  "name": "scan_token",
  "description": "Return a safety + market summary for a token contract. Works on Solana, Ethereum, Base, BSC, Arbitrum, Optimism, Polygon, and Avalanche. Verdict is one of: VERIFIED_STABLECOIN, VERIFIED_WRAPPED, VERIFIED_LST, BLUE_CHIP, ESTABLISHED, CLEAN_ON_SURFACE, CAUTION, SUSPICIOUS, HIGH_RISK, LIKELY_RUG.",
  "input_schema": {
    "type": "object",
    "properties": {
      "address": {"type": "string", "description": "Solana mint or EVM 0x contract"},
      "chain": {"type": "string", "enum": ["auto","solana","eth","base","bsc","arb","op","poly","avax","rh"]}
    },
    "required": ["address"]
  }
}

Tool handler (Node.js, any runtime with fetch):

async function scan_token({ address, chain = 'auto' }) {
  // Validate upfront — the API does too, but early rejection keeps
  // malformed tool-call traffic off the rate-limit window.
  if (!/^[1-9A-HJ-NP-Za-km-z]{32,44}$|^0x[a-fA-F0-9]{40}$/.test(address)) {
    return { error: 'invalid_address' };
  }
  const url = `https://analyzer69000.com/api/v1/token/${encodeURIComponent(address)}?chain=${encodeURIComponent(chain)}&summary=1`;
  const r = await fetch(url, { headers: { Accept: 'application/json' } });
  if (!r.ok) return { error: `http_${r.status}` };
  return await r.json();
}

🔌 MCP server (self-hosted)

For MCP-based agent workflows, run a local stdio wrapper that calls the public summary endpoint:

// a69-mcp.mjs — MCP stdio server exposing Analyzer69000 as a tool.
// Run: node a69-mcp.mjs  (stdio transport, drop into any MCP host)
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new Server(
  { name: 'analyzer69000', version: '1.0.0' },
  { capabilities: { tools: {} } },
);

server.setRequestHandler('tools/list', async () => ({
  tools: [{
    name: 'scan_token',
    description: 'Safety + market summary for a token contract (Solana / EVM).',
    inputSchema: {
      type: 'object', required: ['address'],
      properties: {
        address: { type: 'string' },
        chain:   { type: 'string', enum: ['auto','solana','eth','base','bsc','arb','op','poly','avax','rh'] },
      },
    },
  }],
}));

server.setRequestHandler('tools/call', async (req) => {
  const { address, chain = 'auto' } = req.params.arguments || {};
  if (!/^[1-9A-HJ-NP-Za-km-z]{32,44}$|^0x[a-fA-F0-9]{40}$/.test(address)) {
    return { content: [{ type: 'text', text: 'invalid_address' }], isError: true };
  }
  const r = await fetch(
    `https://analyzer69000.com/api/v1/token/${address}?chain=${chain}&summary=1`,
    { headers: { Accept: 'application/json' } },
  );
  const json = await r.json();
  return { content: [{ type: 'text', text: JSON.stringify(json, null, 2) }] };
});

await server.connect(new StdioServerTransport());
Tip. Keep the wrapper local to your agent runtime and validate token addresses before calling the public API.

🧬 Response schema

Every report is the same shape across chains. Click to expand fields:

top-level root— identifiers, scores, version
address string token mint / contract — echoed from request
chain enum solana · eth · base · bsc · arb · op · poly · avax · rh
verdict enum top-level verdict — BLUE_CHIP · ESTABLISHED · CLEAN_ON_SURFACE · CAUTION · SUSPICIOUS · HIGH_RISK · LIKELY_RUG
rug_score 0-100 higher = more risk
blue_chip_score 0-100 higher = more established
organic_score 0-100 composite launch cleanliness + adoption metric. 75+ = organic, 55+ = mostly organic, 35+ = mixed, 15+ = coordinated, below = manipulated
organic_label enum organic · mostly_organic · mixed · coordinated · manipulated
top_risks array {text, weight} — top risk factors contributing to rug_score
top_positives array {text, weight} — positive factors contributing to blue_chip_score
redemption object {bundle_resolved, adoption_organic} — whether initial risk signals have been redeemed over time
socials_verified int count of verified social links (X, Telegram, Discord, website, etc.)
website object {url, team_count, cross_verified[]} — project website and team verification
schema_version int incremented when the report shape changes — clients can use this to invalidate their own caches
fetched_at iso8601 when this report was computed
_cached boolean true if served from response cache
_summary boolean true when ?summary=1 was passed — identifies the compact agent response
_docs string link to the docs page — convenience for agent tool-use flows
corroboration object?— independent cross-checks; where outside sources agree or disagree with the scan
source_count int how many independent sources returned data for this token
signals array {kind, ok, level, detail} — human-readable agreements and disagreements. level is good · warn · info
cross_checks object independent figures, surfaced next to the scan's own numbers
price_oracle_confirmed boolean? true when the scan price matches an independent price oracle within tolerance
price_divergence_pct number? percentage difference between the scan price and the independent oracle
identity_confirmed boolean? token name/symbol lines up across independent sources (catches cross-chain address collisions)
authorities_confirmed boolean? mint/freeze authority status agrees with an independent audit
verified_listing boolean? token appears on a major aggregator's verified token list
independent_organic_score 0-100? an outside organic-activity score, for comparison with organic_score
independent_holder_count int?
independent_top_holders_pct number?
independent_lp_locked_pct number?
independent_price_usd number?
Corroboration is enrichment: when no outside source returns data the field is absent, and a disagreement is surfaced as a warning rather than silently changing the score.
copycat object?— same-chain fake/clone detection; points to the genuine token
verdict enum copycat (a verified original of the same name exists at another address) · likely_copycat (a much older, much larger same-name token exists) · symbol_collision (informational — a verified token shares the symbol but not the name) · original (this is the most established token under the name)
confidence enum? high · medium · low
original object? the genuine token — address, symbol, holders, verified. Present when a more-established same-name token was found, so you can link users to the real contract
A copycat verdict contributes a Tier-1 rug weight and the reason appears in top_risks. Absent when the token has no same-name peers.
token object— metadata, authorities, age, launchpad
name string
symbol string
decimals int
supply_ui number
image url resolved through a multi-source cascade so fresh EVM tokens that no single provider has indexed still render a logo
description string ≤ 800 chars
token_program enum? spl_token - token_2022 for Solana mints
token_program_id string? Solana token program owner, when known
token_extensions array? Token-2022 extension names and normalized controls, when present
token_extension_summary object? compact extension flags for agents and widgets
platform string pump.fun · SPL · ERC-20 · …
launchpad object detected launchpad — see Launchpad detection for the 13 supported platforms
id · name · url · confidence · source · evidence · logo_svg
mint_renounced boolean
freeze_renounced boolean
launch_utc iso8601
launch_ts unix_seconds launch timestamp — populated from the most authoritative source available (see age_source)
age_hours number
age_source enum? deep_walk_verified · earliest_pair_creation · evm_creation_walk · pair_created_at_fallback — provenance of launch_ts. deep_walk_verified means the walker traversed back to the actual launch tx; evm_creation_walk means the EVM walker reached pair-creation block; pair_created_at_fallback means the walker errored and we used a third-party aggregator's pair-created timestamp as a best-effort estimate
market object— price, liquidity, volume, per-DEX + CEX listings + per-chain breakdowns
cex_listings object centralized-exchange coverage
exchange_count · total_cex_markets · total_cex_volume_24h_usd · recently_listed_count
exchanges array {name, key, logo_svg (inline SVG), brand_color, brand_grad, initials, market_count, total_volume_24h_usd, trust (green|yellow|red), active, first_seen_at, last_trade_at, markets[]}
Trade URLs are domain-validated server-side — if trade_url is present on a market row, we've verified it resolves to the exchange's canonical domain. null means no verified URL for that pair.
markets[] object {base, target, pair_label, volume_24h_usd, trade_url, trust, last_trade_at, is_anomaly, is_stale}
price_usd number
total_market_cap number
total_liquidity_usd number
total_volume_24h number
buy_sell_ratio_24h number 0–1
dex_count int
chain_count int
all_pairs array
dex_breakdown array per-venue liquidity + volume share
chain_breakdown array
buys_24h int buy transactions in the last 24 hours
sells_24h int sell transactions in the last 24 hours
change_24h_pct number 24-hour price change percentage
market_cap_usd number circulating market cap in USD
market_cap_source enum provenance of the market cap figure: verified DEX pool, canonical on-chain supply, external market registry, or estimated
fdv_usd number fully diluted valuation
cex_exchange_count int number of centralized exchanges listing this token
cex_market_count int total trading pairs across all CEXes
cex_volume_24h_usd number aggregate 24h CEX volume
cex_active_count int CEXes with active trading in the last 24h
cex_exchanges array per-exchange breakdown: {name, markets, volume_24h_usd, trust, active}
socials object
deployer object— dev address + trade/movement trail
address · create_tx · verified_via how the deployer was identified
dev_snipe_tokens · dev_snipe_pct initial buy at launch
current_tokens · current_pct live balance
funded_by · cex_origin first-funding source
silent_accumulation_tokens · silent_accumulation_pct tokens in/out via non-trade paths
silent_accumulation_note string plain-english explanation
serial_rugger object prior deployments classified
total_deployments · rugged_count · active_count · dormant_count
severity enum clean · suspicious · moderate · heavy · extreme
sample array per-deployment {address, symbol, verdict, liq, vol, age_days}
trade_history object full buy/sell timeline + non-trade movements since launch
actions array {type: 'buy'|'sell', tokens, notional_usd, price_usd, quote_symbol, tx, timestamp}
movements array {kind: 'fee_claim'|'transfer_in'|'transfer_out', direction, tokens, counterparty, tx, timestamp}
totals object buys/sells counts · tokens_bought/sold · spent_usd/received_usd · realized_pnl_usd · fee_claim_count · transfer_in/out counts + tokens · non_trade_net
security object— contract safety (EVM)
solana_token_extensions object? Token-2022 extension analysis: flags, risk band, fee/hook/delegate/freeze/transferability controls, and user-facing notes
ownership object {has_owner_fn, owner, renounced}
proxy object {is_proxy, implementation, admin, beacon} — EIP-1967 slots
verified object {verified, name, compiler, findings[]} — source verification + dangerous-function scan
honeypot object sell-test verdict + supporting signals
verdict enum honeypot · anti_bot_suspected · high_tax · tax_warning · clean · unknown
buy_tax · sell_tax · transfer_tax pct
flags array owner_can_change_balances, hidden_owner, supply_mintable, transfers_pausable, tax_modifiable, blacklist_enabled, …
disagreement enum? anti_bot_suspected · oracles_disagree · null — populated when independent verification paths conflict
liquidity_lock object— LP burn + lock verification (both chains)
verdict enum fully_secured · mostly_secured · partially_secured · unlocked · v3_pool · v4_pool
pool_type enum? v2 · v3 · v4 · unknown — when set, indicates which Uniswap version the pool uses
burned_pct · locked_pct · secured_pct pct
holders array {name, address, kind (burn|locker), pct}
lp_token/lp_mint string address of the LP token (V2 only — V3/V4 use NFT positions)
note string? human-readable explanation when verdict is v3_pool or v4_pool — points readers to the position-NFT holder as the security signal
price_action object— "is this a rug right now?" derived from price + LP + bundle state
label enum rug_pulled · lp_drained · bundle_dump · mint_inflation · notable_drawdown · notable_runup · pumping · normal_volatility · stable
severity enum info · caution · danger
verdict string one-line plain-english explanation
evidence array bullet list of supporting facts (LP status, % sold, 24h price)
inputs object {change_24h_pct, liquidity_usd, pct_sold, lp_secured} — the raw values the label was derived from
bundle object— launch bundle cluster + hold analysis + wash detection
detected · reliable boolean
severity enum clean · mild · moderate · heavy · extreme · unknown
source enum? bonding_curve · pair · mint · evm_swap_logs — which on-chain primitive the walker scanned
launch_block int? block number of the launch tx (EVM) or first observed swap
launch_ts unix_seconds? timestamp of the launch block — useful for synchronizing with off-chain feeds
unique_buyers_60s · unique_buyers_10m int? EOA count in each launch window (V2/V3/V4)
swap_count int? total swap events analyzed in the launch window
walker_error enum? when the launch-window walker hit a known failure: no_logs (RPC returned nothing in window) · pair_created_block_unknown (block-resolver failed) · no_swaps_decoded (logs found but undecodable, eg custom V4 hook) · v4_pool_manager_unknown_chain
walker_failed boolean true when walker errored on a fresh token. Distinct from predates_scan — caller should retry in ~10 min
predates_scan boolean true only when the token is genuinely too old (>14d EVM, varies on Solana) for the walker's RPC budget. Bundle metrics genuinely unreachable; current-state metrics still apply
launch_source object? walk provenance — {walked_to_oldest, pump_api_used, pages_walked, total_sigs, source, launch_block} — lets callers verify the walker actually reached launch
mev_bots_detected array addresses of known sandwich/priority-fee bots active in the launch window (EVM only)
pct_60s · pct_10m pct NET % of supply sniped (buys − sells per wallet, positive deltas only, capped at 100)
pct_5s_max pct largest 5-second cluster
wash_ratio_60s · wash_ratio_10m 0-1 (gross − net) / gross — fraction of launch volume that was intra-wallet rotation
gross_tokens_60s · gross_tokens_10m number raw cumulative inbound — pre-dedup for wash-trade calc
wash_capped boolean true when raw gross-buy sum mathematically exceeded 100% (impossible net holdings)
wash_note string human-readable explanation when wash trading is significant or wash_capped
wallets_in_largest_bundle int in a single 5s window
sample_wallets array addresses in the tightest cluster
launch_type enum organic · coordinated · team
hold_analysis object live-RPC balance verification of every bundle wallet (used to power the inspector + holdings tracker on /check)
scanned_wallets · retail_wallets · pool_authority_wallets retail = unique humans; pool/authority filtered out so AMM vault outliers don't poison the headline
still_holding · sold_all · sold_partial · reaccumulated int cohort sizes
pct_still_held · pct_sold 0–1
tokens_at_launch · tokens_still_held number
usd_still_held · usd_dumped number priced at scan-time best_pair (basis declared in price_basis)
price_basis object {source, price_usd}
rpc_calls · budget_used_ms int scan transparency — how many on-chain balance checks fired and how long the scan took
wallets array per-wallet rows:
wallet · launched_with_tokens · launched_with_usd
current_tokens · current_usd live RPC balance at scan time
pct_held 0–1+ current / launched (Infinity → re-accumulated when launched=0)
status enum holding · sold_partial · sold_all · reaccumulated
classification enum? pool_or_authority when the wallet looks like an AMM vault / treasury (not a retail bundler)
is_deployer bool
unchecked bool true when the per-scan RPC budget ran out before this wallet
proof object {launch_tx, launch_tx_url, wallet_url} — every claim in the row is verifiable on Solscan
holders object— top-20 distribution (Solana + EVM)
top_20 array account · owner · amount · pct · tag · is_burn/is_lp/is_cex/is_deployer/is_whale/is_bridge/is_team/is_mm
top_10_pct · top_20_pct raw concentration
adjusted_top10_pct excludes LP / burn / CEX — the real retail concentration
burn_pct · pump_curve_pct · lp_pct · cex_pct
holder_count int rows returned
organic_score object— 0–100 composite: launch cleanliness + hold/sold + distribution
score 0-100 higher = more organic. 75+ organic, 55+ mostly organic, 35+ mixed, 15+ coordinated, else manipulated
label enum organic · mostly_organic · mixed · coordinated · manipulated
verdict string one-line human explanation
reliable bool true when launch-window walk fired (for fresh launches). False on blue chips that used the fast-path; score still computed from holders + LP + activity.
signals array up to 10 contributing items: {kind, weight, ok, detail} — positive weights add to the score, negatives subtract
safety object— scores + reasons + redemption flags
rug_score 0-100 higher = more risk
blue_chip_score 0-100 higher = more legit
verdict enum see verdicts
rug_reasons array {text, weight, kind?, redeemed?, _original_weight?, redemption_note?, receipts?}
kind enum? mint_authority_active · mint_authority_lst_program (LST tokens — programmatic PDA, +5 not +15) · freeze_authority_active · dev_snipe · extreme_bundle · heavy_bundle · moderate_bundle · lp_unsecured · lp_partial · lp_concentrated_unsecured (V3/V4 NFT positions) · mintable · transfer_pausable · upgradeable_proxy · ownership_active · serial_rug · price_divergence (multi-pool arbitrage broken) · liquidity_drained (pool holds effectively nothing while still reporting volume — you cannot exit) · liquidity_thin (reserves too small for the traded volume; any real exit moves the price hard)
redeemed boolean true when a historical signal has materialized and been down-weighted
_original_weight int original score before redemption (preserved for transparency)
receipts object on-chain proof — check, numbers, sample wallets, dev_wallet, create_tx, verify_hint
blue_chip_factors array positive signals — includes kinds: organic_adoption, bundle_resolved
social object— verified + discovered socials
verified object from project metadata
found object scraped from verified website
site_title · site_description
fair_launch object— derived fair-launch detection (both chains)
status enum fair · unfair · unknown
detected boolean true only when every signal passes
summary string plain-english verdict
signals array five checks:
bundle_clean severity === 'clean'
no_dev_snipe deployer kept only a minimal launch allocation
organic_buyers several distinct wallets bought in the first minute
no_mev_bots no sandwich/priority-fee bots in launch window (EVM)
no_cluster_burst no large single-window buy cluster
deployer_verification object— multi-signal deployer authenticity check
verification_score 0-100 20 points per verified signal, capped at 100
signal_count · verified_count int
signals array {kind, verified, detail} — every way the deployer was authenticated:
creation_tx_signer · authoritative_launcher_record (pump.fun cross-ref) · source_verified · ownership_renounced · mint_authority_renounced · freeze_authority_renounced · prior_deployments_clean · prior_rugs_detected · cex_funded_deployer
team_wallets array— pre-launch airdrop recipients (EVM only)
wallet · tokens · tx_count · first_block · first_tx
Walks Transfer events FROM the deployer in a ±500 block window around launch to identify off-market allocations.
team_trades array— post-launch activity of team wallets (EVM only)
wallet · initial_airdrop · buy_count · sell_count · tokens_in · tokens_out · net_delta · txs[]
Renders on the price chart as amber ▲/▼ markers (distinct from deployer green/red).
links object— external explorers
_cached boolean— served from response cache or freshly computed
fetched_at iso8601— scan timestamp; append to OG URLs as &v=<unix> for cache-bust
schema_version int— increments when the response shape changes; clients can use it to invalidate their own caches

🎯 Verdicts & scores

safety.verdict is a one-word label derived from the two scores plus age + market gates. Order of evaluation: critical contract flags → score ladder → age-gated upgrade → canonical override.

VerdictTriggerMeaning
LIKELY_RUGStrong rug evidence stacked — or a confirmed honeypot (sell reverts) — or a critical contract flag (blacklist, hidden mint authority, paused)Strong evidence: cannot sell, dead market, deployer drain pattern, or active rug
HIGH_RISKMultiple negative signals stackedMultiple negative signals stacked
SUSPICIOUSConcerning concentration, authority, or bundle signalsConcerning concentration, authority, or bundle signals
CAUTIONMinor flags — new token or a single signalMinor flags — new token, single signal
CLEAN_ON_SURFACENo negative signals, but no established track record yetNo negative signals, but not established either
ESTABLISHEDSolid liquidity, holders, active markets, and meaningful ageLiquidity, holders, markets, age look solid
BLUE_CHIPProven market — deep liquidity, distributed holders, long track recordProven market, deep liquidity, distributed holders
Canonical-token overrides — pre-registered tokens skip the launch-window heuristics:
VERIFIED_STABLECOINUSDC, USDT, DAI, FDUSD, …Mint-controlled by a known issuer. Treated as a verified blue-chip class.
VERIFIED_WRAPPEDWETH, WBTC, cbBTC, WSOL, cbDOGE, cbXRP, BTCB, WBNB, …1:1 wrapped representation. Issuer custody controls stay visible but do not count as memecoin rug vectors.
VERIFIED_LSTstETH, jitoSOL, mSOL, weETH, …Liquid-staking receipt token. Treated as a verified blue-chip class.
BLUE_CHIP (canon)PEPE, SHIB, FLOKI, BONK, JUP, PYTH, …Established meme/token registry — launch-window scoring rules don't apply.

Hard cap: a token with strong rug signals can never be rewarded for being "old" or "renounced" — its blue_chip_score is forced to 0. Confirmed honeypots and critical contract flags always land on LIKELY_RUG regardless.

Active-rug labels (price_action.label)

Independent of safety.verdict — surfaces what's happening on-chain right now. A token can show CAUTION verdict (contract is clean) while ALSO showing lp_drained (the launch is actively unwinding). Share cards + tweets lead with these when they fire.

LabelTriggerSurfaces as
rug_pulledLiquidity effectively gone and price collapsed💀 RUG PULLED chip + tweet "RUG PULLED. Liquidity gone, price collapsed"
lp_drainedLP unsecured while price drops hard and the launch bundle is exiting🚨 LP DRAINING · RUG IN PROGRESS chip + tweet "RUG IN PROGRESS. LP unlocked, X% of bundle dumped"
bundle_dumpThe launch bundle is selling into a falling price📉 BUNDLE DUMPING NOW chip + tweet "Bundle is dumping. X% of launch bag exited"
mint_inflationMint not renounced, price dropping on thin liquidityIn-page advisory; not yet on share card
notable_drawdownSharp drawdown but LP secured and the bundle is quietIn-page only — distribution / market sell-off, not rug
pumpingStrong upside moveIn-page only — buy-share + watch-for-distribution context
normal_volatilityWithin a typical rangeIn-page only — within typical range

🔮 PRECOG — predictive rug score

precog is an additional forward-looking field on every scan response, served by an in-house ML model. It is not derived from safety — it's a parallel prediction trained on labeled outcomes from prior scans. Treat the absence of the field as "score not available", never as "no risk."

"precog": {
  "rug_probability": 0.83,        // 0..1
  "risk_band": "HIGH",            // CLEAN | LOW | CAUTION | HIGH | EXTREME
  "days_estimate": 6,             // estimated days until rug (or null)
  "days_low": 4, "days_high": 9,  // 87% confidence interval
  "model_version": "v0-rules",
  "schema_version": 1
}
BandProbability rangeFrontend chip
CLEAN< 20%Card omitted from the safety strip
LOW20%–<40%Green ring
CAUTION40%–<65%Amber ring
HIGH65%–<85%Coral ring + countdown
EXTREME≥ 85%Red ring + receipt countdown

Latency: typical inference 1.5–3 s when the predictive verdict is included; clients should treat absence as graceful fallback (the model is offline, the scan still works).

Bundle hold-vs-sold chips on the share card

Independent of verdict — the OG card shows the launch-bundle exit pattern so X / Discord / Telegram unfurls tell the truth even when the safety verdict is mild.

ChipTrigger
BUNDLE DUMPED ≥70%bundle.hold_analysis.pct_sold ≥ 0.70 AND ≥3 wallets sampled
BUNDLE EXITING ≥30%pct_sold ≥ 0.30 AND ≥3 wallets sampled
V4 POOL · NFT LPliquidity_lock.verdict === 'v4_pool' — informational, replaces misleading "LP UNLOCKED" on V4 launches

🧱 Rate limits

All limits are per-IP, hashed server-side (sha256, no raw IPs stored). Exceeding a limit returns 429 Too Many Requests.

EndpointPer minutePer hour
/api/v1/token · /api/scan/token30300
/api/v1/bundle30300
/api/scan/candles60 global + 30 per-pool
/api/scan/tape30
/api/scan/honeypot20
/api/scan/impact120
/api/scan/wallet-detail30
/api/scan/funder-chain20
/api/scan/deep-bundle630
/api/trending60
/api/social/feed30
/api/comments/search15200
/api/comments/list60600
/api/comments/wallet-lookup10120
/api/launch/book5
/api/check/[addr] (page renderer)30300
/api/og/*edge-cached 1h (60s + SWR on unversioned URLs)

Reports cache server-side for 12 hours — re-scanning the same address is effectively free. OG cards with a ?v=<unix> version tag are CDN-immutable (max-age=86400, immutable).

Need higher limits? DM @Analyzer6900.

💻 Code examples

curl -s 'https://analyzer69000.com/api/v1/token/<addr>' | jq '.safety'
const res = await fetch(`https://analyzer69000.com/api/v1/token/${addr}`);
const { token, safety, market } = await res.json();
console.log(`${token.name} — ${safety.verdict} (${safety.rug_score}/100)`);
import requests
r = requests.get(f'https://analyzer69000.com/api/v1/token/{addr}', timeout=10)
data = r.json()
print(data['safety']['verdict'], data['safety']['rug_score'])
// Node 20+ — native fetch
const res = await fetch(`https://analyzer69000.com/api/v1/token/${addr}`, {
  headers: { Accept: 'application/json' },
});
const report = await res.json();
resp, err := http.Get("https://analyzer69000.com/api/v1/token/" + addr)
if err != nil { return err }
defer resp.Body.Close()
var report map[string]any
json.NewDecoder(resp.Body).Decode(&report)
let url = format!("https://analyzer69000.com/api/v1/token/{addr}");
let report: serde_json::Value = reqwest::get(url).await?.json().await?;

❓ Frequently asked questions

Short answers. If something's still unclear, ping @Analyzer6900 on X.

Do I need an API key?

No. All public endpoints are free and rate-limited per IP — drop them into production without creating an account. A keyed higher-rate tier may launch later; the free tier stays free.

Which chains are supported?

Eight, with one unified scoring model:

  • Solana — base58 mint addresses
  • Ethereum, Base, BSC, Arbitrum, Optimism, Polygon, Avalanche0x… contracts

Chain is auto-detected from address format. Pass chain=auto or be explicit with chain=base, chain=avax, etc. Hyperliquid is treated as a perps venue, not a public token-scan chain.

Can I scan a contract that just launched seconds ago?

Yes. Cache is bypassed for any address we haven't seen before — first request triggers a fresh on-chain analysis (~1–3 seconds). After that, results are cached for 12 hours. Force a refresh with ?refresh=1.

How accurate is the rug score?

The score is deterministic — same on-chain state always produces the same number. Every signal is returned in safety.rug_reasons with a weight, so you can audit the math end-to-end.

Blue-chip recognition has an "established" override: mcap > $10M + liquidity > $500K + age > 30d pulls the score down automatically, so JUP / BONK / USDC don't trip the concentration detectors.

Two read-path reconciliations live in front of the cron jobs so the dashboard never disagrees with itself: (1) bundle-dump and holder-concentration are computed from adjusted_top10_pct on every read instead of trusting whatever a refresh job last wrote; (2) Uniswap V4 pools (no pair contract to burn) get a neutral v4_pool verdict instead of being misread as 0% secured.

What's in a token report?

Everything you'd otherwise stitch together from 4–5 different tools:

  • Mint + freeze authority status (revoked? renounced?)
  • Deployer trail, first-buyer bundle, dev-snipe %
  • Every liquidity pool across every DEX + cross-chain breakdown
  • Holder map — top 20 with pump.fun curve / LP / burn / deployer / retail classification
  • Socials (X, Telegram, Discord, site) with verified vs. found separation
  • Price, volume, market cap, FDV, 24h change, age
  • Rug score + blue-chip score + verdict (BLUE_CHIP / ESTABLISHED / SUSPICIOUS / LIKELY_RUG)
What are the rate limits?

30 req/min and 300 req/hour per IP on the free tier. Burst-friendly. If you hit the ceiling we return HTTP 429 with a Retry-After header — respect it and you're back online in under a minute.

Bursty dashboards: cache reports client-side or server-side for 60 seconds to spread load.
Can I use it in a commercial product?

Yes — fair use applies (don't resell the raw JSON as "your" API). Link back with "Scan by Analyzer69000" or leave the built-in Powered by branding in the embeds. Custom accent colors, custom themes, all allowed — we want the widgets in your UI.

Is the embed safe to drop into my production site?

Yes. Specifically designed to be boring security-wise:

  • Shadow-DOM isolated — zero CSS leakage in either direction
  • All user-derived strings HTML-escaped before render
  • Logo images gated through URL() protocol check (only https://) and loaded with referrerpolicy=no-referrer
  • No inline event handlers constructed from API data
  • No third-party network calls from any variant except bubbles, which lazy-imports D3 from cdn.jsdelivr.net (add to script-src if you run strict CSP)
  • Optional auto-refresh is capped at min 20s so it can't amplify a reload loop
What happens if Analyzer69000 is down?

The widget renders a graceful error state in your chosen theme — no broken layout, no console spam, no uncaught promises. Your page keeps working. Once the API comes back, the next data-refresh tick recovers automatically.

Do you store any user data?

No wallet connect, no cookies, no accounts, no PII. Rate limiting uses a SHA-256 hash of the requester IP — the raw IP is never written to disk. Token reports are cached for 12h keyed on address + chain only.

How do I report a bug or suggest a feature?

DMs open on X @Analyzer6900. Include the token address, the response you got, and what you expected — fixes usually ship same day.