NFT Rarity Evaluation Tool Development
When a user looks at their token from a collection of 10,000 pieces, the first question is: how rare is it? "Rare" seems like an obvious concept, but behind it stands non-trivial mathematics: different calculation algorithms give different ratings for the same token, and the choice of methodology directly affects perceived value.
Rarity Calculation Methodologies
Trait Rarity Score — basic and most common approach. For each token attribute, we take its rarity: 1 / (count_of_tokens_with_this_trait / total_supply). Total score is the sum across all traits. Problem: collections with different numbers of attributes aren't comparable, and tokens with many traits get an advantage just from quantity.
Statistical Rarity — product of trait probabilities. A token is rare only if all its attributes are rare simultaneously. More intuitively fair, but mathematically suppresses tokens with one extremely rare trait.
Jaccard Distance / Information Content — more academic approaches used in tools like Rarity Sniper and trackers based on rarity.tools. Information Content calculates −log2(p) for each trait, giving a more balanced distribution without explosive score growth for unique traits.
Trait Normalization — adjustment for average number of traits in collection. If the average token has 5 attributes and a specific one has 8, its score is divided by a correction coefficient. Implemented in OpenRarity — an open standard that OpenSea now actively promotes.
For a serious tool, it makes sense to show multiple methodologies in parallel — users choose which to trust.
Data Sources and Indexing
NFT collection metadata is stored either in IPFS (collection CID) or on centralized servers (via tokenURI). To calculate rarity, you need to download and parse the entire collection's metadata.
Data collection strategy:
- Read
contractURIortokenURI(0..n)from contract via batch RPC calls (eth_call multicall via Multicall3) - For IPFS — resolve gateway (Cloudflare IPFS, Pinata, or own IPFS node) and download JSON in batches
- Handle edge-cases: tokens with
nulltraits (counted as separate "None" attribute), traits with numeric values (require binning or separate processing), metadata refresh after reveal
Build index in PostgreSQL or Redis: table token_traits(collection_id, token_id, trait_type, trait_value) + aggregates for each trait. Recalculate rarity after metadata update — incrementally.
Implementation and API
Backend service on Node.js/Go accepts contract address, determines chain (via chainId), loads and indexes collection, computes scores by selected methodologies. Result — endpoint /rarity/{contract}/{tokenId} with full breakdown by traits.
Frontend displays:
| Attribute | Value | Frequency | Rarity score |
|---|---|---|---|
| Background | Cosmic Purple | 3.2% | 31.25 |
| Eyes | Laser | 0.8% | 125.0 |
| Mouth | Gold Grill | 1.5% | 66.67 |
Plus overall token rank in collection and rarity percentile.
Important detail: cache results aggressively. Collection metadata after reveal doesn't change — TTL can be very long. First calculation of a 10k token collection takes seconds, subsequent queries — milliseconds.
Marketplace Integration
If the tool is embedded in an existing marketplace or NFT dashboard, rarity-score is passed as an attribute when displaying the token. OpenRarity provides npm package @openrarity/rarity-scorer for client-side integration without custom backend — suitable for small collections that fit entirely in browser memory.







