Altcoin scanner methodology
A scanner is only as useful as its universe definition, identity mapping, source lineage, freshness rules, failure states, and review record. This methodology keeps those choices visible.
Define the universe before looking at winners
Write the chains, categories, minimum history, liquidity floor, geographic or venue constraints, time horizon, target behavior, and excluded risks first. This reduces selection bias and makes later evaluation reproducible.
Universe
Chains, token types, categories, age, market venues, data providers, and inclusion rules.
Horizon
Sampling frequency, lookback windows, intended holding horizon, and valid comparison periods.
Exclusions
Missing identity, weak history, inadequate liquidity, unsupported jurisdictions, or unacceptable controls.
Resolve identity and source lineage
Every market, contract, wallet, supply, and venue field should trace back to a canonical record anchored by chain plus contract address or mint. Provider IDs are mappings, not substitutes for identity.
- Preserve native, wrapped, bridged, migrated, and proxy forms separately.
- Record provider, endpoint or document, retrieval time, and field meaning.
- Expose conflicts instead of choosing the most favorable value.
- Version decoders, labels, transformations, and classification rules.
Gate first, rank second
Keep eligibility, ranking, and context as separate concepts. A failed safety or data gate should not be offset by momentum, social attention, or a model score.
| Rule type | Examples | Output | Missing data |
|---|---|---|---|
| Identity gate | Exact chain and contract, migration state, symbol collision | Pass or reject | Reject or quarantine |
| Data gate | History, timestamps, coverage, provider agreement | Pass or incomplete | Reduce scope or reject |
| Liquidity gate | Spread, depth, pool liquidity, routes, price impact | Pass or reject | Reject execution claims |
| Risk gate | Minting, freezing, proxy upgrades, transfer restrictions | Allowed, flagged, or reject | Require review |
| Ranking feature | Relative trend, activity acceleration, breadth, catalyst quality | Contribution to rank | Visible penalty |
| Context field | Category, benchmark, custody, venue access, narrative | Interpretation | Label unknown |
Review, snapshot, and monitor drift
Every result should carry a reason, the strongest evidence, the biggest weakness, source timestamps, confidence, and the next observation that would invalidate the classification.
Reject
A mandatory identity, data, liquidity, access, or risk rule failed.
Monitor
The candidate is incomplete, early, stale, or waiting for a defined confirmation.
Investigate
The candidate passed the screen and moves to deeper source and execution review.
Drift
Track feature distributions, missingness, provider changes, and decision outcomes over time.
Methodology questions
Why use hard gates before scores?
Hard gates stop missing identity, insufficient history, poor liquidity, or disallowed control risks from being hidden by a high score elsewhere.
Should all signals use the same refresh rate?
No. Market, onchain, supply, contract, and platform-access fields change at different speeds. Each field needs its own freshness policy.
How are missing values handled?
Missing values should remain missing, reduce confidence, or trigger a gate. They should not be silently converted into neutral or favorable values.
What are reject, monitor, and investigate outcomes?
Reject means a hard requirement failed; monitor means the candidate is incomplete or early; investigate means it passed the screen and deserves deeper human research.
Build a cleaner altcoin research process
Start with a defined universe, combine independent signals, and record why each candidate survives or fails the scan.