ERC-20 | Financial Context Wiki

ERC-20 è l'interfaccia standard di Ethereum per i token fungibili. Scopri come funzionano saldi, trasferimenti, limiti di spesa e approvazioni e cosa non garantisce lo standard.

Solo a scopo educativo; non costituisce consulenza finanziaria. Investire può comportare perdite.

Risposta diretta

ERC-20 è un’interfaccia standard per i contratti di token fungibili su Ethereum. Consente a portafogli, exchange e applicazioni decentralizzate di utilizzare le stesse chiamate per leggere l’offerta o un saldo, trasferire token e autorizzare un altro indirizzo a spendere un importo limitato. Fungibile significa che unità equivalenti dello stesso token sono concepite per essere intercambiabili.

L’interfaccia principale comprende:

totalSupply e balanceOf per leggere l’offerta e i saldi dei conti;
transfer per inviare i token di chi effettua la chiamata;
approve e allowance per impostare e leggere il limite di spesa di un soggetto autorizzato;
transferFrom per spendere dal saldo di un proprietario entro tale limite; e
gli eventi Transfer e Approval per registrare trasferimenti e approvazioni.

Lo standard definisce l’interoperabilità, non la qualità dell’asset. La conformità a ERC-20 non garantisce un’offerta fissa, un equo valore di mercato, la convertibilità, la liquidità, un’amministrazione sicura o persino un comportamento identico tra le diverse implementazioni.

Come funziona

Un saldo ERC-20 è una voce nello stato del contratto del token, associata a un indirizzo. Un portafoglio mostra tale stato; non conserva un file di token separato. Quando transfer(to, amount) va a buon fine, il contratto riduce il saldo di chi effettua la chiamata, aumenta quello del destinatario ed emette un evento Transfer. Di norma, l’utente paga il gas di rete in ETH. Se l’esecuzione viene annullata, le modifiche allo stato del token vengono revocate, ma il gas già consumato non viene rimborsato integralmente.

La spesa delegata utilizza un limite di spesa. La chiamata approve(spender, amount) stabilisce quanto il soggetto autorizzato può utilizzare dal saldo di chi effettua la chiamata. Tale soggetto può quindi chiamare transferFrom(owner, to, amount), mentre allowance(owner, spender) indica il limite residuo. Un’approvazione appartiene a una sola coppia proprietario-soggetto autorizzato, in un singolo contratto di token e su una singola rete; non concede alcun permesso su tutti gli asset del portafoglio.

Chiamare nuovamente approve sovrascrive il limite precedente. La specifica EIP-20 avverte le interfacce utente di impostare un limite esistente su 0 prima di stabilire un altro valore diverso da zero, perché altrimenti l’ordine delle transazioni potrebbe consentire al soggetto autorizzato di utilizzare sia il vecchio sia il nuovo limite. Impostare un limite su 0 può impedire future chiamate a transferFrom per quella combinazione di proprietario, soggetto autorizzato e token, ma non può recuperare i token già trasferiti.

name, symbol e decimals sono metodi facoltativi per i metadati in EIP-20. decimals influisce sulle unità visualizzate, non sulla contabilità a numeri interi del contratto. Lo standard, inoltre, non prescrive come i token vengano coniati o bruciati, se i trasferimenti possano essere sospesi o tassati, se gli indirizzi possano essere bloccati o se la logica di un proxy possa essere aggiornata. Questi comportamenti devono essere verificati nel codice distribuito, nell’implementazione corrente e nelle autorizzazioni amministrative.

Esempio

Supponiamo che un portafoglio contenga 1,000 unità di un token ERC-20 e che un utente voglia scambiarne 100 tramite il router di un exchange decentralizzato. L’utente invia prima approve(router, 100). Se l’operazione va a buon fine, il router può chiamare transferFrom(user, pool, 100); dopo aver speso l’intero importo, il normale limite residuo è 0. La transazione di approvazione e quella di scambio sono azioni on-chain separate, quindi ciascuna può richiedere gas e può fallire indipendentemente.

Approvare il valore massimo possibile può evitare approvazioni ripetute, ma espone un importo maggiore per più tempo se il router, la sua autorità di aggiornamento o l’interfaccia utilizzata per ottenere l’approvazione vengono compromessi. Un limite di spesa ridotto restringe tale esposizione, ma non elimina i rischi legati agli smart contract, al prezzo del token, alla liquidità o alle transazioni.

Rischi

Contratto o rete errati: nomi, simboli e icone possono essere copiati; verifica l’indirizzo del contratto sulla rete prevista.
Limite di spesa eccessivo: un soggetto autorizzato malevolo o compromesso può utilizzare un limite non speso fino all’importo approvato.
Comportamento non standard: alcuni token ampiamente utilizzati non restituiscono valori esattamente come previsto, mentre altri addebitano commissioni di trasferimento, ricalibrano i saldi, bloccano indirizzi o sospendono i trasferimenti.
Controllo amministrativo: il conio, il blocco, gli aggiornamenti o altre azioni privilegiate possono modificare il rischio del token dopo che un utente lo ha acquistato.
Trasferimento irrecuperabile: inviare token all’indirizzo sbagliato o a un contratto che non è in grado di gestirli può renderne impossibile il recupero.

La standardizzazione ERC-20 riduce le difficoltà di integrazione; non elimina i rischi legati al contratto, all’emittente, alla custodia, al mercato o alle operazioni. Prima di firmare, controlla la rete, il contratto del token, l’indirizzo del soggetto autorizzato, l’importo approvato e la chiamata della transazione.

Idee sbagliate comuni

Mito 1: L’etichetta ERC-20 dimostra che un token è legittimo

Chiunque può distribuire un contratto con un nome o un simbolo noto. L’etichetta descrive soltanto la dichiarata conformità a un’interfaccia. Verifica l’indirizzo del contratto, quindi valuta separatamente il codice, le autorizzazioni, l’emittente, la liquidità e il mercato.

Mito 2: Un’approvazione trasferisce immediatamente i token approvati

Di norma, approve modifica un limite di spesa; di per sé non trasferisce token al soggetto autorizzato. È la successiva chiamata a transferFrom a spostarli. Tuttavia, un limite ancora attivo è un’autorizzazione reale che può rimanere utilizzabile finché non viene speso, sostituito o impostato su 0.

Mito 3: Tutti i token ERC-20 si comportano allo stesso modo

Lo standard specifica un’interfaccia comune minima. Non impone una particolare politica dell’offerta e non vieta commissioni, sospensioni, liste nere, ricalibrazioni dei saldi o aggiornabilità. Le integrazioni devono considerare l’implementazione effettiva anziché affidarsi soltanto all’etichetta ERC-20.

Argomenti correlati

Fonti

ERC-20: Token Standard - Ethereum Improvement Proposals (consultato: 2026-08-20)
ERC-20 Token Standard - Ethereum.org (consultato: 2026-08-20)