The standard every marketplace understands.

A conventional ERC-721 collection with a paid public mint, a fixed supply, a per-wallet cap and on-chain enumeration. Token ids are sequential from 1. This is the safest default: it uses OpenZeppelin's audited implementation end to end and there is no wallet, indexer or marketplace that will not recognise it.

• Paid public mint with a per-wallet cap and an owner-controlled sale toggle
• Owner mint for reserves, team allocations and airdrops
• ERC-721 Enumerable: totalSupply, tokenByIndex, tokenOfOwnerByIndex on-chain

Mint ten for roughly the gas of minting one.

Chiru Labs' ERC721A stores ownership lazily: a batch mint writes a single ownership slot for the whole run instead of one per token. For a drop where people mint five or ten at a time, that is a large, visible saving on the mint transaction — which is exactly the transaction your buyers pay for.

• Cheap batch mint: mint(quantity) writes one ownership record per batch
• Paid public mint with a per-wallet cap and an owner-controlled sale toggle
• Owner mint for reserves, team allocations and airdrops

Many editions, many supplies, one contract.

A multi-token contract where the owner creates token ids on demand, each with its own max supply, price and per-wallet cap, and anyone can then mint copies of an open id. One deployment covers a whole catalogue of editions, items or passes, and transfers can move several ids in one call.

• createToken() adds a new id with its own supply, price, wallet cap and sale state
• Public mint(id, amount) plus owner mint and owner batch mint across ids
• Per-id supply tracking via ERC1155Supply: totalSupply(id), exists(id)

An ERC-20 balance that mints and burns NFTs as whole units move.

A hybrid token: one fungible balance backs a set of NFTs, and crossing a whole-unit boundary mints or burns one automatically. Holding 3.4 tokens means holding 3 NFTs; sending 0.5 away burns one; receiving 0.6 back mints a fresh one. The point is native fractionalisation — the collection can trade in an AMM pool like any ERC-20 while still being a set of NFTs.

• Full ERC-20 surface: transfer, approve, allowance, transferFrom, 18 decimals
• NFTs mint and burn automatically as balances cross whole units
• Burned ids are recycled, so the id space stays bounded by max NFT supply

Community standard, not a finalized EIP. No EIP number, no reference implementation, no standardised behaviour — deployed ERC-404s differ from one another.

A badge that can never be sold or moved.

A minimal soulbound token: the owner issues badges to addresses, and those badges are permanently bound to the wallet that received them. Every wallet-to-wallet transfer path reverts, approvals are disabled outright, and locked(tokenId) reports true for the life of the token, so ERC-5192-aware wallets label it correctly instead of offering a Sell button.

• ERC-5192 locked(tokenId) plus the Locked event, emitted at issuance
• Owner-only issue() and issueBatch() for one-by-one or bulk distribution
• Owner revoke() burns a badge; optional holder-side burn so people can renounce

Split ownership from use, with an expiry the chain enforces.

An ERC-721 collection that carries a second role alongside the owner: a user, with a UNIX expiry. The owner keeps the asset and can still sell it; the user holds time-limited rights that lapse on their own, with no transaction needed to end the rental. userOf returns the zero address the moment the clock runs out, and the record clears automatically when the token changes hands.

• ERC-4907 setUser / userOf / userExpires with the UpdateUser event
• Rentals expire on their own; no transaction needed to reclaim the role
• The user record clears on transfer, so a sale never carries a stale renter