Skip to content

Collections

A collection is the top-level container for a drop. Every collection has a type (which determines its on-chain shape and which sales are valid), a backing contract, optionally a sale, and minted tokens.

TypeSupply modelWhen to use
OpenEditionUnlimitedMax distribution — every collector can mint
LimitedEditionFixed capScarcity-driven drops with a supply limit
OneOfOneExactly 1Unique, singular pieces
SeriesFixed, unique per tokenMultiple tokens with individual metadata
GenerativeSeriesFixed or openCode-driven art rendered at mint time

Editions (Open, Limited, OneOfOne) support both ERC-721 and ERC-1155. Series and generative are always ERC-721.

A collection moves through explicit statuses:

  1. Draft — configured but not deployed. Only the owner can see it.
  2. InProgress — deployment transaction submitted, awaiting confirmation.
  3. Live — contract deployed, sale is claimable.
  4. Migrated — imported from an external source.
  5. Disabled — frozen. No further mints.

The transition from DraftInProgressLive is managed by the deploy workflow.

  • Identifiersid (UUID, internal) and highlightId (public, URL-safe).
  • Contract — a deployed smart contract; type is derived from the collection type + token standard. See contracts.
  • Type-specific detailCollectionEditionDetail, CollectionSeriesDetail, or CollectionGenerativeDetail (mutually exclusive).
  • Sale — a draft collection has at most one sale at a time; a live collection can accept additional gated sales. See sales.
  • Media — logo, featured image, and the artwork/code the tokens reference.
  • Tokens — the minted NFTs. See tokens & metadata.
  • Royalty — optional EIP-2981 royalty recipient + amount.

Some contract implementations can back multiple collections (cheap to deploy a new collection against them); others are one-per-collection. The support matrix spells out which is which, but as a rule: LimitedEdition/OneOfOne on ERC-721, and all ERC-1155 editions, use reusable contracts.