Smart contracts voor NFT-marktplaatsen regelen listings, aanbiedingen, veilingen, afwikkeling, annulering, fee-routering, royalty’s en administratieve controles. Hoewel ERC-721- of ERC-1155-standaarden het asset zelf beschrijven, levert het volgen van een tokenstandaard niet automatisch een veilige marktplaats op.

Bouwers moeten marktplaatscontracten vergelijken met het fee- en ordergedrag in de OpenSea-marktplaatsreview, de operationele lagen in de infrastructuurgids voor NFT-marktplaatsen en de betalingsprikkels in passief-inkomstenmodellen voor NFT’s, omdat contractevents fungeren als brondata voor afwikkelings- en supportprocessen.

NFT-smart contracts uitgelegd

Een NFT-smart contract is code die op een blockchain wordt ingezet en tokens creëert en bepaalt hoe eigendom wordt vastgelegd en overgedragen. Bij minting wijst het contract een token-ID toe aan een eigendomsadres. Wanneer de token wordt verkocht of overgedragen, werkt het contract het eigendomsregister bij nadat de bevoegdheid van de afzender en de toepasselijke overdrachtsregels zijn gecontroleerd.

Het contract registreert doorgaans de eigenaar van de token, de supply, goedkeuringen, overdrachtsgeschiedenis en een verwijzing naar metadata. Het slaat het artwork zelf niet noodzakelijk op. Zoals de uitleg van NFT-smart contracts door Hedera aangeeft, identificeren de token-ID en metadata het asset, terwijl smart-contractlogica minting en eigendomswijzigingen afhandelt. Belangrijk is dat een smart contract uitvoerbare computercode is; het is niet automatisch een juridische overeenkomst over auteursrecht, terugbetalingen of commerciële rechten.

NFT-contracten versus marktplaatscontracten

Het NFT-contract en het marktplaatscontract hebben verschillende taken. Het NFT-contract definieert het asset, maakt token-ID’s aan, registreert eigendom en handhaaft goedkeuringen en overdrachten. Het marktplaatscontract coördineert de verkoop: het valideert de listing of aanbieding, ontvangt betaling, overdraagt de NFT, routeert fees en sluit of annuleert de order.

Dit onderscheid is belangrijk omdat het bezitten van een geldige NFT niet betekent dat deze actief te koop staat, en het ondertekenen van een marktplaatsorder verandert het eigendom pas wanneer de afwikkeling slaagt. Een koper moet daarom beide adressen verifiëren: het collectiecontract identificeert de NFT, terwijl het marktplaatscontract of de spender de software identificeert die overdrachtsmachtiging ontvangt.

Hoe ERC-721 en ERC-1155 het marktplaatsontwerp beïnvloeden

ERC-721 wordt doorgaans gebruikt wanneer elke token-ID één afzonderlijk bezit vertegenwoordigt. Het past goed bij unieke kunst, unieke game-assets, landpercelen en collectibles waarvan het eigendom token per token wordt gecontroleerd. ERC-1155 kan meerdere exemplaren van dezelfde token-ID vertegenwoordigen, wat nuttig is voor game-consumables, tickets, edities of items die in aantallen worden uitgegeven.

De standaard verandert wat een order moet bevatten. Een ERC-721-listing verkoopt normaal één token-ID. Een ERC-1155-listing kan 20 exemplaren aanbieden terwijl een koper er slechts drie koopt, waardoor de marktplaats de resterende hoeveelheid moet bijwerken zonder de hele order te sluiten. Een annulering moet de resterende hoeveelheid ongeldig maken, en de afwikkelingsevent moet aangeven hoeveel units van eigenaar zijn gewisseld.

Goedkeuringsmechanismen zien er ook anders uit. Een token-specifieke ERC-721-goedkeuring machtigt één NFT, terwijl een operatorgoedkeuring mogelijk alle tokens uit die collectie dekt. ERC-1155 gebruikt vaak operatorgoedkeuring voor de volledige balans van een wallet onder het contract. Een marktplaats kan voor het gemak bredere toestemming vereisen, maar de walletprompt moet die reikwijdte zichtbaar maken en de gebruiker moet weten hoe deze kan worden ingetrokken.

Ontwerpen voor escrow en lazy listing

Een escrow-marktplaats verplaatst de NFT naar het marktplaatscontract wanneer de verkoper deze aanbiedt. Dat maakt het eenvoudig om beschikbaarheid te verifiëren, maar de verkoper betaalt meer gas en verliest het gebruik van het asset zolang het is gelist. Een lazy listing houdt de NFT in de wallet van de verkoper en registreert een off-chain handtekening met daarin de token, prijs, chain, vervaldatum, nonce en het marktplaatsadres. Dit verlaagt de listingkosten en behoudt het beheer, maar het contract moet de handtekening valideren en de verkoper heeft nog steeds een on-chain pad nodig om deze ongeldig te maken.

Voor een game-marktplaats heeft deze keuze meer impact dan alleen gas. Escrow kan voorkomen dat een item wordt uitgerust terwijl het gelist is; lazy listing behoudt het spelersasset, maar vereist dat de game en marktplaats een listing afhandelen die onuitvoerbaar wordt wanneer het eigendom wijzigt. Dat operationele verschil is ook waarom teams randgevallen zoals walletoverdrachten, collectie-upgrades en het ongeldig maken van listings vóór lancering moeten testen in plaats van aan te nemen dat het listingmodel dit automatisch afhandelt.

Levenscyclus van listings en aanbiedingen

Een listing met vaste prijs moet door de statussen create, validate, buy, settle en cancel gaan. Aanbiedingen vereisen vervaldatum, nonce, chain ID, controles op de spender en annulering. Elke status moet events genereren die een indexer kan reconciliëren.

Aanbiedingen hebben ook een betalingsmodel nodig dat het contract betrouwbaar kan uitvoeren. Een aanbieding in native coin kan meestal later niet uit de wallet van de koper worden opgenomen zonder een nieuwe ondertekende transactie, terwijl een goedgekeurde ERC-20-token zoals WETH of USDC in escrow kan worden aangehouden of kan worden overgedragen wanneer de verkoper accepteert. Het orderrecord moet daarom de valuta, het bedrag, de vervaldatum, nonce, koper, verkoper, token-ID en annuleringsstatus bevatten — niet alleen een headlineprijs.

Veilingafwikkeling heeft een eigen state machine nodig. Een Engelse veiling moet hogere biedingen, terugbetalingen, het sluitingstijdstip en de uiteindelijke afwikkelaar afhandelen. Een Nederlandse veiling moet de huidige prijs berekenen op basis van verstreken tijd en verouderde aankopen weigeren. Een pull-based terugbetalingssaldo is veiliger dan direct geld sturen naar elke overboden bieder, omdat een mislukte refund-callback niet de hele veiling mag blokkeren. Een korte verlenging van de eindtijd helpt ook om last-second bid sniping te verminderen.

Een NFT-verkoop van 0.5 ETH van handtekening tot afwikkeling

Neem een ERC-721 NFT die via een ondertekende order voor 0.5 ETH wordt aangeboden. De verkoper houdt de NFT in de wallet maar geeft het marktplaatscontract toestemming om deze over te dragen. De ondertekende listing bevat het collectiecontract, token-ID, verkoper, prijs, vervaldatum, nonce, chain ID en marktplaatsadres. Er vindt geen eigendomswijziging plaats wanneer die handtekening wordt aangemaakt.

Wanneer de koper de aankoop indient, controleert het marktplaatscontract of de order niet is verlopen of geannuleerd, of de handtekening van de verkoper is, of de verkoper nog steeds eigenaar is van de NFT, en of de overdrachtsgoedkeuring nog geldig is. Daarna markeert het contract de order als gevuld, verwerkt het de betaling, routeert het de NFT naar de koper en genereert het events die de marktplaats kan gebruiken om de itempagina bij te werken.

De hierboven beschreven feeverdeling is illustratief en geen verklaring over de live fees van een specifieke marktplaats.

Als de NFT-overdracht mislukt, mag de betaling niet voltooid blijven terwijl het eigendom onveranderd is. Als de ontvanger van de betaling geen ETH kan ontvangen, hangt de veiligste reactie af van het contractontwerp: de transactie kan revert gaan, of het bedrag kan worden gecrediteerd naar een opneembaar saldo. Daarom moeten betalingsroutering, overdrachtsvolgorde, statusupdates en reentrancybeveiliging samen worden getest in plaats van als losstaande vinkjes voor functies.

Royalty’s en fee-routering

Royalty-informatie kan EIP-2981 volgen, terwijl contractbibliotheken zoals OpenZeppelin ERC-721 en OpenZeppelin ERC-1155 helpen bij standaard assetgedrag. Handhaving door de marktplaats vereist echter nog steeds expliciet productbeleid.

EIP-2981 maakt royalty-informatie leesbaar, maar niet universeel afdwingbaar. Een marktplaats kan het creatoradres en het royaltybedrag opvragen, maar een ander platform kan een ander beleid kiezen of het resultaat negeren. Als creator-inkomsten essentieel zijn, test dan het daadwerkelijke overdrachtspad, de geselecteerde marktplaats, aggregatorgedrag en de handhavingslogica van de collectie in plaats van een royaltyveld als gegarandeerde betaling te beschouwen.

Beveiligingstests

Test reentrancy, replay, verlopen orders, signatures op de verkeerde chain, compromittering van admin-sleutels, pauzegedrag en gedeeltelijke fills. Het doel is niet een lange auditchecklist, maar aantonen dat de marktplaats fail-closed werkt wanneer de order onveilig is.

De meest waardevolle tests moeten de fouten modelleren die een koper of verkoper daadwerkelijk kan ervaren. Een aankoop moet een gewijzigde prijs weigeren in plaats van een bait-and-switch uit te voeren; een ondertekende order moet gekoppeld zijn aan de chain ID en het marktplaatsadres; en een geannuleerde of gebruikte nonce mag niet opnieuw worden uitgevoerd. Voor afwikkelingscode geldt dat de orderstatus vóór externe calls moet worden bijgewerkt en dat rond betalings- en overdrachtspaden een reentrancyguard moet worden toegepast.

Een Polygon-gebruiker die Rarible beoordeelde meldde dat de netwerkervaring geen ondersteuning bood voor custom contracts en metadata freezing in deze chainspecifieke contractreview, verzameld op 11 augustus 2026. Dat is geen bewijs dat een marktplaatscontract onveilig is en de bevindingen kunnen afhangen van het netwerk en de productversie. Het blijft wel een nuttige implementatiegrens: test contractdekking, metadata-immutability en upgradegedrag op precies de chain die voor lancering is geselecteerd.

Conclusie

Een marktplaatscontract moet worden beoordeeld op basis van de orderlevenscyclus en het faalgedrag. Als het artikel een bouwer helpt om verlopen orders, signatures op de verkeerde chain, royaltyroutering en event-indexing te testen, doet het meer dan tokenstandaarden herhalen. De volgende technische controle is de orderlevenscyclus-test. Een veilig contractpad handelt creatie, vervaldatum, annulering, afwikkeling, royalty’s, indexering en pauzegedrag af zonder op aannames te vertrouwen.

Veelgestelde vragen

Welke informatie wordt opgeslagen in een NFT-smart contract?

Het contract registreert meestal token-ID’s, eigendom, balances, goedkeuringen, overdrachtsregels, supply en een metadata-URI. De afbeelding of video wordt vaak apart opgeslagen en via metadata gerefereerd.

Behandelt het NFT-contract ook marktplaatslistings?

Niet noodzakelijk. Het NFT-contract beheert de token, terwijl een apart marktplaatscontract doorgaans listings, aanbiedingen, veilingen, betaling, fees en afwikkeling beheert.

Kan een marktplaats een NFT zonder toestemming overdragen?

Daarvoor is toestemming nodig via eigendom, een token-specifieke goedkeuring of een operatorgoedkeuring die door het NFT-contract wordt herkend. Kopers en verkopers moeten de goedgekeurde spender controleren voordat ze ondertekenen.

Garandeert een NFT-royaltyveld betaling?

Nee. Een royaltystandaard kan de ontvanger en het bedrag communiceren, maar de feitelijke betaling hangt af van het beleid van de marktplaats en het afwikkelingspad.

Disclaimer: Dit artikel is uitsluitend bedoeld voor onderzoek en redactionele vergelijking. Het vormt geen financieel, beleggings-, juridisch of fiscaal advies. NFT-tools, marktplaatsen, fees, chain-ondersteuning en live beschikbaarheid kunnen snel veranderen, dus verifieer de actuele omstandigheden op het officiële platform voordat u een beslissing neemt met betrekking tot fondsen, assets of private keys.