Vai al contenuto
Financial Context Wiki

ERC-721

ERC-721 è l'interfaccia standard di Ethereum per i token non fungibili (NFT): ogni token è identificato separatamente e uno smart contract registra le regole di proprietà e trasferimento.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

ERC-721 è l’interfaccia standard di Ethereum per i token non fungibili. Invece di registrare un unico saldo intercambiabile, un contratto ERC-721 segue ogni token tramite tokenId, ne espone il proprietario e definisce come può essere trasferito o autorizzato. Il token è identificato dalla coppia tra indirizzo del contratto e tokenId; lo standard da solo non stabilisce prezzo, autenticità, scarsità o diritti legali dell’asset.

ERC-721 differisce da ERC-20 perché le unità ERC-20 sono fungibili: un’unità dovrebbe poter essere scambiata con un’altra. I token ERC-721 possono appartenere alla stessa collezione pur avendo identificativi e metadati diversi. Un wallet o un marketplace può supportare entrambi gli standard, ma le chiamate di trasferimento e approvazione sono diverse.

La domanda pratica non è se un progetto dichiara di usare “ERC-721”, ma cosa fanno davvero il suo contratto e i sistemi circostanti. Prima di trattare un NFT come un asset, verifica implementazione, permessi, metadati, autorizzazioni del marketplace, liquidità e diritti promessi ai titolari.

Come funziona

Identità e proprietà

Il contratto registra un proprietario per ogni tokenId esistente. ownerOf restituisce quell’indirizzo e balanceOf conta quanti token possiede un indirizzo. Il mint di solito crea un nuovo identificativo ed emette un evento Transfer dall’indirizzo zero; il burn di solito emette un trasferimento verso l’indirizzo zero. Gli eventi aiutano l’indicizzazione, ma fa fede lo stato del contratto.

Trasferimenti e approvazioni

Il proprietario può chiamare direttamente transferFrom oppure autorizzare un indirizzo per un token con approve. setApprovalForAll autorizza un operatore per tutti i token che il proprietario detiene nella collezione. È comodo per i marketplace, ma assegna un permesso ampio. Verifica l’operatore tramite l’indirizzo del contratto e revoca on-chain le approvazioni non più necessarie. Un ordine firmato del marketplace è distinto da un’approvazione on-chain: annullare l’uno non annulla necessariamente l’altra.

safeTransferFrom verifica anche se il contratto destinatario implementa IERC721Receiver. Ciò aiuta a evitare di inviare il token a un contratto che non può riceverlo; transferFrom non esegue il callback del destinatario. Nessuna delle due funzioni garantisce che marketplace, bridge o wallet gestiscano correttamente il token.

Metadati e royalty

L’estensione opzionale dei metadati espone tokenURI, che può puntare a dati memorizzati on-chain o altrove. Una base URI modificabile, un contratto aggiornabile, un amministratore o un servizio di hosting centralizzato possono cambiare ciò che il token mostra dopo il mint. La memorizzazione permanente o decentralizzata riduce alcune dipendenze, ma non dimostra autore, provenienza o titolarità della proprietà intellettuale.

ERC-721 non obbliga i mercati secondari a pagare royalty al creatore. Una collezione può implementare l’interfaccia opzionale EIP-2981, ma il marketplace decide se rispettarla e l’interfaccia non regola né impone il pagamento. Limiti di offerta, casualità, autenticità dell’opera, licenze dei marchi e altre promesse devono essere verificati separatamente in codice, regole di distribuzione e documenti legali.

Esempio

Supponi che un contratto conii il token #42 per Alice. Il token non è identificato globalmente solo da 42: anche l’indirizzo del contratto della collezione fa parte della sua identità. Alice può metterlo in vendita concedendo approve per quel token o setApprovalForAll all’operatore del marketplace. Quando la vendita viene eseguita, il marketplace chiama una funzione di trasferimento e il contratto verifica proprietà e autorizzazione. Alice dovrebbe poi revocare l’approvazione per l’intera collezione quando non le serve più.

L’immagine mostrata dal marketplace è una questione separata di metadati. Alice deve verificare il comportamento di tokenURI, i permessi di aggiornamento, l’hosting e la licenza della collezione, senza presumere che il possesso del token trasferisca copyright o diritti d’uso commerciale.

Rischi

  • Rischio del contratto: un bug, un upgrade malevolo, un amministratore privilegiato o un hook di trasferimento errato possono bloccare o spostare token.

  • Rischio di autorizzazione: un setApprovalForAll per l’intera collezione o un marketplace compromesso può spostare tutti i token approvati di quella collezione.

  • Rischio dei metadati e legale: i file off-chain possono sparire o cambiare e la proprietà del token non concede automaticamente copyright, marchi o altri diritti legali.

  • Rischio di mercato: i prezzi degli NFT possono essere volatili, la liquidità ridotta e il floor price mostrato potrebbe non essere eseguibile per un token specifico.

Le operazioni on-chain sono in genere irreversibili. Prima di firmare verifica contratto della collezione, indirizzo del destinatario, approvazioni, controlli dei metadati e dettagli della transazione; considera le affermazioni di promotori o community come dichiarazioni da verificare, non garanzie.

Idee sbagliate comuni

Mito 1: ERC-721 garantisce la scarsità

Distingue solo i token all’interno di un contratto. L’emittente può coniare altri token, distribuire collezioni simili o far puntare più identificativi a media equivalenti. La scarsità dipende dalle regole di offerta e dai permessi che le applicano.

Mito 2: L’NFT include tutti i diritti di proprietà intellettuale

La blockchain registra un trasferimento di token. Copyright, riproduzione, uso commerciale, adattamento e marchi dipendono dalla licenza della collezione e dalla legge applicabile; non si possono dedurre da ownerOf.

Mito 3: Annullare un annuncio del marketplace rimuove ogni autorizzazione

Annuncio, firma e scadenza, oltre a un approve o setApprovalForAll on-chain, sono stati separati. Verifica e revoca indipendentemente il permesso on-chain quando non serve più.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...