A Solana altcoin scanner should treat the mint address as the asset’s identity. Names, symbols, and logos are metadata that can be copied. The mint defines the token, while token accounts hold units for owners. Authorities and token extensions can affect supply, transfers, fees, freezing, metadata, and other behavior. Market activity adds another layer: liquidity may be fragmented across decentralized exchanges and pools, while new launches can generate large amounts of automated trading.
The scanning workflow therefore combines mint-level facts, account distribution, liquidity, execution, and time-based activity. It should distinguish what the chain proves from what labels infer. A rising chart does not resolve an uncertain mint, and a large holder count does not prove broad ownership. The purpose is to organize verifiable fields and make Solana-specific risks visible before a candidate enters deeper research.
Use the mint address as the canonical identifier
Store the mint address, token program, decimals, current supply, metadata reference, and first observed transaction. Compare the mint with official project sources and the exact pool or venue under review. A symbol lookup can return multiple unrelated tokens. When aggregating prices or holders, require the same mint address across every provider. If a project migrates to a new mint, create a linked record rather than merging histories.
The official Solana token documentation explains that tokens are represented by mints and token accounts and can use different token programs and extensions. A scanner should identify which program governs the mint because available features and decoding rules may differ. Unknown or unsupported program data should lower coverage, not be silently interpreted as a standard token.
Inspect mint, freeze, and update authorities
Determine whether a mint authority can create additional units and whether a freeze authority can freeze token accounts. Record the authority address and whether it has been revoked. Review metadata update authority separately; a changeable name or image does not alter balances, but it can affect user identification and trust. If an authority is controlled by a program or multisignature arrangement, identify that structure where possible.
Do not convert “revoked” into a general safety badge. Other extensions or program logic may still affect transfers, fees, or account behavior. Conversely, an active authority may be part of a disclosed issuance or compliance process. The scanner should state the capability and controller, then let the research policy decide whether it fits the intended universe.
Decode token extensions and transfer behavior
Token extensions can introduce transfer fees, confidential features, non-transferability, metadata storage, permanent delegates, interest-bearing calculations, default account states, transfer hooks, and other capabilities depending on the program and configuration. Surface enabled extensions with plain-language explanations and links to the raw account data. Some combinations may be incompatible or have operational implications for wallets and venues.
Pay particular attention to capabilities that change what a holder can transfer or what amount a recipient receives. A transfer-fee token can make quoted prices and pool behavior harder to interpret. A permanent delegate or transfer hook can introduce control or external logic. These features may be intentional, but they should be understood before liquidity and holder metrics are treated as comparable with a basic token.
Verify supply and concentration using token accounts
Calculate total supply from the mint and reconcile it with provider records. Review the largest token accounts, but classify known pools, program vaults, bridges, treasuries, vesting arrangements, and custodians where evidence supports the label. One owner may control multiple token accounts, and one token account belongs to a single mint. Preserve raw account concentration and an adjusted view rather than presenting one number as definitive ownership.
Track creation, distribution, and consolidation patterns over time. Airdrops can create many accounts with tiny balances; automated systems can create high transaction counts; custodial services can concentrate balances for many users. Use active-account and balance-retention measures alongside the holder count. For a new mint, short history should be a visible limitation.
Map liquidity across pools and quote assets
Identify the major pools for the mint, the quote asset in each pool, fee tier or market design, current liquidity, and recent trade activity. Avoid summing pools without considering whether liquidity can be routed efficiently among them. A token paired mainly with another volatile or illiquid token presents a different exit profile from one paired with a deeply traded stable asset or SOL, although each pair carries its own risks.
Estimate price impact at several sizes using current pool state or a reliable quote service, then compare with observed volume and trade count. Flag pools created very recently, pools with concentrated liquidity outside the current price, and markets dominated by a small number of trades. The Solana scanner page keeps pool liquidity, activity, and mint controls as separate layers so one cannot mask another.
Distinguish organic activity from launch automation
New Solana tokens can attract bots, routers, and automated market participants immediately. High transaction count may reflect repeated small swaps, priority-fee competition, arbitrage, or failed transactions rather than a broad user base. Examine unique fee payers, trade-size distribution, repeat addresses, direction balance, and persistence after the initial launch window. These are imperfect proxies, but they provide more context than raw count.
Look for concentration in the first buyers and the relationship between early accounts, deployer funding, and liquidity provision. Avoid asserting common ownership based solely on timing or a shared exchange funding source. Use clusters as research leads with confidence levels. A scanner should support transaction inspection, not issue accusations.
Add token age, metadata, and project evidence
Record mint creation, first liquidity, metadata updates, website publication, repository history, and major announcements as separate dates. A token can have an old mint and newly activated market, or a recent metadata change on an existing asset. These timelines help identify migrations, revived contracts, and copied branding. Verify that official links point back to the same mint and that the project describes the token’s purpose and controls.
Metadata can be mutable and offchain resources can disappear. Cache the observed URI and hash important public documents for internal research where appropriate. Do not treat a polished website as proof of product use. Review program activity, open-source code, documentation, and application behavior independently from token marketing.
Interpret charts with Solana execution context
Price charts for a mint may aggregate several pools and routes. Check which market dominates the price and whether the quote is stale or influenced by a shallow pool. Compare candles with liquidity and trade count; a large percentage move in a tiny pool is not equivalent to the same move in a deeper market. For fee-on-transfer or unusual extension behavior, verify how the data provider calculates price and volume.
Use volatility and relative strength, but apply the same identity and liquidity gates before ranking chart patterns. Compare the token with SOL and with a relevant Solana sector basket. A token can rise because SOL rises, because a sector narrative expands, or because of mint-specific activity. The scanner should show all three contexts.
A Solana token scan record
- Mint address, token program, decimals, supply, metadata URI, and creation timeline.
- Mint, freeze, metadata, delegate, and other relevant authorities with revocation status.
- Enabled token extensions and their practical effects on transfers, fees, or control.
- Raw and adjusted token-account concentration with label confidence shown.
- Major pools, quote assets, liquidity, trade count, volume, routing, and estimated price impact.
- Activity quality: unique participants, repeat behavior, trade sizes, and persistence after launch.
- Project evidence, migrations, chart source, benchmark context, and unresolved data gaps.
Use reject, monitor, and investigate outcomes. Reject records with uncertain identity or incompatible control features. Monitor tokens that need more history or stable liquidity. Investigate candidates that pass the rules with a written question about product use, supply, market structure, or token utility. Preserve the original snapshot so later findings do not rewrite the initial evidence.
Scan the mint before the momentum
Solana token research begins with the mint and token program, then expands to authorities, extensions, accounts, pools, activity, metadata, and chart context. Each layer answers a different question. Combining them without hiding missing data produces a more reliable shortlist than a feed ranked by percentage change alone.
The chain can show what the mint and accounts do; it cannot automatically explain who controls every address or why every transfer occurred. Keep those inferences labeled, and let uncertain records remain uncertain until the evidence improves.
