External asset key
A stable ticket, certificate, serial number, item, or entitlement reference prevents the same business object from being minted twice.
Delivery model
Give every asset a durable identity before it reaches the chain.
Metadata version
An approved, published document and media manifest with content hashes, mutability, and authority recorded.
Token identity
Collection contract, token ID, owner, transaction evidence, and the observed metadata pointer after confirmation.
Metadata as a resource
Publish a version—not an editable draft.
The mint request should reference a published metadata version ID. The service records its URI, digest, schema, and authority before signing the token transaction.
- Validate schema, media type, dimensions, and file size.
- Normalize and hash deterministic metadata.
- Record mutability and update authority.
- Keep publication and mint status separate.
- Monitor availability and unauthorized changes.
{
"schema_version": "collection-item/1.0",
"name": "Founders Pass #1842",
"description": "Membership credential for the 2026 cohort.",
"image": "ipfs://bafy.../pass-1842.png",
"attributes": [
{ "trait_type": "Cohort", "value": "2026" },
{ "trait_type": "Tier", "value": "Founders" }
],
"external_reference": "member_1842"
}Illustrative metadata document. Replace example values and apply your own authentication, authorization, and signing policy.
Standard choice
ERC-721 and ERC-1155 serve different inventory models.
721
Individual identity
Each token has an individual ID and owner. Use it for individually addressable collectibles, credentials, tickets, and tokenized objects.
- Token ID allocation or event parsing
- Per-token ownership verification
- Token URI and metadata version
- Unique external asset constraint
1155
Multi-token inventory
One contract manages many token IDs, each with its own supply. Use it for mixed collections, editions, and coherent item batches.
- Contract + token ID asset identity
- Per-ID quantity and cap
- URI substitution rules
- Item-level batch reconciliation
Confirmation contract
Separate ownership, content, and indexing status.
Blockchain delivery
Verify receipt or signature, expected event or instruction, token ID, recipient owner, collection, and configured finality.
Content integrity
Verify the observed URI or metadata account, content hash, referenced media, and intended mutability state.
Presentation indexing
Track wallets, explorers, or marketplaces separately. A delayed cache should not change the canonical ownership result.
Batch delivery
Represent the batch as a parent with item evidence.
A large campaign may span several transactions. Preserve the external asset key, metadata version, requested recipient, token ID, transaction, and final status for every item.
FAQ
NFT minting questions.
What makes an NFT mint request unique?
Use both an idempotency key for the HTTP action and a stable external asset reference for the underlying ticket, certificate, serial number, collectible, or business object.
Should metadata be published before minting?
Usually yes. Validate and publish an approved metadata version and its media first, then bind the mint operation to that immutable version so a draft cannot change while the transaction is in flight.
When should a product use ERC-721 instead of ERC-1155?
Use ERC-721 when each item needs individual identity and ownership. Use ERC-1155 when one contract should manage many token IDs with independent quantities and useful batch behavior.
Is marketplace indexing part of mint confirmation?
No. Chain ownership and token URI evidence can be confirmed independently. Marketplace or explorer indexing is a separate, provider-specific presentation status.
Build from explicit contracts
Use the reference architecture as a starting point.
Define assets, authorities, idempotency, confirmation, and reconciliation before connecting a production signer.