Best crypto data API for token metadata, live across Mobula, Codex, Jupiter
Share of metadata fields (logo, description, twitter, website) populated for fresh-launch tokens, audited every launch on Solana, BNB and Base.
This benchmark measures the gap every wallet, portfolio tracker and DEX terminal hits within a few minutes of a memecoin launch. when a token is two minutes old, how much of its metadata does each aggregator actually return. Logo, description, twitter, website. The four fields a UI needs to render a tradeable card instead of a contract address and a question mark. Aggregator marketing pages quote "37M tokens indexed" or "real-time coverage", but the moment a pump.fun or Four.meme token clears its bonding curve the gap between providers becomes visible to end users. The harness watches new launches on Solana, BNB Chain and Base via Mobula Pulse V2, then asks Mobula, Codex and Jupiter (Solana only) for the same token and records which fields came back populated. Because Jupiter is Solana-only by construction, the leaderboard is read per chain rather than as a cross-chain aggregate that mechanically favours the chain-restricted provider. On Solana the current leader is Mobula at 57.8%; on BNB Chain it is Codex at 83.8%. Coverage is the share of field checks that returned a value, computed as a rolling rate so the leaderboard reflects what the API is doing this hour, not what its catalogue claims to hold.
Methodology
We benchmark how complete each aggregator's token-metadata response is for freshly-launched tokens. The harness subscribes to Mobula Pulse V2 for new tokens on Solana, BNB Chain and Base, then asks each aggregator (Mobula, Codex, Jupiter where the chain is supported) for that token's metadata and records whether four canonical fields (`logo`, `description`, `twitter`, `website`) were returned. The aggregate is the share of (provider, chain, field) combinations that returned a populated value across all fresh-token checks in the window. A value of 100% means every field was returned for every fresh token; a value of 50% means half the fields were missing on average. Sort order on this page is ascending, so the lowest coverage shows first, which is the inverse of latency benchmarks. Readers should compare the columns themselves; numerical p50 is the headline.
Frequently asked
Which token metadata API has the best coverage for fresh launches?
The leaderboard is read per chain because one provider (Jupiter) is Solana-only and would mechanically dominate an unfiltered cross-chain aggregate. On Solana, Mobula currently leads at 57.8% (p50, 24 h). On BNB Chain, Codex leads at 83.8% (p50, 24 h). The benchmark targets the hardest case for any aggregator, tokens minted in the last few minutes on Solana, BNB or Base launchpads (pump.fun, Four.meme, Meteora DBC, Raydium CPMM and others), where catalogue size matters less than how fast the indexer reads off-chain metadata.
What does 'metadata coverage' actually measure?
For every freshly-launched token the harness asks each provider for that token's metadata and records whether four canonical fields came back populated. Logo, description, twitter, website. Coverage is the share of those field checks that returned a value, summed across providers, chains and fields, then expressed as a percentage. A provider with 80% coverage returns four-fifths of the requested fields on average for fresh tokens; a provider with 50% leaves half the fields blank.
Why do fresh tokens have low metadata coverage everywhere?
Most fresh tokens are minted by a launchpad with on-chain metadata that contains name, symbol, decimals, and sometimes a logo URI, but rarely a twitter or website out of the box. Aggregators have to pull the rest from off-chain sources (the launchpad's metadata server, the token creator's social profiles, in-protocol IPFS pins). Providers that hook directly into the launchpad's mint flow recover more fields than providers that wait for a curator to backfill them, which is the architectural reason coverage on fresh launches separates the leaderboard.
Does Jupiter cover BNB Chain or Base tokens?
No. Jupiter is Solana-only by design, so it appears with zero coverage on EVM chains by construction. The cross-chain headline value excludes Jupiter on chains it does not support so the comparison stays fair. On Solana Jupiter sits at 24.8% (p50, 24 h) on this benchmark.
How does OpenChainBench discover fresh tokens to test?
The harness subscribes to Mobula Pulse V2's WebSocket on Solana, BNB Chain and Base, scoped to known launchpads (pump.fun, Meteora DBC, Four.meme, Raydium CPMM, Zora, BaseApp, Bags, Moonshot). Every new mint triggers a metadata check on each provider in scope, and the result is recorded into Prometheus counters. Steady-state runs several hundred checks per provider per hour, which is the sample density that gives the percentile aggregates statistical meaning.
Why use a rolling rate instead of a single number for coverage?
Coverage drifts during the day. A launchpad releases dozens of tokens in a minute then quiets down, and provider coverage on the fast-launch burst is different from coverage during the lull. We use `quantile_over_time` on a one-hour rolling rate, sampled over 24 hours, so the headline is p50 of the hourly coverage rate rather than a flat average. The same shape as a latency benchmark, applied to a coverage ratio.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/metadata-coverage
