Understand OpenRarity & AuroraRarity

What a rarity rank tells you

A rank compares artwork within one collection. Rank 1 is rarest under that collection’s method. A score is the number used in the calculation; a rank is its resulting position after the sorting rules are applied. A higher score contributes to rarity, but unique traits have sorting priority.

Published rankings use metadata and confirmed mint records for one contract on one network. Before minting, creators can preview OpenRarity using saved artwork traits, including after deploying a contract. Search, filters, page changes and view modes do not change the comparison group. Rarity describes recorded scarcity, not artistic quality, popularity or sale price.

Preview rarity before minting

Your creator collection calculates an OpenRarity preview from all saved artwork and traits, including artwork hidden from the public gallery. Each artwork counts once with equal weight. No deployment, mint or wallet transaction is needed. Save trait edits, add artwork or remove artwork to update the preview, then choose Rarest first to browse the results.

Deployment alone does not remove the preview. It remains available while the selected contract has no known mint history on that network, including after an eligible ArtLab re-render before the first mint. The preview uses the OpenRarity formula below and stays private to your creator workspace; public galleries do not receive draft traits or preview ranks.

Once minted or burned artwork is indexed, rankings use published metadata and confirmed records for the selected network. Unrevealed or incomplete published data does not switch back to a draft preview. Published ERC-1155 rankings use AuroraRarity with actual minted copy counts, so they can differ from the equal-weight OpenRarity artwork preview.

Numeric traits, display-type traits or repeated trait names prevent an OpenRarity preview. Collections without traits show a prompt to add them.

OpenRarity: the open standard for unique NFTs

OpenRarity is a community-developed, open-source method. Aurora follows its information-content calculation with Double Sort and Trait Count. The project publishes the methodology and reference implementation so the calculation can be inspected and reproduced.

OpenSea also uses OpenRarity. Matching ranks requires the same collection data and settings; differences in indexing can produce different results.

OpenRarity project

OpenRarity methodology

OpenRarity reference implementation

OpenRarity formula, explained

Let N be the number of NFTs. A trait type t is a category such as Color; v is a value such as Blue. The frequency n(t,v) is how many NFTs have that value. Σ means “add these terms together”; log₂ is the base-two logarithm.

A trait found on half the collection contributes 1 bit of information; on a quarter, 2 bits; on every NFT, 0 bits. Add the contributions for an NFT, then divide by H, the collection’s total trait entropy. Entropy is the sum of the average information in each trait category. The same divisor applies to every NFT in that collection.

OpenRarity information-content calculation

OpenRarity example: one Gold, three Blue

Imagine four NFTs with only a Color trait. One is Gold and three are Blue. Their trait counts are all 1, so that category contributes zero. Gold has probability 1/4 and Blue has probability 3/4. H = 0.25 × 2 + 0.75 × log₂(4/3) ≈ 0.8113. The Gold trait is also unique, so Double Sort places that NFT first.

AuroraRarity: our standard for ERC-1155 editions

AuroraRarity is Aurora’s own rarity standard for edition collections. It extends information-content rarity in two explicit ways: trait frequencies count minted copies, and a separate edition-scarcity term accounts for how many copies of each artwork have been minted.

An artwork with one copy and an artwork with 100 copies should not automatically have identical rarity just because their traits match. AuroraRarity recognizes both the rarity of their traits across all minted copies and the relative size of each edition. It ranks artwork types, not individual copies, so every holder of the same token ID sees the same rank.

The formula has no custom artist weighting, market-price input or ownership multiplier. Every trait category, the derived trait-count category and the edition distribution contributes once. AuroraRarity is independently defined by Aurora; it is not an official ERC-1155 version of OpenRarity or a promise that another marketplace will display the same rank.

Exactly what AuroraRarity counts

• Use each artwork’s confirmed lifetime minted copies, including creator mints and public mints. The collection total is the sum of those copy counts.
• Exclude unminted uploads, pending transactions, planned edition sizes and quantities reserved for future releases. A displayed minted count is not a maximum supply or a promise that no more copies can be minted.
• Use the published traits associated with each minted artwork. All copies of a token ID carry that artwork’s traits and contribute its full copy count to their frequencies.
• Do not use the number of holders or anyone’s current wallet balance. Transfers between holders do not change the calculation.
• Use lifetime mint counts rather than circulating supply after burns. If Aurora detects burned or incomplete records that prevent a complete comparison, it withholds ranks; it does not estimate the missing copies.

AuroraRarity formula, explained

Let mᵢ be the confirmed minted copies of artwork i, and M = Σⱼ mⱼ the total minted copies. C(t,v) is the sum of copies belonging to every artwork with value v for trait type t. A missing trait is also a value category. The derived trait-count category is included.

First calculate trait probabilities across copies, then add edition scarcity. Dividing by the combined entropy puts the result on a consistent scale for that collection. All logarithms are base two, and Σ means addition over the indicated categories or artworks.

AuroraRarity example: three artworks, ten copies

Consider artwork A with 1 Gold copy, B with 3 Blue copies and C with 6 Blue copies. Color is the only trait, so every artwork’s trait count is 1. There are 10 minted copies in total: Gold appears on 10% of copies and Blue on 90%. Counting only artwork types would give Gold 1/3; AuroraRarity deliberately uses 1/10.

The color entropy is approximately 0.4690. The edition entropy for shares 1/10, 3/10 and 6/10 is approximately 1.2955. The combined divisor is approximately 1.7645. Calculations use full precision; the table is rounded.

Colored trait rarity badges

Each trait card has a small colored badge when its frequency is available. The badge describes how often that trait value occurs across the whole comparison group. It does not describe the artwork’s overall rank or change the OpenRarity or AuroraRarity formula.

Workspace previews and ERC-721 count artworks equally. ERC-1155 badges use the percentage of minted copies carrying the trait. Filtering and pagination never change a badge. Draft traits without calculated frequencies and unrevealed traits do not receive badges.

Trait count, missing values, sorting and ties

OpenRarity reference sorting and tie rules

• Trait names and text values are compared without case or surrounding whitespace. Blue, blue and a value with spaces around Blue have the same frequency.
• A missing category contributes its own absence frequency. A missing Color, an explicit empty text value and the text None are separate categories. Empty text and None are excluded from the derived trait count.
• Trait Count adds a category for the number of present, nonempty, non-None traits on each artwork. It is derived automatically; creators should not add a meta_trait:trait_count field themselves.
• OpenRarity Double Sort orders NFTs by the number of trait values found on exactly one NFT, then by descending score. The derived trait-count value can also be unique. Adjacent equal scores share a rank under the reference rule.
• AuroraRarity first orders artwork by the number of trait values found on exactly one minted copy, then by descending score. A trait on one artwork with 20 copies is not copy-unique. The edition ID is not counted as a unique metadata trait, and missing categories do not add unique-trait priority.
• AuroraRarity ties require the same unique-trait count and equal scores. Both methods compare scores with a relative tolerance of 0.000000001. Shared ranks skip subsequent positions: 1, 2, 2, 4. Aurora uses artwork IDs only to keep tied rows in a stable order, not to give them different ranks.

When ranks appear or change

The creator workspace previews ranks from saved artwork traits before minting, including for deployed collections with no known mint history on the selected network. Once mint history is known, it uses published data, as public galleries do. If minting is already known but its records are still being indexed, rankings wait for those records. Private metadata edits are drafts until published. Unrevealed traits stay private, and published rankings wait until all indexed minted artwork is revealed and its metadata and mint records are complete.

Ranking requires distinct trait names and text values, without numeric or special display-type traits. If any artwork contains an unsupported trait, Aurora keeps the available traits visible and withholds ranks for the collection. Numeric traits are not silently dropped from a partial score. ERC-721 also needs published traits; ERC-1155 can use edition scarcity alone.

New mints, extra copies and published metadata changes can change scores and ranks across the entire collection. Indexing happens after transactions are confirmed. External mints, detected burns, gaps or missing records can keep ranks unavailable until a complete comparison is possible.

Edit artwork metadata and trait CSVs

Filter traits and choose Grid, Compact, List or Compact list