Best NFT collection metadata API: Moralis, Alchemy, OpenSea benchmarked
Share of metadata fields (name, image, description, floor_eth, external_url) populated across 50 Ethereum blue-chip NFT collections, audited every 6 hours.
TL;DR. As of , Moralis leads field coverage at 97.1% (24h avg) on Best NFT collection metadata API: Moralis, Alchemy, OpenSea benchmarked. Source: OpenChainBench, https://openchainbench.com/benchmarks/nft-collection-metadata.
This benchmark measures what every NFT marketplace, portfolio tracker and wallet hits when it tries to render a collection card. Name, image, description, floor_eth and external_url. The five fields a UI needs to render a tradeable collection tile instead of a bare contract address. Provider marketing pages quote "10M+ NFTs indexed" or "real-time floor prices", but coverage on established blue-chip collections is the floor of what any production app can rely on, not the ceiling. The harness queries Moralis, Alchemy and OpenSea every six hours for the same 50 Ethereum blue-chip collections (BAYC, CryptoPunks, Azuki, Pudgy Penguins, Doodles and others) and records which of the five fields each provider returned. Coverage is the share of (provider, collection, field) combinations that returned a populated value, computed as a rolling rate so the leaderboard reflects what the API is doing today. This bench is the established-collection companion to the fresh-launch metadata-coverage bench. one tests the worst case (tokens two minutes old), this tests the best case (collections everyone has had years to index). On the current 24h window Moralis leads at 97.1%.
Methodology
We benchmark how complete each NFT data API's collection-metadata response is for a fixed list of 50 Ethereum blue-chip collections. Every six hours the harness asks each provider for each collection and records whether five canonical fields (`name`, `image`, `description`, `floor_eth`, `external_url`) came back populated. The aggregate is the share of (provider, collection, field) combinations that returned a populated value across all checks in the window. A value of 100% means every field was returned for every collection on every check; a value of 60% means two-fifths of the fields were missing on average. Sort order on this page is descending, so the highest coverage shows first, which is the inverse of latency benchmarks. Apple-to-apple field semantics are documented in the methodology so readers can replicate the harness against their own collection list.
Frequently asked
Which API is best for NFT collection metadata?
On the 50 Ethereum blue-chip set this benchmark scores, Moralis currently leads at 97.1% (p50, 24 h). The benchmark targets the best case for any NFT API. collections that everyone has had years to index. so the spread between providers reflects refresh discipline and field completeness rather than catalogue size. For fresh NFT mints (the worst case) the picture is different and that benchmark is not yet live on OpenChainBench.
Why only 50 collections?
A fixed collection set keeps the comparison apple-to-apple. Every provider is asked about the same collections on the same cadence, so coverage differences cannot be explained away by 'the other provider tested an easier collection list'. 50 is the trade-off between statistical density (1000 field checks per provider per day) and respecting each provider's free-tier rate limit. The list is committed in the harness repo and only changes via PR.
Does this benchmark test fresh NFT mints?
No. This bench tests established blue-chip collections (BAYC, CryptoPunks, Azuki and 47 others). Fresh-mint NFT metadata coverage is a different benchmark that would need a launchpad-aware discovery loop, similar to the fresh-launch token metadata-coverage bench. Treat this number as the floor of what any provider can deliver. coverage on fresh mints will always be lower.
What's the difference between Moralis NFT API and OpenSea API?
Moralis is a general-purpose Web3 data API. its NFT endpoint pulls from Moralis's own EVM indexer plus enriched marketplace data. OpenSea is the marketplace. its API is the canonical source for marketplace-side fields (description, external_url, floor) on collections OpenSea has listed. Moralis covers some collections OpenSea has delisted; OpenSea covers some marketplace-specific fields Moralis does not expose. Both appear in this bench because they are different layers of the stack.
Why is floor_eth the most often-missing field?
floor_eth is the only field on the list that requires a live marketplace lookup. Name, image, description and external_url are contract-level or off-chain metadata that the provider can cache and serve for hours. Floor changes whenever someone lists or delists, so providers either refresh aggressively (paying the marketplace API cost) or let it go stale. The 6-hour cadence on this bench is long enough to surface refresh failures, short enough to be useful as a leaderboard.
How does the apple-to-apple field semantics work?
Each provider returns slightly different field shapes. We normalise as follows: `name`, `description` and `external_url` count on any non-empty string. `image` counts on a non-empty string URL (each provider gets one chance, picked from the documented preferred field; no OR-of-multiple-URLs tricks). `floor_eth` counts on any positive number in ETH. This normalisation is committed in the harness repo and only changes via PR.
Why use a rolling rate instead of a single number for coverage?
Coverage drifts during the day. A marketplace can rate-limit one provider for an hour and that provider's coverage drops until the limit resets. 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. Same shape as a latency benchmark, applied to a coverage ratio.
Source code github.com/ChainBench/OpenChainBench/tree/main/harnesses/nft-metadata-coverage