New altcoins create an identification problem before they create an investment problem. A familiar name or ticker can point to multiple contracts, copycat tokens, wrapped versions, abandoned deployments, or an asset on the wrong network. Market pages may appear before documentation is complete, and social channels may circulate an address that differs from the project’s official materials. A scanner should therefore begin with identity and control, not price performance.
The checklist below is designed to reject uncertain candidates quickly and document the questions that remain. It does not certify a token as safe. Smart contracts can contain undiscovered defects, teams can change behavior, liquidity can disappear, and public information can be false or incomplete. The purpose is to replace a fast, emotionally loaded launch process with a sequence of verifiable checks.
Confirm the exact chain and token address
Record the network, contract or mint address, symbol, decimals, and the official source that published the address. Compare at least two first-party references when available, such as project documentation and an announcement from a long-standing official channel. Do not rely on a search result snippet, token logo, or symbol. Copycat assets can reproduce all three. On multichain projects, determine whether the token is native, bridged, or wrapped and which contract is intended for the venue you are reviewing.
Store the address as the primary identifier in the scanner. Symbols and names are display fields. If the address changes because of a migration, treat the replacement as a new asset record linked to the old one, not a silent update. This preserves price and holder histories and prevents a new contract from inheriting the credibility or market data of an earlier deployment.
Surface every meaningful control
A token contract or mint may include authorities that can create supply, freeze accounts, pause transfers, restrict recipients, change fees, blacklist addresses, upgrade logic, or alter metadata. The specific mechanisms differ by network and standard. A scanner should list these capabilities and the controlling address, then identify whether control is held by one account, a multisignature arrangement, a governance system, or an unknown entity. Renounced ownership does not prove the absence of other privileged roles.
Ask whether the control is necessary for the stated product and whether the project discloses it clearly. Permissioned real-world-asset tokens may intentionally include transfer restrictions. A community token may not need the same capabilities. The question is not whether all administration is bad; it is whether the power, holder, purpose, and change process are visible enough for the intended risk profile.
Reconcile supply and distribution
Compare onchain supply with the project’s stated total, circulating amount, allocation table, and vesting schedule. Identify addresses associated with the team, treasury, investors, market makers, liquidity pools, bridges, staking contracts, and burn mechanisms when labels are verifiable. Do not subtract an address from concentration simply because a community label claims it is an exchange or pool. Use contract type and transaction behavior to support the label.
Review how much supply can still be created and who controls that function. If supply is capped, confirm how the cap is enforced. If emissions are planned, map the schedule and recipients. A fully diluted valuation can be misleading without time. A large future supply released slowly for security incentives differs from a large near-term allocation controlled by a small group. The scanner should present timing and control alongside the ratio.
Inspect holder concentration with context
Calculate concentration after separating known contracts and infrastructure, but preserve both the raw and adjusted views. A top-holder list can be dominated by a liquidity pool, bridge, vesting contract, or custodian. Conversely, one entity may divide holdings among many addresses. The data can reveal questions, not ownership with certainty. Track changes over time, especially transfers from deployer, treasury, or vesting addresses into exchange-associated wallets or liquidity pools.
Look for distribution mechanics that create misleading holder counts, such as dust transfers to many addresses or airdrops that recipients never use. Active holders, retention, and transaction diversity may be more informative than the headline count. For very new tokens, short history makes every distribution metric unstable; mark that limitation instead of assigning a precise decentralization score.
Evaluate liquidity ownership and exit conditions
Confirm the main trading pair, pool address, quote asset, liquidity amount, and who controls the liquidity position or associated tokens. Terms such as “locked liquidity” require details: what is locked, where, by whom, until when, and whether other privileged actions can still change trading conditions. A lock does not eliminate contract risk, mint risk, transfer restrictions, price impact, or the possibility that liquidity exists mainly in a volatile quote asset.
Estimate price impact for several order sizes and observe how liquidity changes after launch incentives. Report spread, depth, and venue concentration rather than relying only on daily volume. New-token volume can be highly variable and may include automated or circular activity. If the market cannot support the planned size without large impact, the candidate fails the execution gate regardless of the narrative.
Review deployer and related-address history
Trace the deployment transaction, funding source, prior contracts, and administrative transfers where the chain permits. A deployer that created many short-lived tokens or reused code with problematic controls deserves closer review. A new address is not automatically suspicious, and an established address is not automatically trustworthy. The goal is to identify relationships and inconsistencies that the project should be able to explain.
Save evidence links and transaction hashes internally, but avoid asserting that addresses belong to a person without reliable attribution. Cluster analysis can produce false associations through exchanges, routers, and shared infrastructure. Use confidence labels such as confirmed, probable, possible, and unknown. The wallet scanner framework applies the same evidence discipline to transfer interpretation.
Check code, documentation, and product claims separately
Verified source code means the published source corresponds to deployed bytecode under the explorer’s process; it does not mean the code is safe or the product works. Review whether the contract uses standard components, whether upgrade paths exist, and whether audits cover the exact deployed version. Read audit scope, unresolved findings, and dates. An audit badge without the report is not evidence.
Then examine the product claim. Is there a usable application, open repository, test environment, protocol documentation, or measurable onchain behavior? Separate the token from the product. A functioning application does not guarantee that the token captures value, and a liquid token does not prove that the application has users. The scanner should have distinct fields for contract quality, product evidence, and token utility.
Validate websites, communications, and legal claims
Check domain age and history, consistent links among official channels, named entities where relevant, and whether legal or regulatory language is precise. Be cautious with claims of approval, licensing, partnerships, insurance, guaranteed yield, or institutional backing that cannot be verified from the named organization. Screenshots and logos are easy to copy. Contact details and documents should identify the responsible party and jurisdiction when the project makes legal or asset-backed claims.
Investor.gov notes that crypto asset investments can involve significant volatility, illiquidity, platform failure, fraud, and limited protections; its crypto asset investor alert is a useful reminder that registration and disclosures may be absent or incomplete. A scanner cannot replace legal review, and it should not present an unverifiable compliance claim as a positive signal.
Use a staged new-token decision checklist
- Identity: chain and exact contract or mint address verified from reliable first-party sources.
- Control: mint, freeze, pause, blacklist, fee, transfer, metadata, and upgrade powers identified.
- Supply: onchain amount reconciled with allocation and release information; future creation understood.
- Distribution: raw and adjusted holder concentration reviewed with labeling confidence shown.
- Liquidity: main pools or venues confirmed; ownership, lock terms, spread, depth, and price impact reviewed.
- History: deployer and related contracts inspected without overclaiming address ownership.
- Evidence: product, code, audit, partnership, and legal claims verified independently.
- Outcome: reject, monitor, or investigate with a written reason and next checkpoint.
Do not compress the checklist into one green badge. A candidate may pass identity and liquidity while failing control or disclosure. Keep the dimensions visible so the decision can be revisited when new evidence arrives. For early launches, “monitor until more history exists” is often the most accurate outcome.
Trust the address only after the evidence matches
New-token research should move from identity to control, supply, distribution, liquidity, history, product evidence, and claims. Price belongs later in the process. This ordering helps prevent a rising chart or familiar ticker from bypassing the checks that determine what the asset actually is and who can change it.
A scanner improves the process when it preserves uncertainty and rejects incomplete records. It cannot guarantee safety, but it can make the reasons for caution specific, auditable, and harder to ignore during a fast-moving launch.
