---
title: "ERC-721"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ERC-721
> 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
- [Accumulatore crittografico](/it/crypto/cryptographic-accumulator/)
- [ERC-20](/it/crypto/erc20/)
- [NFT](/it/crypto/nft/)
- [Frase mnemonica](/it/crypto/seed-phrase/)
- [Standard dei token](/it/crypto/token-standard/)
## Fonti
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (consultato: 2026-08-20)
- [ERC-721 Non-Fungible Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) - Ethereum.org (consultato: 2026-08-20)
- [ERC-2981: NFT Royalty Standard](https://eips.ethereum.org/EIPS/eip-2981) - Ethereum Improvement Proposals (consultato: 2026-08-20)
- [Prestare attenzione all’acquisto di monete o token digitali](https://www.cftc.gov/LearnAndProtect/AdvisoriesAndArticles/caution_of_digital_currencies.html) - CFTC (consultato: 2026-08-20)
Source: https://wiki.fcontext.com/it/crypto/erc721/index.mdx