NFT marketplace smart contracts represent listings, offers, auctions, settlement, cancellation, fee routing, royalties, and administrative controls. ERC-721 or ERC-1155 describes the asset; it does not automatically create a safe marketplace.
A builder should compare marketplace contracts with the fee and order behavior in the OpenSea marketplace review, the operational layers in the NFT marketplace infrastructure guide, and the payment triggers in NFT passive income models because contract events become the source for settlement and support workflows.
NFT smart contracts explained
An NFT smart contract is code deployed on a blockchain that creates tokens and controls how ownership is recorded and transferred. When an NFT is minted, the contract assigns a token ID to an owner address. When it is sold or transferred, the contract updates that ownership record after checking the sender’s authority and the transfer rules.
| Contract function | What it does | What a user can verify |
|---|---|---|
| Minting | Creates a token ID and assigns its first owner | Mint transaction, contract address, token ID, and owner |
| Ownership | Records who controls an ERC-721 token or an ERC-1155 balance | Owner address or account balance onchain |
| Approval | Allows a marketplace or operator to transfer a token under defined permission | Approved address, operator scope, and revocation transaction |
| Transfer | Moves the token between addresses when the rules are satisfied | Sender, recipient, token ID, and transaction status |
| Metadata reference | Points wallets and marketplaces to the name, image, description, and traits | Token URI, media availability, and displayed attributes |
| Administrative controls | May allow minting, pausing, burning, or metadata updates | Admin address, role permissions, and contract events |
The contract normally records the token’s owner, supply, approvals, transfer history, and a metadata reference. It does not necessarily store the artwork itself.
As Hedera’s explanation of NFT smart contracts, the token ID and metadata identify the asset, while smart-contract logic handles minting and ownership changes. A smart contract is executable computer code, not automatically a legal agreement about copyright, refunds, or commercial rights.
NFT contracts and marketplace contracts
The NFT contract and marketplace contract have different jobs. The NFT contract defines the asset, creates token IDs, records ownership, and enforces approvals and transfers. The marketplace contract coordinates a sale: it validates the listing or offer, collects payment, transfers the NFT, routes fees, and closes or cancels the order.
This separation matters because owning a valid NFT does not mean it is actively listed, and signing a marketplace order does not change ownership until settlement succeeds. A buyer should therefore verify both addresses: the collection contract identifies the NFT, while the marketplace contract or spender identifies the software receiving transfer permission.
ERC-721 and ERC-1155 change the marketplace design
ERC-721 is commonly used when every token ID represents one independently owned item. It fits one-of-one art, unique game assets, land parcels, and collectibles whose ownership is checked token by token. ERC-1155 can represent multiple copies of the same token ID, which is useful for game consumables, tickets, editions, or items issued in quantity.
| Collection model | Practical fit | Marketplace behavior to test |
|---|---|---|
| ERC-721 unique token | One-of-one art, individual characters, land, or unique equipment | The order must identify one contract and one token ID, then verify its current owner |
| ERC-1155 single edition | Several copies of the same artwork or membership tier | The listing must include quantity and reject a purchase larger than the seller’s balance |
| ERC-1155 mixed inventory | Game items, consumables, tickets, or bundled asset types | Partial fills, remaining quantity, batch transfers, and per-token metadata need testing |
The standard changes what an order must contain. An ERC-721 listing normally sells one token ID. An ERC-1155 listing may offer 20 copies while a buyer purchases only three, so the marketplace must update the remaining quantity without closing the entire order. A cancellation must invalidate whatever quantity remains, and the settlement event must show how many units changed hands.
Approvals also look different to the user. A token-specific ERC-721 approval can authorise one NFT, while an operator approval may cover every token from that collection. ERC-1155 commonly uses operator approval for a wallet’s balances under the contract. A marketplace can require broader permission for convenience, but the wallet prompt should make that scope visible and the user should know how to revoke it.
Escrow and lazy listing designs
An escrow marketplace transfers the NFT into the marketplace contract when the seller lists it. That makes availability simple to verify, but the seller pays more gas and loses use of the asset while it is listed. A lazy listing keeps the NFT in the seller’s wallet and records an off-chain signature containing the token, price, chain, expiry, nonce, and marketplace address. It reduces listing cost and preserves custody, but the contract must validate the signature and the seller still needs an on-chain path to invalidate it.
| Design | Asset location before sale | Main benefit | Main failure to test |
|---|---|---|---|
| Escrow listing | Marketplace contract | The contract can confirm the asset is held | Locked inventory, failed cancellation, and custody exposure |
| Lazy listing | Seller wallet | Lower listing friction and continued asset utility | Replay, stale approval, changed price, or asset moved before purchase |
For a game marketplace, the choice affects more than gas. Escrow can prevent an item from being equipped while listed; lazy listing preserves the player asset but requires the game and marketplace to handle a listing that becomes unfillable when ownership changes.
Listing and offer lifecycle
A fixed listing should move through create, validate, buy, settle, and cancel states. Offers need expiry, nonce, chain ID, spender checks, and cancellation. Every state should emit events that an indexer can reconcile.
Offers need a payment model that the contract can actually pull. A native coin offer usually cannot be withdrawn from the buyer’s wallet later without a new signed transaction, while an approved ERC-20 such as WETH or USDC can be held in escrow or transferred when the seller accepts. The order record should therefore include the currency, amount, expiry, nonce, buyer, seller, token ID, and cancellation status rather than storing only a headline price.
Auction settlement needs its own state machine. An English auction must handle higher bids, refunds, the close time, and the final settlement caller; a Dutch auction must calculate the current price from time and reject stale purchases. A pull-based refund balance is safer than sending money immediately to every outbid bidder, because a failed refund callback should not freeze the whole auction. A short end-time extension also reduces last-second bid sniping.
A 0.5 ETH NFT sale from signature to settlement
Consider an ERC-721 NFT listed for 0.5 ETH through a signed order. The seller keeps the NFT in the wallet but approves the marketplace contract to transfer it. The signed listing identifies the collection contract, token ID, seller, price, expiry, nonce, chain ID, and marketplace address. No ownership change occurs when that signature is created.
When the buyer submits the purchase, the marketplace contract checks that the order has not expired or been cancelled, the signature belongs to the seller, the seller still owns the NFT, and the transfer approval remains valid. It then marks the order as filled, processes payment, routes the NFT to the buyer, and emits events that the marketplace can use to update the item page.
The following distribution is illustrative, not a statement of one marketplace’s live fees:
| Settlement line | Example amount | Contract action |
|---|---|---|
| Buyer payment | 0.5000 ETH | Received by the settlement function |
| Marketplace fee at 2.5% | 0.0125 ETH | Routed to the marketplace fee recipient |
| Creator royalty at 5% | 0.0250 ETH | Routed to the royalty recipient if the marketplace enforces it |
| Seller proceeds | 0.4625 ETH | Sent or credited to the seller before any seller-side gas cost |
If the NFT transfer fails, the payment should not be left completed while ownership remains unchanged. If the payment recipient cannot receive ETH, the safest response depends on the contract design: the transaction can revert, or the amount can be credited to a withdrawable balance. This is why payment routing, transfer order, state updates, and reentrancy protection must be tested together rather than as separate feature checkboxes.
Royalties and fee routing
Royalty information can follow EIP-2981, while contract libraries such as OpenZeppelin ERC-721 and OpenZeppelin ERC-1155 help with standard asset behavior. Marketplace enforcement still needs product policy.
A concrete example helps here: show what happens to one listed item from discovery to signature to settlement, then explain where fees, royalties, and approvals enter the path.
EIP-2981 makes royalty information readable, not universally enforceable. A marketplace can query the creator address and royalty amount, but another venue may choose a different policy or ignore the result. If creator revenue is essential, test the actual transfer path, the selected marketplace, aggregator behavior, and the collection’s enforcement logic instead of treating a royalty field as a guaranteed payment.
Security tests
Test reentrancy, replay, expired orders, wrong-chain signatures, admin key compromise, pause behavior, and partial fills. The goal is not a long audit checklist; it is proving the marketplace fails closed when the order is unsafe.
The highest-value tests should model the failure a buyer or seller can actually experience. A purchase should reject a changed price rather than execute a bait-and-switch; a signed order should be bound to the chain ID and marketplace address; and a cancelled or consumed nonce should not execute again. For settlement code, update order state before external calls and use a reentrancy guard around payment and transfer paths.
A Polygon user reviewing Rarible reported that the network experience lacked custom-contract support and metadata freezing in this network-specific contract review, collected on August 11, 2026. That is not evidence that a marketplace contract is unsafe, and it may depend on the network and product version. It is still a useful implementation boundary: test contract coverage, metadata immutability, and upgrade behavior on the exact chain selected for launch.
Conclusion
A marketplace contract should be judged by its order lifecycle and failure behavior. If the article helps a builder test expired orders, wrong-chain signatures, royalty routing, and event indexing, it has done more than repeat token standards. The next engineering check is the order lifecycle test. A safe contract path handles creation, expiry, cancellation, settlement, royalties, indexing, and pause behavior without relying on assumptions.
Frequently asked questions
What information is stored in an NFT smart contract?
The contract usually records token IDs, ownership, balances, approvals, transfer rules, supply, and a metadata URI. The image or video is often stored separately and referenced through metadata.
Does the NFT contract also handle marketplace listings?
Not necessarily. The NFT contract manages the token, while a separate marketplace contract commonly manages listings, offers, auctions, payment, fees, and settlement.
Can a marketplace transfer an NFT without permission?
It needs permission through ownership, a token-specific approval, or an operator approval recognised by the NFT contract. Buyers and sellers should check the approved spender before signing.
Does an NFT royalty field guarantee payment?
No. A royalty standard can communicate the recipient and amount, but payment still depends on marketplace policy and the actual settlement path.
Disclaimer: This article is for research and editorial comparison purposes only. It does not constitute financial, investment, legal, or tax advice. NFT tools, marketplaces, fees, chain support, and live availability can change quickly, so verify current conditions on the official platform before making any decision involving funds, assets, or private keys.
