Cardano NFTs are native assets: the ledger itself tracks them, with no ERC-721-style contract required. A Cardano marketplace therefore does not call a token contract to transfer items; it locks NFTs in script-controlled UTxOs with a price in the datum and lets buyers spend them. Understanding that eUTxO model is most of the learning curve.
How Cardano NFTs are minted
Every native asset belongs to a minting policy, a script whose hash becomes the asset's policy ID. The policy decides who can mint or burn. For NFTs, the classic policy is a simple native script: "this key may mint, but only before slot X." After that slot, nobody can mint more under the policy, which is how collections prove fixed supply. Each NFT is a policy ID plus an asset name, with a quantity of one.
Because the ledger handles transfers, sending an NFT is just an ordinary transaction output. There is no approval step, so the "approve-all" phishing pattern common on EVM chains does not apply in the same way, though malicious transaction signing does.
One quirk: every UTxO must carry a minimum amount of ADA. Wallets bundle a small ADA deposit with each NFT, which comes back when the output is spent.
CIP-25 vs CIP-68 metadata
Cardano Improvement Proposals define metadata conventions; the CIP repository is the primary reference.
| CIP-25 | CIP-68 | |
|---|---|---|
| Where metadata lives | Transaction metadata (label 721) in the minting transaction | Datum attached to a separate reference token (label 100) held at a script address |
| Can scripts read it? | No; it is off-ledger history | Yes; Plutus scripts can read the datum |
| Updatable? | Only by minting again (marketplaces use the latest mint transaction) | Yes, by spending and recreating the reference output, if the script allows |
| Typical use | Static art and PFP collections | Game items, dynamic NFTs, on-chain logic that depends on traits |
A CIP-68 NFT is actually a pair: the user token (label 222) that sits in the holder's wallet and the reference token (label 100) that carries the datum. Your marketplace and indexer need to support both standards, since most older collections use CIP-25.
Marketplace contracts in the eUTxO model
A listing on Cardano is typically a UTxO containing the NFT, sent to a marketplace validator address, with a datum that records the seller's address, the price and any fee or royalty outputs. To buy, a transaction spends that UTxO and must include outputs paying the seller (and the marketplace and creator) as the datum requires. To cancel, the seller signs a transaction spending it back.
This design has a nice property: each listing is independent, so many buyers can purchase different items in the same block without contention. The famous "concurrency problem" on Cardano appears when many users need the same shared UTxO, for example a single pool or a global order book. Collection offers and AMM-style pools therefore need batching or off-chain order matching.
Validators are written in Plutus or, increasingly, in Aiken, a purpose-built language that compiles to efficient Plutus Core. Aiken's lower execution costs matter because transaction fees depend on script size and execution units.
Components
- Validators: listing, offer and (optionally) auction scripts, plus royalty enforcement logic.
- Off-chain transaction building: libraries such as Lucid Evolution, Mesh or cardano-serialization-lib build and balance transactions in the browser or backend.
- Wallet connection: CIP-30 is the standard dApp-wallet bridge supported by Eternl, Lace, Vespr and others.
- Indexing: db-sync, Kupo and Ogmios, or hosted APIs like Blockfrost and Koios, to track listings, sales and metadata.
- Royalties: CIP-27 defines a royalty token per policy; your buy validator can require a royalty output.
- Front end: storefronts, filters by policy and traits, and sale history.
Build steps
- Decide supported metadata standards (CIP-25 and CIP-68) and royalty handling.
- Write listing, purchase and cancel validators in Aiken with property tests.
- Build transaction construction and test on the preview or preprod testnet.
- Stand up indexing and a metadata cache, including IPFS image proxying.
- Integrate CIP-30 wallets and handle min-ADA and fee display clearly.
- Audit the validators; double-satisfaction bugs, where one payment output satisfies two listings in the same transaction, are a classic Cardano marketplace flaw.
Market reality
Cardano has a loyal community and an active, if modest, NFT scene, but its volume is small next to Ethereum, Solana and Bitcoin Ordinals, and much of it runs through a few established marketplaces. Plutus and Aiken talent is scarcer than Solidity talent. A new Cardano marketplace makes sense when you are serving a specific Cardano community, game or brand, not as a general-purpose competitor. If you need reach across ecosystems, see cross-chain NFT marketplace development; general marketplace design is in NFT marketplace development. Teams already building on Cardano for token launches may find IDO launchpads on Cardano relevant too.
Frequently asked questions
Do Cardano NFTs need a smart contract?
Not for minting or transferring. A native-script minting policy is enough. Smart contracts (validators) are needed for marketplace logic like escrowed listings and offers.
Should I use CIP-25 or CIP-68?
CIP-25 is simpler and fine for static collections. Use CIP-68 when metadata must change or be read by on-chain scripts, such as for game items.
What is a policy ID?
The hash of the minting policy script. It identifies the collection, and a time-locked policy proves no more tokens can be minted after a set slot.
Is Aiken required?
No, but it is now the most common choice for new validators because it is easier to write and produces cheaper scripts than older Plutus tooling.