Rarible vs SuperRare: Contract Standards, Royalties, and Indexing Differences

Rarible and SuperRare both power premium NFT experiences, but they diverge in how they structure contracts, enforce royalties, and index data. This deep-dive distills the practical trade‑offs for product, engineering, and business leaders choosing an approach for their next NFT initiative.

Summary: Rarible runs an open, multichain, aggregator-friendly stack with optional onchain royalty enforcement on RARI Chain; SuperRare runs a curated ERC‑721 network with default 10% creator royalties and a focused GraphQL API, optimized for 1/1 art and gallery-style drops. (docs.rarible.org)

TL;DR for decision‑makers

Choose Rarible if you want multichain coverage, marketplace aggregation, executable order flow, and options for hard royalty enforcement via RARI Chain (Ethereum L3). (docs.rarible.org)
Choose SuperRare if you need curated ERC‑721 primary markets, default 10% creator royalties on the SuperRare protocol, and a clean GraphQL for platform-native analytics. (docs.superrare.com)

1) Contract standards: how tokens are minted and represented

Rarible: ERC‑721, ERC‑1155, lazy minting, and protocol contracts

Token standards: Supports ERC‑721 and ERC‑1155 across EVM networks. (docs.rarible.org)
Core contracts (Ethereum mainnet examples):
- ERC721Rarible: 0xc9154424B823b10579895cCBE442d41b9Abd96Ed
- ERC1155Rarible: 0xB66a603f4cFe17e3D27B87a8BfCaD319856518B8
- ExchangeV2: 0x9757F2d2b135150BBeb65308D4a91804107cd8D6
- RoyaltiesRegistry (EVM-wide royalty resolution): 0xEa90CFad1b8e030B8Fd3E63D22074E0AEb8E0DCD (docs.rarible.org)
Lazy minting: signature-based minting defers onchain creation until purchase; available on Ethereum under Rarible’s shared collections. This keeps gas off the creator and helps test demand early. (help.rarible.com)
Royalty interfaces supported at the exchange layer: Rarible RoyaltiesV1, RoyaltiesV2, and ERC‑2981. This lets the protocol discover and pay royalties even for externally minted contracts. (docs.rarible.org)

Why it matters: if you’re shipping mass collections or game assets, ERC‑1155 is operationally cheaper (batch mints/transfers). If you’re shipping 1/1s or small editions with stronger provenance semantics, ERC‑721 is fine. Rarible supports both.

SuperRare: ERC‑721‑only with shared “SuperRare” and sovereign/series contracts

Standard: ERC‑721 only; SuperRare’s network is designed for 1/1 art. (help.superrare.com)
Shared V2 contract (aka “SUPR” on explorers): 0xb932a70A57673d89f4acfFBE830E8ed7f75Fb9e0. This is the historic, verified ERC‑721 contract for SuperRare V2. (etherscan.io)
Series/Sovereign contracts: artists and Spaces can launch branded ERC‑721 minting contracts to keep provenance and branding distinct while staying inside the SuperRare ecosystem. (help.superrare.com)

Why it matters: if your model is curated 1/1 art or limited primary drops with a gallery experience, SuperRare’s ERC‑721 focus and provenance narrative are aligned to that.

2) Royalties: standards, enforcement, and edge cases

The standards landscape

ERC‑2981 is the canonical interface for royalty lookup but is informational; markets choose whether to pay. It returns a single recipient and amount for a given sale price. (eips.ethereum.org)
Many ecosystems also query legacy interfaces (e.g., Rarible Royalties v1/v2) or a Royalties Registry to resolve overrides and splits. (docs.rarible.org)

Rarible’s approach

Multi-standard support: Rarible ExchangeV2 queries RoyaltiesV1, RoyaltiesV2, and ERC‑2981; it then pays out automatically when trades settle via the protocol. (docs.rarible.org)
Set/override royalties:
- In-app: add recipients and basis points (EIP‑2981 compatible; applies to trades on Rarible). (help.rarible.com)
- Externally: write to RoyaltiesRegistry via Etherscan (ETH and Polygon proxies) for collection-wide resolution. (help.rarible.com)
Policy toward marketplaces: Rarible publicly ceased aggregating orders from marketplaces that disabled royalties in 2023; by 2025, their docs and help center show API/front-end aggregation includes OpenSea listings again (Blur activity only). If you rely on cross‑market liquidity via Rarible’s API, confirm current aggregation scope during integration. (theblock.co)
Hard enforcement option: RARI Chain (Ethereum L3, Arbitrum tech) adds node‑level royalty checks for ERC‑721/1155 transfers. Transactions that circumvent specified royalty payments revert—moving royalties from “best practice” to “protocol rule.” For creators/brands who must guarantee rev‑share, this is the cleanest onchain enforcement available today. (rarichain.org)

Practical implication: On Ethereum L1 and most L2s, royalties remain policy- not protocol‑enforced. If you require guaranteed royalties for secondary markets, mint and transact on RARI Chain or bridge in with ERC‑2981 metadata preserved. (rarichain.org)

SuperRare’s approach

Default 10% creator royalties on secondary sales for transactions using the SuperRare protocol; works minted after the current Terms’ effective date default to 10% in the Royalty Registry (artists can adjust in specified cases). Buyers also pay a separate marketplace fee (commonly displayed as 3%) to the DAO. Primary sales route 85% to the artist and 15% to the SuperRare DAO. (campaigns.superrare.com)
Royalty Registry: SuperRare implements the Royalty Registry for certain contracts. Notably, their support docs indicate the registry overrides don’t apply to some V2 tokens, which matters if you’re trying to reroute royalties post‑mint. (help.superrare.com)
Collector royalties (new incentive): the first collector can receive a 1% decreasing royalty funded from the SuperRare network fee (not from the artist’s 10%), kicking in on the first secondary sale where the first collector isn’t a party (mint sale +2). This can stimulate early primary demand without reducing creator revenue. (medium.com)
Example split (RarePass): some drops (e.g., RarePass) define explicit secondary splits (e.g., 45% artists / 45% DAO / 10% company) from the 10% royalty. Ensure your legal and integrator teams respect these scheme‑specific splits. (campaigns.superrare.com)

Practical implication: SuperRare enforces creator royalties at the protocol layer for trades that invoke their protocol. If your secondary trading occurs elsewhere, enforcement depends on that venue’s policy and whether they honor the Royalty Registry. (campaigns.superrare.com)

3) Indexing and APIs: how you’ll ship data‑rich experiences

Rarible API and indexer

Scope: multichain NFT indexer with ownership, metadata, search, and executable market data (order book, bids) across major marketplaces; provides a single entry point and CDN-backed media delivery. (rarible.org)
Supported marketplaces: docs (mid‑2025) show listings from Rarible and OpenSea and activity capture from Blur. Always verify current coverage at build time. (docs.rarible.org)
Scale: published plans up to 20M requests/month with 100 req/s and 99.99% uptime; enterprise plans available. This matters for consumer apps and analytics dashboards. (rarible.org)
Indexer performance: Rarible has published detailed tuning notes (Kafka pipeline, time‑marks, node selection) to lower mint‑to‑index latency and handle spam on Polygon—useful for architects planning SLAs. (docs.rarible.org)

Takeaway: if you need cross‑chain search, floor tracking, and transaction building in one SDK/API with production‑grade rate limits, Rarible’s stack is purpose‑built. (rarible.org)

SuperRare Public API (GraphQL)

Scope: GraphQL endpoint for NFTs, collections, sales, auctions, events within the SuperRare ecosystem (includes fields like universalTokenId, creator/owner profiles, auction state). (help.superrare.com)
Rate limits: published standard tier is 5 requests/minute; plan for caching and pagination. (help.superrare.com)
Currency support surfaced in marketplace docs includes ETH, USDC, and $RARE splits on listings. (help.superrare.com)

Takeaway: great for curated-experience analytics and native marketplace surfaces; not intended as a broad NFT aggregator.

4) Concrete examples you can reuse

A. Query SuperRare activity with GraphQL

Use SR’s public playground to test. Note the rate limit and paginate.

# Recent events with basic NFT context
query GetRecentNftEvents {
  getNftEvents(filter: {}, pagination: { take: 10 }) {
    events {
      eventType
      createdAt
      nft {
        universalTokenId
        contractAddress
        tokenId
        metadata { name }
      }
      agent { defaultAddress }
      patient { defaultAddress }
    }
  }
}

Result fields match the docs (eventType, agent/patient actors). Cache aggressively in production. (help.superrare.com)

B. Resolve and set royalties for a Rarible‑indexed collection

First, check if your NFT implements ERC‑2981 (royaltyInfo) and/or Rarible Royalties v2. If not, you can register collection‑wide recipients in the RoyaltiesRegistry via the verified proxy contracts (ETH/Polygon). (docs.rarible.org)
For collections minted via Rarible, you can also set royalties directly in the UI (EIP‑2981 compatible), which Rarible’s Exchange will honor for protocol trades. (help.rarible.com)

C. Hard‑enforce royalties by design: deploy on RARI Chain

RARI Chain runs royalty checks at the node level for ERC‑721/1155 transfers; transactions that don’t satisfy configured royalty payments revert. For a marketplace launch with guaranteed creator revenue, mint and settle on RARI Chain or bridge assets in with ERC‑2981 intact. (rarichain.org)

D. Lazy mint to de‑risk gas on primary drops (Rarible)

Enable “Free minting” on Ethereum to list first, mint on purchase. This reduces upfront costs and can improve funnel conversion for experimental or long‑tail SKUs. Know that until purchase, items won’t appear cross‑market because the token hasn’t been minted yet. (help.rarible.com)

5) Emerging best practices (late‑2025)

Combine ERC‑2981 with a registry: Implement ERC‑2981 in your contracts and register overrides in a Royalties Registry to support multi‑recipient splits and post‑mint routing. This maximizes cross‑market compatibility. (eips.ethereum.org)
Decide early on enforcement vs reach:
- Need guaranteed payouts? Favor RARI Chain for onchain enforcement. (rarichain.org)
- Need maximum secondary reach? Use ERC‑2981 + registry on Ethereum mainnet/L2 and plan for marketplace policy variance.
Engineer for indexer realities: If you need real‑time UX after mints/listings, design with Rarible’s faster indexer and publish SLAs; otherwise, cache SuperRare GraphQL responses and implement queues for hydration. (docs.rarible.org)
Communicate royalties clearly to collectors: If you leverage SuperRare’s 1% Collector Royalty (funded from network fees), surface the benefit in your primary drop pages to incentivize early buys without reducing artist royalties. (medium.com)
Verify marketplace aggregation at build time: Rarible’s 2023 stance paused aggregation from some venues; their 2025 docs show OpenSea listings aggregated again while Blur listings aren’t. Check docs and run end‑to‑end tests before go‑live. (theblock.co)

6) Decision guide by use case

Brand/gaming drops with thousands of items across chains:
- Rarible API + ERC‑1155 for scale, optional lazy mint, and Execute API for order building. Consider RARI Chain if royalties must be non‑bypassable. (docs.rarible.org)
Fine art, curated 1/1s, gallery partnerships:
- SuperRare Spaces or Series contracts for brand‑aligned ERC‑721, default 10% royalty, DAO‑aligned fees, and a focused events API. (docs.superrare.com)
Data products and analytics:
- Rarible for multichain, multi‑market floor/activity; SuperRare API for deep artist/auction context within that ecosystem. (rarible.org)

7) Implementation pitfalls to avoid

Assuming all SuperRare tokens accept Royalty Registry overrides: SR docs note Registry won’t work on some V2 tokens—confirm before rerouting addresses. (help.superrare.com)
Underestimating rate limits: SuperRare’s public API standard tier is 5 req/min—batch, cache, and paginate; Rarible offers far higher ceilings but still plan retries and backoff. (help.superrare.com)
Ignoring marketplace policy drift: Royalty enforcement has shifted since 2023. If you architect for cross‑market royalties, prefer standards (ERC‑2981 + registry) and optionally anchor trading on RARI Chain for guaranteed payouts. (theblock.co)
Expecting lazy‑minted items to appear everywhere immediately: they’re not onchain until purchase, so aggregators can’t index them yet. Communicate this in UX. (help.rarible.com)

8) Quick reference: what’s unique right now

Rarible
- Multi‑standard royalty resolution (Royalties v1/v2 + ERC‑2981) at the exchange. (docs.rarible.org)
- RARI Chain with node‑level royalty checks for immutable enforcement. (rarichain.org)
- Multichain indexer + executable market data and enterprise‑grade quotas. (rarible.org)
SuperRare
- Default 10% creator royalty protocol‑side; curated ERC‑721 network. (campaigns.superrare.com)
- Spaces/Series allow branded ERC‑721 contracts inside SR’s curation model. (docs.superrare.com)
- New Collector Royalty incentive for first buyers, funded from network fees. (medium.com)

9) If you asked us to pick (contextual recommendations)

Enterprise IP holder with strict rev‑share requirements: Ship on RARI Chain to make royalties non‑optional; if you also want discovery on Ethereum, mirror listings via bridges while preserving ERC‑2981 metadata. (rarichain.org)
Museum/gallery initiative with curatorial control: Launch via a SuperRare Space, set commissions and schedules, and lean on SR’s default 10% creator royalty and auction primitives. (docs.superrare.com)
Consumer app needing broad coverage and search: Integrate Rarible API as your primary indexer and market data layer; enrich with SuperRare GraphQL for deeper SR‑specific context. (rarible.org)

Appendix: standards you’ll likely touch

ERC‑2981 (royaltyInfo): single‑recipient royalty lookup that markets may implement; pair with a registry for multi‑recipient splits. (eips.ethereum.org)
EIP‑712 (typed signatures): common across marketplaces and lazy mint flows; relevant for order signing and gasless listing UX. (eips.ethereum.org)

By aligning your contract choices (ERC‑721 vs ERC‑1155), royalty strategy (policy vs protocol enforcement), and indexing plan (aggregator vs curated API), you can ship NFT products that are both creator‑friendly and operationally scalable—and you’ll avoid the gotchas that have tripped up many teams in 2023–2025.