Monthly New Token Risk Signals
A monthly risk report should measure observable signals, not label every flagged token a scam or predict what it will do. Transfer restrictions, mutable fees, privileged ownership, concentrated holdings, unlocked liquidity, and suspicious trading patterns each need a precise test and timestamp. No complete monthly dataset accompanies this article, so it presents no prevalence statistics and names no riskiest token. Coinatio's live table supplies current examples and timestamps for ongoing review. Scanner findings can be incomplete or mistaken, and an unflagged token is not necessarily safe. This research is not financial advice.
Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.

- Build cohorts from all eligible first-traded tokens in a complete UTC month, including failed and short-lived launches.
- Give every signal its own measurable denominator, since provider and chain support vary by test.
- Separate contract capabilities, observed behavior, market structure, and confirmed incident evidence.
- Publish scan time, chain state, provider version, missingness, exclusions, and post-publication revisions.
Cohort, denominator, and observation windows
Define the monthly cohort as unique fungible tokens whose first verified permissionless trade occurred from 00:00:00 UTC on the first day through 23:59:59 UTC on the final day. Deduplicate contracts or mints across pools. The overall cohort denominator includes every eligible observed launch, even if liquidity later disappears or the token is absent from aggregators. Excluding vanished tokens would bias the report toward survivors.
Use fixed token-age snapshots, such as 24 hours and 7 days after first trade, and a separate month-end status. Mature the cohort before publishing any 7-day metric. For each signal, the denominator is only cohort tokens for which that test was technically supported and returned a conclusive result at the target age. Report unsupported, provider-error, inconclusive, and not-yet-mature counts separately. Never divide flags by the whole cohort when the scanner covered only part of it.
Signal taxonomy and reproducible tests
Contract capability signals include owner-controlled minting, pausing, denylisting, fee changes, proxy upgrades, and transfer restrictions. Behavioral signals include a failed standardized sell simulation, fees observed outside declared thresholds, or privileged state changes after launch. Market-structure signals include adjusted holder concentration, thin executable liquidity, rapid liquidity withdrawal, and dominant deployer-linked funding. Incident evidence, such as a confirmed exploit or publicly attributed illicit service, belongs in a fourth category and should not be inferred from capability flags alone.
Query GoPlus and Honeypot.is at the target timestamp where historical responses exist, retain raw responses, and map fields through a versioned normalization table. Validate critical flags against bytecode, verified source, transaction simulation, or onchain events when feasible. Use Uniswap and Raydium pool mechanics to calculate liquidity changes consistently. Use Birdeye and CoinGecko for discovery and cross-checking, not as universal ground truth.
Publish per-signal counts, conclusive denominators, rates, and exact binomial confidence intervals when the sample supports them. For small denominators, show counts prominently and avoid false precision. A composite score may be useful for sorting only if weights are declared before examining outcomes, missing signals are not silently scored as safe, and component flags remain visible. Coinatio's live table supplies current examples; it should not be interpreted as a fixed monthly cohort unless the matching filters are active.
Exclusions and outcome validation
Exclude testnet deployments, NFTs, wrapped canonical assets, duplicate pools, known protocol receipt tokens, and contracts that never became permissionlessly tradable. Keep flagged, illiquid, abandoned, and delisted tokens in the eligible cohort. Exclude a token from one metric only when that metric is unsupported or inconclusive, and state the reason. Do not remove outliers merely because they dominate a chart.
A honeypot simulation failure may result from temporary state, route selection, gas assumptions, anti-bot windows, or unsupported contract behavior. Reproduce it from the same block where possible and distinguish cannot sell from simulation unavailable. Likewise, unlocked liquidity is a condition, not proof that liquidity will be removed. Chainalysis reports can inform categories and attribution standards, while MetaMask documentation can inform wallet-facing security context, but neither turns a scanner flag into a confirmed incident.
Timestamp requirements, coverage, and limitations
Each row needs first trade time, target observation age, block or slot, scan start and completion times, provider response timestamp, market-data timestamp, simulation parameters, chain finality status, and analysis version. Monthly releases need cohort cutoff, maturity cutoff, data freeze time, and revision date. Store source payload hashes so later provider changes can be distinguished from coding changes.
Coverage varies across chains, token standards, proxy patterns, launchpads, and DEX venues. Provider definitions may differ for similar fields, and historical point-in-time security data may not exist. Report a coverage matrix by signal and chain plus the share of unknown results. Cross-chain totals should be weighted by conclusive token observations, not averaged from chain percentages without their denominators. These signals support investigation and comparison, but they do not establish intent, identity, legality, or future outcomes.
Sources
This article explains technical and market-data concepts. It is not financial, legal, tax, or investment advice. Verify current chain state and primary documentation independently.


