---
title: "Perché alcune approvazioni di token devono essere prima azzerate?"
description: "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."
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.
# Perché alcune approvazioni di token devono essere prima azzerate?
> 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.
## Come funziona
1. 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.
2. 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.
3. 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`.
4. 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.
5. 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
- [Gara sulle approvazioni ERC-20](/it/crypto/erc20-approval-race-condition/)
- [Approvazione del wallet](/it/crypto/wallet-approval/)
- [Nonce e deadline di Permit ERC-2612](/it/crypto/erc2612-permit-nonce-deadline/)
- [Rischio delle firme Permit2](/it/crypto/permit2-signature-risk/)
## Fonti
- [ERC-20: standard dei token](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-21)
- [ERC20 | Documentazione OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) - OpenZeppelin (consultato: 2026-08-21)
- [SafeERC20.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) - OpenZeppelin (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/token-approval-zero-first/index.mdx