A Reproducible Checklist for Screening Tokens Less Than One Hour Old
The first hour of DEX activity contains little history and a great deal of ambiguity. Metadata may not have propagated, analytics may be incomplete, and a few related wallets can dominate every visible metric. A useful screen does not try to compress that uncertainty into a green check. It captures a repeatable snapshot, rejects identity mistakes, and documents what cannot yet be known. The same checklist should produce the same factual record when another researcher runs it against the same block range.
Editorial research by Coinatio, checked against the primary documentation cited below. Educational content only.
- Anchor age to a named event and an exact block or slot.
- Verify identity and contract controls before interpreting market metrics.
- Measure liquidity quality, participant concentration, and trade behavior separately.
- Mark unavailable evidence as unknown rather than passing it by default.
- Repeat the snapshot because first-hour conditions change quickly.
Step 1: freeze the observation window
Record the current UTC time, chain, latest finalized or confirmed block, token address, pool address, and data sources. Define age explicitly. Contract deployment age, mint initialization age, pool initialization age, first funded-liquidity age, and first-swap age answer different questions. For market screening, first usable liquidity and first swap are usually the most relevant pair.
Save transaction links or raw identifiers for each timestamp. Human-readable times from indexers can differ because of parser logic or delayed ingestion. If the chain reorganizes, rerun the record against the canonical transaction history and note the revision.
Step 2: establish token identity and controls
Copy the token address from the pool account or swap transaction, not from a search result. Confirm decimals, total supply, metadata URI, deployer or mint authority, and implementation details where proxies are used. On EVM networks, inspect owner roles, upgradeability, fee setters, pause logic, allowlists, blocklists, and transfer conditions. On Solana, inspect mint and freeze authorities plus relevant token extensions.
Source verification helps reviewers read declared code, but it does not prove benign behavior. Unverified code limits analysis, while verified code can still contain privileged or surprising logic. Write each control as an observable capability, including the account currently holding it, instead of assigning a vague audit badge.
- Address and chain match the observed pool.
- Decimals and supply agree across RPC and explorer views.
- Administrative capabilities are listed with current controllers.
- Proxy or upgrade authority is identified when applicable.
Step 3: inspect liquidity structure
Identify both reserve assets, the pool fee tier, reserve balances, current position range for concentrated liquidity, and the initial provider. Express depth using executable quotes against a recognized quote asset. A displayed dollar figure can be circular when it relies on the new token's own pool price.
Determine who controls liquidity tokens or position NFTs and whether any lock claim can be verified on-chain. A lock only covers the specified position under the specified contract and expiry. It does not restrict token authorities, other pools, concentrated-liquidity range changes, or unrelated wallets.
Step 4: review first-hour activity
Count swaps, unique transaction signers, unique traders where the chain model permits, and volume by base and quote amounts. Separate aggregator-routed swaps from direct pool interactions. Inspect whether a few wallets account for most volume, whether the deployer funded early buyers, and whether repeated sizes or alternating trades suggest automation.
Test quotes in both directions through an official interface or endpoint. Include expected output, price impact, fees, route, block number, and simulation result. Buy and sell counts alone do not reveal trade sizes, independent demand, profitability, or the ability to execute future exits.
- Compare counts with unique traders and notional size distribution.
- Flag related funding patterns without claiming common ownership as fact.
- Treat failed simulations as unresolved until the error is decoded.
Step 5: classify evidence and revisit
Finish with three columns: observed, not observed, and unknown. For example, a mint authority may be observed as revoked, no verified source may be observed, and beneficial ownership may remain unknown. Add data-source timestamps because holder and liquidity distributions can change within a block.
Repeat the screen after a fixed interval such as 15 or 30 minutes, preserving both snapshots. Indexing gaps, limited transaction history, private relays, address clustering uncertainty, and chain-specific semantics prevent this checklist from establishing safety. It organizes due diligence and makes disagreements auditable. It is not financial advice.
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.
