Perché alcune approvazioni di token devono essere prima azzerate?

Alcuni token ERC-20 rifiutano il passaggio diretto da un allowance diverso da zero a un altro. Scopri quando serve l'azzeramento, perché le due transazioni vanno confermate in ordine e quali rischi restano.

Solo a scopo educativo; non costituisce consulenza in materia di investimenti. Gli investimenti possono comportare perdite.

Risposta diretta

Alcune implementazioni ERC-20 rifiutano approve(spender, newAmount) quando sia l’allowance esistente sia newAmount sono diversi da zero. Per questi token, invia prima approve(spender, 0), attendi la conferma e solo dopo invia la nuova approvazione diversa da zero.

Questo vincolo non è obbligatorio per tutti i token ERC-20. ERC-20 definisce approve come sostituzione dell’allowance corrente e raccomanda alle interfacce client di azzerarlo prima, per mitigare una gara durante la modifica dell’approvazione; precisa anche che i contratti dei token non dovrebbero imporlo per ragioni di compatibilità. Alcuni token distribuiti, tuttavia, lo impongono. L’azzeramento è quindi sia una procedura di compatibilità sia un utile punto di controllo, ma non garantisce che il vecchio allowance non venga speso prima della conferma della transazione di azzeramento.

L'ID della catena e la verifica del contratto corrispondono all'applicazione previstaFunzione, spender, token, importo, nonce e scadenza vengono decodificatiSono state verificate le indennità esistenti e la semantica di sostituzioneSono state simulate le modifiche al saldo e all'approvazioneChiamate, delegati o trasferimenti di valore imprevisti causano il rifiuto

0 / 5

0 elementi recensiti; 5 elementi ancora irrisolti

Il completamento di questa revisione non dimostra che una risorsa, una transazione o un sistema siano sicuri.

Come funziona

Verifica la chain, il contratto del token, il proprietario, lo spender e l’importo previsto. Leggi allowance(owner, spender) dal contratto del token invece di affidarti solo a un’etichetta del wallet.
Se l’allowance è già 0, invia una volta l’approvazione desiderata. Se è diverso da zero, la sostituzione diretta con un altro valore diverso da zero può riuscire su un’implementazione standard oppure essere annullata su un token che richiede l’azzeramento.
Per la procedura di azzeramento, invia approve(spender, 0) e attendi una ricevuta positiva. Poi rileggi l’allowance della stessa coppia proprietario-spender e conferma che sia 0.
Ricontrolla il saldo del token, lo spender e lo scopo. Solo allora invia approve(spender, newAmount) e attendi la conferma prima di considerare attivo il nuovo allowance.
Verifica l’allowance finale e controlla gli eventi Transfer e Approval intervenuti. Una ricevuta positiva prova l’esecuzione, mentre lo stato corrente del contratto mostra il permesso rimasto.

SafeERC20.forceApprove di OpenZeppelin offre ai contratti un ripiego di compatibilità: prova il valore desiderato e, se la chiamata fallisce, prova 0 seguito dal valore desiderato. L’utility modifica l’allowance del contratto chiamante. Non corregge automaticamente l’approvazione del wallet di un utente e non elimina la necessità di verificare l’ordine delle transazioni e lo stato finale.

Esempio

Un proprietario ha concesso a uno spender un allowance di 1000 token e vuole ridurlo a 100. Su un token che richiede l’azzeramento, approve(spender, 100) viene annullata, quindi l’allowance on-chain resta 1000; una chiamata annullata non aggiorna parzialmente lo stato.

Il proprietario invia invece approve(spender, 0). Prima della conferma, lo spender usa 400, lasciando 600; la transazione di azzeramento poi confermata sostituisce il residuo con 0. Dopo aver verificato il saldo ridotto, il proprietario può decidere se concedere il nuovo 100. Se lo concede, lo spender ha già usato 400 e in seguito può usarne fino ad altri 100. L’azzeramento ha reso visibile la spesa intermedia prima del nuovo permesso, ma non l’ha annullata.

Rischi

Il vecchio allowance resta utilizzabile finché non viene eseguito l’azzeramento. Uno spender può anticipare una revoca o una riduzione in sospeso.
Trasmettere azzeramento e sostituzione senza attendere la prima conferma elimina il punto di controllo previsto e può nascondere una spesa intermedia.
Una chain, un indirizzo del token o un indirizzo dello spender errati possono creare o revocare un permesso diverso da quello voluto. I simboli dei token non sono identificatori univoci.
La procedura in due passaggi costa due transazioni quando servono entrambe; ciascuna può fallire, essere sostituita o restare in sospeso. Non dedurre lo stato da una sola firma inviata.
Le approvazioni illimitate e gli spender aggiornabili o compromessi possono esporre i depositi futuri. Usa il minor importo pratico e verifica l’allowance residuo dopo l’uso.
Le integrazioni tra contratti devono gestire deliberatamente valori restituiti e comportamenti di approvazione non standard. Un wrapper di compatibilità non rende sicuro uno spender inaffidabile.

Idee sbagliate comuni

Ogni ERC-20 richiede l’azzeramento. Lo standard raccomanda la sequenza lato client ma afferma che i contratti dei token non dovrebbero imporla; solo alcune implementazioni rifiutano il passaggio tra due valori diversi da zero.
L’azzeramento risolve completamente la gara sulle approvazioni. Lo spender può ancora usare il vecchio allowance prima che l’azzeramento sia confermato.
Una sostituzione annullata ha cancellato il vecchio allowance. Un revert annulla la modifica di stato tentata, quindi in genere resta l’allowance precedente.
Inviare insieme le due transazioni equivale ad aspettare. Il punto di controllo deriva dal confermare e ispezionare lo stato zero prima di decidere la sostituzione.
Disconnettere un sito ne revoca l’approvazione. Lo stato della connessione del wallet e l’allowance on-chain del contratto del token sono separati.

Argomenti correlati

Fonti

ERC-20: standard dei token - Ethereum Improvement Proposals (consultato: 2026-08-21)
ERC20 | Documentazione OpenZeppelin - OpenZeppelin (consultato: 2026-08-21)
SafeERC20.sol - OpenZeppelin (consultato: 2026-08-21)