NFT marketplace smart contracts govern listings, offers, auctions, settlement, cancellation, fee routing, royalties, and administrative controls. While ERC-721 or ERC-1155 standards describe the asset itself, adhering to a token standard does not automatically produce a secure marketplace.

Builders should compare marketplace contracts against 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 serve as the source data for settlement and support workflows.

NFT Smart Contracts Explained

An NFT smart contract is code deployed on a blockchain that creates tokens and governs how ownership is recorded and transferred. Upon minting, the contract assigns a token ID to an owner address. When the token is sold or transferred, the contract updates the ownership record only after verifying the sender's authority and applicable transfer rules.

The contract typically 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 notes, the token ID and metadata identify the asset, while smart-contract logic handles minting and ownership changes. Importantly, a smart contract is executable computer code—it is not automatically a legal agreement governing copyright, refunds, or commercial rights.

NFT Contracts vs. Marketplace Contracts

The NFT contract and the marketplace contract serve distinct purposes. The NFT contract defines the asset, creates token IDs, records ownership, and enforces approvals and transfers. The marketplace contract coordinates the sale: it validates the listing or offer, collects payment, transfers the NFT, routes fees, and closes or cancels the order.

This separation is significant because owning a valid NFT does not mean it is actively listed, and signing a marketplace order does not change ownership until settlement completes. Buyers should verify both addresses: the collection contract identifies the NFT, while the marketplace contract or spender identifies the software receiving transfer permission. For teams integrating wallets, support tools, or indexers, this distinction also determines which events are treated as source-of-truth for item availability, refunds, and fulfillment.

How ERC-721 and ERC-1155 Shape Marketplace Design

ERC-721 is commonly used when each token ID represents a single independently owned item. It is well suited for one-of-one art, unique game assets, land parcels, and collectibles whose ownership is verified 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.

The token 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, requiring the marketplace to update the remaining quantity without closing the entire order. A cancellation must invalidate whatever quantity remains, and the settlement event must indicate how many units changed hands.

Approval mechanisms also differ. A token-specific ERC-721 approval authorizes a single NFT, while an operator approval may cover every token from that collection. ERC-1155 commonly uses operator approval for a wallet's entire balance under the contract. A marketplace can require broader permission for convenience, but the wallet prompt should make that scope visible and the user should understand how to revoke it.

Escrow and Lazy Listing Designs

An escrow marketplace transfers the NFT into the marketplace contract when the seller lists it. This approach makes availability simple to verify, but the seller pays more gas and loses the ability to use the asset while 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. This 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.

For a game marketplace, this choice affects more than gas costs. Escrow can prevent an item from being equipped while listed, whereas lazy listing preserves the player's asset but requires the game and marketplace to handle a listing that becomes unfillable when ownership changes. That operational difference is also why teams should test edge cases such as wallet transfers, collection upgrades, and listing invalidation before launch rather than assuming the listing model will handle them automatically.

Listing and Offer Lifecycle

A fixed-price listing should move through create, validate, buy, settle, and cancel states. Offers require expiry, nonce, chain ID, spender checks, and cancellation. Every state should emit events that an indexer can reconcile.

Offers also need a payment model the contract can reliably execute. A native coin offer usually cannot be withdrawn from the buyer's wallet later without a new signed transaction, while an approved ERC-20 token 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—not just a headline price.

Auction settlement requires 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 elapsed time and reject stale purchases. A pull-based refund balance is safer than sending funds immediately to every outbid bidder, because a failed refund callback should not freeze the entire auction. A short end-time extension also helps reduce 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 verifies 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. The contract 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 fee distribution described above is illustrative, not a statement of any specific marketplace's live fees.

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 isolated 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 implement standard asset behavior. However, marketplace enforcement still requires deliberate product policy.

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 entirely. If creator revenue is essential, builders should test the actual transfer path, the selected marketplace, aggregator behavior, and the collection's enforcement logic rather than treating a royalty field as a guaranteed payment.

Security Testing

Critical tests include reentrancy, replay attacks, expired orders, wrong-chain signatures, admin key compromise, pause behavior, and partial fills. The objective is not to produce a lengthy audit checklist but to prove that the marketplace fails closed when an order is unsafe.

The highest-value tests should model failures that a buyer or seller could 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. A cancelled or consumed nonce should not execute again. For settlement code, update order state before external calls and apply 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 a network-specific contract review, collected on August 11, 2026. This is not evidence that a marketplace contract is unsafe, and the findings may depend on the network and product version. Nonetheless, it highlights 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 evaluated by its order lifecycle and failure behavior. A safe contract path handles creation, expiry, cancellation, settlement, royalties, indexing, and pause behavior without relying on assumptions. The next engineering step is the order lifecycle test.

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 recognized 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 actual payment depends on marketplace policy and the 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.