Gli smart contract per marketplace NFT gestiscono inserzioni, offerte, aste, regolamento, cancellazione, instradamento delle fee, royalties e controlli amministrativi. Sebbene gli standard ERC-721 o ERC-1155 descrivano l’asset in sé, attenersi a uno standard token non produce automaticamente un marketplace sicuro.

Gli sviluppatori dovrebbero confrontare i contratti del marketplace con il comportamento di fee e ordini nella recensione del marketplace OpenSea, con i livelli operativi nella guida all’infrastruttura dei marketplace NFT e con i trigger di pagamento nei modelli di reddito passivo da NFT, perché gli eventi del contratto costituiscono i dati di origine per i flussi di regolamento e supporto.

Spiegazione degli smart contract NFT

Uno smart contract NFT è codice distribuito su una blockchain che crea token e disciplina il modo in cui la proprietà viene registrata e trasferita. Quando un NFT viene mintato, il contratto assegna un token ID a un indirizzo proprietario. Quando il token viene venduto o trasferito, il contratto aggiorna il record di proprietà solo dopo aver verificato l’autorità del mittente e le regole di trasferimento applicabili.

Di norma, il contratto registra il proprietario del token, la supply, le approvazioni, la cronologia dei trasferimenti e un riferimento ai metadati. Non necessariamente memorizza il contenuto artistico stesso. Come osserva la spiegazione di Hedera sugli smart contract NFT, il token ID e i metadati identificano l’asset, mentre la logica dello smart contract gestisce il minting e le variazioni di proprietà. È importante ricordare che uno smart contract è codice eseguibile, non un accordo legale che disciplini automaticamente copyright, rimborsi o diritti commerciali.

Contratti NFT e contratti di marketplace

Il contratto NFT e il contratto del marketplace hanno funzioni diverse. Il contratto NFT definisce l’asset, crea i token ID, registra la proprietà e impone approvazioni e trasferimenti. Il contratto del marketplace coordina la vendita: valida l’inserzione o l’offerta, incassa il pagamento, trasferisce l’NFT, instrada le fee e chiude o annulla l’ordine.

Questa separazione è importante perché possedere un NFT valido non significa che sia attivamente in vendita, e firmare un ordine del marketplace non modifica la proprietà finché il regolamento non va a buon fine. Un acquirente dovrebbe quindi verificare entrambi gli indirizzi: il contratto della collezione identifica l’NFT, mentre il contratto del marketplace o lo spender identifica il software che riceve l’autorizzazione al trasferimento. Per i team che integrano wallet, strumenti di supporto o indexer, questa distinzione determina anche quali eventi vengono trattati come fonte di verità per disponibilità dell’asset, rimborsi ed esecuzione.

In che modo ERC-721 ed ERC-1155 influenzano il design del marketplace

ERC-721 è comunemente usato quando ogni token ID rappresenta un singolo elemento di proprietà indipendente. È adatto a opere one-of-one, asset di gioco unici, lotti di terreno e collezionabili la cui proprietà viene verificata token per token. ERC-1155 può rappresentare più copie dello stesso token ID, utile per consumabili di gioco, biglietti, edizioni o elementi emessi in quantità.

Lo standard token modifica il contenuto richiesto da un ordine. Un’inserzione ERC-721 normalmente vende un solo token ID. Un’inserzione ERC-1155 può offrire 20 copie mentre l’acquirente ne compra solo tre, quindi il marketplace deve aggiornare la quantità residua senza chiudere l’intero ordine. Una cancellazione deve invalidare la quantità ancora disponibile e l’evento di regolamento deve indicare quante unità sono passate di mano.

Anche i meccanismi di approvazione cambiano. Un’approvazione ERC-721 specifica per token autorizza un singolo NFT, mentre un’approvazione da operator può coprire tutti i token di quella collezione. ERC-1155 usa comunemente l’approvazione da operator per l’intero saldo del wallet sotto il contratto. Un marketplace può richiedere un’autorizzazione più ampia per comodità, ma il prompt del wallet dovrebbe rendere visibile tale ambito e l’utente dovrebbe sapere come revocarlo.

Modelli di escrow e lazy listing

Un marketplace in escrow trasferisce l’NFT nel contratto del marketplace quando il venditore pubblica l’inserzione. Questo rende semplice verificare la disponibilità, ma il venditore paga più gas e perde la possibilità di usare l’asset mentre è in vendita. Un lazy listing mantiene l’NFT nel wallet del venditore e registra una firma off-chain che contiene token, prezzo, chain, scadenza, nonce e indirizzo del marketplace. Riduce il costo di inserzione e preserva la custodia, ma il contratto deve validare la firma e il venditore deve comunque disporre di un percorso on-chain per invalidarla.

Per un marketplace di gaming, questa scelta incide su più aspetti del gas. L’escrow può impedire che un oggetto venga equipaggiato mentre è inserito, mentre il lazy listing preserva l’asset del giocatore ma richiede che gioco e marketplace gestiscano un’inserzione che diventa non evadibile quando la proprietà cambia. Questa differenza operativa è anche il motivo per cui i team dovrebbero testare casi limite come trasferimenti di wallet, aggiornamenti della collezione e invalidazione dell’inserzione prima del lancio, invece di assumere che il modello di listing li gestisca automaticamente.

Ciclo di vita di inserzioni e offerte

Un’inserzione a prezzo fisso dovrebbe passare attraverso gli stati create, validate, buy, settle e cancel. Le offerte richiedono scadenza, nonce, chain ID, controlli sullo spender e cancellazione. Ogni stato dovrebbe emettere eventi che un indexer può riconciliare.

Le offerte richiedono anche un modello di pagamento che il contratto possa eseguire in modo affidabile. Un’offerta in coin nativo di solito non può essere prelevata in seguito dal wallet dell’acquirente senza una nuova transazione firmata, mentre un token ERC-20 approvato come WETH o USDC può essere tenuto in escrow o trasferito quando il venditore accetta. Il record dell’ordine dovrebbe quindi includere valuta, importo, scadenza, nonce, acquirente, venditore, token ID e stato di cancellazione, non solo un prezzo di riferimento.

Il regolamento delle aste richiede una propria macchina a stati. Un’asta inglese deve gestire offerte più alte, rimborsi, l’orario di chiusura e il chiamante finale del regolamento; un’asta olandese deve calcolare il prezzo corrente in base al tempo e rifiutare acquisti obsoleti. Un saldo di rimborso basato su pull è più sicuro dell’invio immediato dei fondi a ogni offerente superato, perché un callback di rimborso fallito non dovrebbe bloccare l’intera asta. Anche una breve estensione dell’orario finale aiuta a ridurre il last-second bid sniping.

Una vendita NFT da 0.5 ETH dalla firma al regolamento

Si consideri un NFT ERC-721 inserito a 0.5 ETH tramite un ordine firmato. Il venditore mantiene l’NFT nel wallet ma approva il contratto del marketplace a trasferirlo. L’inserzione firmata identifica il contratto della collezione, il token ID, il venditore, il prezzo, la scadenza, il nonce, la chain ID e l’indirizzo del marketplace. Nessun cambio di proprietà avviene nel momento in cui quella firma viene creata.

Quando l’acquirente invia l’acquisto, il contratto del marketplace verifica che l’ordine non sia scaduto o cancellato, che la firma appartenga al venditore, che il venditore possieda ancora l’NFT e che l’approvazione al trasferimento sia ancora valida. Il contratto quindi segna l’ordine come eseguito, processa il pagamento, instrada l’NFT all’acquirente ed emette eventi che il marketplace può usare per aggiornare la pagina dell’asset.

La distribuzione delle fee descritta sopra è illustrativa e non rappresenta le fee live di uno specifico marketplace.

Se il trasferimento dell’NFT fallisce, il pagamento non dovrebbe rimanere completato mentre la proprietà resta invariata. Se il destinatario del pagamento non può ricevere ETH, la risposta più sicura dipende dal design del contratto: la transazione può essere annullata, oppure l’importo può essere accreditato a un saldo prelevabile. Ecco perché instradamento dei pagamenti, ordine di trasferimento, aggiornamenti di stato e protezione dalla reentrancy devono essere testati insieme, non come semplici caselle funzionali separate.

Royalties e instradamento delle fee

Le informazioni sulle royalty possono seguire EIP-2981, mentre librerie di contratto come OpenZeppelin ERC-721 e OpenZeppelin ERC-1155 aiutano a implementare il comportamento standard degli asset. Tuttavia, l’applicazione lato marketplace richiede comunque una policy di prodotto esplicita.

EIP-2981 rende le informazioni sulle royalty leggibili, non universalmente eseguibili. Un marketplace può interrogare l’indirizzo del creatore e l’importo della royalty, ma un altro venue può scegliere una policy diversa o ignorare completamente il risultato. Se i ricavi del creatore sono essenziali, è necessario testare il percorso effettivo del trasferimento, il marketplace selezionato, il comportamento dell’aggregator e la logica di enforcement della collezione, invece di trattare un campo royalty come un pagamento garantito.

Test di sicurezza

I test principali includono reentrancy, replay attack, ordini scaduti, firme sulla chain sbagliata, compromissione della chiave admin, comportamento di pausa e fill parziali. L’obiettivo non è produrre una lunga checklist di audit, ma dimostrare che il marketplace fallisce in modo chiuso quando un ordine non è sicuro.

I test di maggior valore dovrebbero modellare i fallimenti che un acquirente o un venditore può effettivamente incontrare. Un acquisto dovrebbe rifiutare un prezzo modificato invece di eseguire un bait-and-switch; un ordine firmato dovrebbe essere vincolato alla chain ID e all’indirizzo del marketplace; un nonce cancellato o già consumato non dovrebbe essere eseguito di nuovo. Nel codice di settlement, aggiornare lo stato dell’ordine prima delle chiamate esterne e usare un guard contro la reentrancy nei percorsi di pagamento e trasferimento.

Un utente Polygon che ha recensito Rarible ha riportato che l’esperienza di rete mancava del supporto a contratti custom e del freezing dei metadati in questa recensione di contratto specifica per rete, raccolta l’11 agosto 2026. Questo non è una prova che un contratto di marketplace sia insicuro e i risultati possono dipendere dalla rete e dalla versione del prodotto. Rimane comunque un confine di implementazione utile: testare copertura dei contratti, immutabilità dei metadati e comportamento degli upgrade sulla chain esatta scelta per il lancio.

Conclusione

Un contratto di marketplace dovrebbe essere valutato in base al ciclo di vita degli ordini e al comportamento in caso di errore. Se l’articolo aiuta uno sviluppatore a testare ordini scaduti, firme sulla chain sbagliata, instradamento delle royalty e indicizzazione degli eventi, ha fatto più che ripetere gli standard token. Il prossimo controllo ingegneristico è il test del ciclo di vita dell’ordine. Un percorso di contratto sicuro gestisce creazione, scadenza, cancellazione, regolamento, royalties, indicizzazione e comportamento di pausa senza affidarsi ad assunzioni.

Domande frequenti

Quali informazioni sono memorizzate in uno smart contract NFT?

Di solito il contratto registra token ID, proprietà, saldi, approvazioni, regole di trasferimento, supply e un URI dei metadati. L’immagine o il video sono spesso archiviati separatamente e referenziati tramite i metadati.

Il contratto NFT gestisce anche le inserzioni del marketplace?

Non necessariamente. Il contratto NFT gestisce il token, mentre un contratto separato del marketplace gestisce comunemente inserzioni, offerte, aste, pagamenti, fee e regolamento.

Un marketplace può trasferire un NFT senza autorizzazione?

Serve un’autorizzazione tramite proprietà, un’approvazione specifica del token o un’approvazione da operator riconosciuta dal contratto NFT. Acquirenti e venditori dovrebbero controllare lo spender approvato prima di firmare.

Un campo royalty di un NFT garantisce il pagamento?

No. Uno standard royalty può comunicare destinatario e importo, ma il pagamento effettivo dipende dalla policy del marketplace e dal percorso di settlement.

Disclaimer: Questo articolo è destinato esclusivamente a finalità di ricerca e confronto editoriale. Non costituisce consulenza finanziaria, di investimento, legale o fiscale. Strumenti NFT, marketplace, fee, supporto alle chain e disponibilità in tempo reale possono cambiare rapidamente, quindi verifica le condizioni attuali sulla piattaforma ufficiale prima di prendere qualsiasi decisione che coinvolga fondi, asset o chiavi private.