Token Indexer Data Checklist: From Chain Identity to Market Data

The minimum identity tuple is chain or network, contract address or mint, and token program where relevant. Preserve address casing according to chain conventions and validate checksums for EVM addresses. Record deployment or mint-creation transaction, creation slot or block, creator, decimals, raw supply, authorities, program owner, proxy implementation, and selected Token-2022 extensions. Obtain these fields from RPC or verified explorer data.

Symbols and names are labels, not unique keys. Attackers and unrelated projects can reuse them. Every API response, database row, cache key, and support request should retain canonical identity even if the interface hides it. For bridged assets, distinguish the representation contract from the origin asset and record the bridge relationship only when it can be verified through the bridge's canonical contracts or registry.

Prepare name, symbol, description, logo, website, explorer URL, documentation, and public social links in the format required by each platform. Host assets at stable public URLs with correct MIME types and no authentication, redirects that depend on cookies, or short-lived query signatures. Use square logos with sufficient resolution and keep visual identity consistent across metadata standards and submissions.

Record where each field originates: ERC-20 calls, Metaplex account, Token-2022 metadata, verified source, project submission, or platform curation. Include update authority and mutability. If sources conflict, do not silently merge them. Define precedence and surface a review state. CoinMarketCap listing processes and Birdeye token updates apply their own requirements, validation, and timing beyond what exists onchain.

A price requires a valid market and a methodology. Record DEX, pool program or factory, pool address, base and quote assets, fee tier, creation transaction, reserves or active liquidity, and first reliable trade time. Verify vault mints and pool ownership directly. A fake pool can reuse a symbol or pair a real token with a worthless lookalike quote asset.

Volume, liquidity, fully diluted valuation, circulating supply, and holder counts are derived fields. Define time window, quote currency, decimal normalization, excluded addresses, spam filters, and refresh time. Fully diluted valuation often uses total or maximum supply, while market capitalization requires a circulating-supply methodology. Do not label one as the other. Retain raw inputs so a displayed value can be reproduced.

Create a versioned manifest that can be compared with the values visible on each target platform. Submit through official channels and log request identifiers without exposing private credentials.

• Validate network, canonical address, token program, decimals, supply, authorities, extensions, and proxy state.
• Provide stable logo and metadata URLs, provenance for every field, and a contact path for corrections.
• Verify pool contract, vault assets, token ordering, fee tier, creation transaction, and usable liquidity.
• Define circulating supply exclusions with labeled addresses and reproducible onchain balances.
• Compare RPC, explorer, DEX, CoinMarketCap or Birdeye output after expected ingestion windows.
• Alert on identity mismatches, decimal changes in cached data, stale timestamps, broken media, and implausible price jumps.

This checklist improves data quality but does not compel an indexer to list an asset or apply a particular ranking. Platforms use independent eligibility, liquidity, abuse-prevention, and review policies. APIs can lag the chain, reorganizations can affect recent events, and circulating supply can require judgment about controlled wallets. Never treat an indexed logo, verified page, price, or ranking as proof of authenticity. Consult each provider's current schema, rate limits, and update process.