How to Use an Altcoin Scanner: A Practical Research Workflow
A step-by-step method for turning a broad token universe into a focused research list using liquidity, market structure, supply, onchain, and risk filters.
Read the guide →Wallet data shows addresses, balances, transactions, programs, and contract interactions. It rarely shows intent or the identity of every beneficial owner. A wallet scanner should distinguish observable events from labels and interpretations, preserve confidence levels, and decode whether activity is a transfer, swap, bridge movement, liquidity action, vesting claim, or protocol operation.
Keep each data family traceable so one attractive metric cannot silently override missing identity, liquidity, supply, or control information.
Record the source, date, and confidence for exchange, bridge, treasury, deployer, pool, custodian, or contract labels.
Show raw balances and an adjusted view for known infrastructure while acknowledging one entity can use many addresses.
Decode transfers, swaps, liquidity actions, bridge flows, staking, vesting, and internal protocol movements separately.
Track concentration, new large holders, treasury movement, exchange-associated flows, and persistence without calling every deposit a sale.
Use common funding, timing, contract interaction, and behavior as leads, not proof of shared ownership.
Preserve block, timestamp, transaction hash, chain, decoder version, and indexing status for every alert.
A useful scan is a documented sequence with clear failure states, not a mysterious score that always produces a candidate.
Capture the chain event and decode what technically occurred before adding labels or market interpretation.
Attach known entities with source and confidence; leave uncertain addresses unknown rather than guessing.
Compare with pools, bridges, exchanges, vesting contracts, supply, liquidity, and related market activity.
Write several plausible interpretations and identify the evidence that would distinguish them.
Scanner results become more trustworthy when their blind spots are displayed beside the output.
One public address may represent many customers, while internal trades may not appear as one-to-one onchain events.
One user action can produce many transfers through routers, multicalls, vaults, bridges, and settlement contracts.
Shared funding services and exchange withdrawals can create false clusters. Labels require evidence and may become stale.
Move from the page-level framework into a detailed, source-linked research workflow.
A step-by-step method for turning a broad token universe into a focused research list using liquidity, market structure, supply, onchain, and risk filters.
Read the guide →
A structured checklist for verifying a new token’s identity, contract controls, supply, holders, liquidity, deployer history, market data, and project claims.
Read the guide →
Screen Ethereum tokens by contract address, ERC-20 behavior, roles, upgradeability, supply, holders, pools, transfer activity, layer-2 deployment, and market quality.
Read the guide →It can identify large addresses and known entities, but beneficial ownership may be unknown or pooled. Use labels with confidence.
Not necessarily. It may precede a sale, custody change, collateral action, or other use. Trade evidence is needed for a stronger claim.
Pools, bridges, treasuries, and custodians can dominate raw balances. Both raw and adjusted views reveal different aspects of structure.
Wallet flows can provide context, but they do not determine future price and can be misinterpreted without market and contract data.
Start with a defined universe, combine independent signals, and record why each candidate survives or fails the scan.