---
title: "Race condition delle approvazioni ERC-20"
description: "Uno spender ERC-20 può usare la vecchia allowance prima che venga confermata un'approvazione sostitutiva, per poi usare la nuova allowance. Scopri come funziona questa race condition e come modificare o revocare le approvazioni in modo più sicuro."
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.

# Race condition delle approvazioni ERC-20

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

<a id="answer"></a>

## Risposta diretta

La race condition delle approvazioni ERC-20 può verificarsi quando un proprietario sostituisce un'allowance diversa da zero con un'altra chiamando `approve(spender, newAmount)`. Lo spender può vedere la modifica in sospeso, spendere prima la vecchia allowance tramite `transferFrom` e poi spendere la nuova allowance dopo che è stata confermata.

La specifica ERC-20 raccomanda quindi che le interfacce client impostino prima l'allowance a `0`, per poi assegnare un nuovo valore allo stesso spender. Ogni transazione deve essere confermata nell'ordine corretto. Se un token le supporta, le chiamate atomiche `increaseAllowance` o `decreaseAllowance` evitano di sostituire direttamente un'allowance diversa da zero.

<a id="mechanism"></a>

## Come funziona

ERC-20 definisce `approve` come una sovrascrittura: una chiamata riuscita a `approve(spender, amount)` imposta l'allowance dello spender su `amount`. Separatamente, `transferFrom(owner, recipient, amount)` consente allo spender di trasferire i token del proprietario e normalmente riduce l'allowance residua. Le transazioni in sospeso non riservano un ordine di esecuzione, quindi uno spender può inviare un trasferimento che viene eseguito prima della modifica dell'approvazione da parte del proprietario.

La transizione rischiosa è `N -> M`, dove sia `N > 0` sia `M > 0`. Se lo spender utilizza `N` prima dell'esecuzione dell'approvazione sostitutiva, l'approvazione successiva assegna una nuova allowance pari a `M`. L'importo massimo speso durante questa sequenza può quindi essere `N + M`, nei limiti del saldo di token del proprietario e dell'implementazione del token.

<a id="example"></a>

## Esempio

Alice ha autorizzato un protocollo a spendere `100` token. Invia `approve(protocol, 50)` con l'intenzione di ridurre l'allowance residua a `50`. Prima che la transazione venga confermata, lo spender del protocollo invia `transferFrom(Alice, recipient, 100)` e riesce a farla eseguire per prima. L'approvazione di Alice imposta quindi l'allowance a `50`, che lo spender può usare in un altro trasferimento. I due trasferimenti ammontano complessivamente a `150` token.

Un flusso di sostituzione più sicuro consiste nell'inviare `approve(protocol, 0)`, attendere la conferma, controllare l'allowance e il saldo risultanti e solo dopo inviare `approve(protocol, 50)`, se la nuova approvazione è ancora appropriata. Se lo spender utilizza la vecchia allowance prima della conferma della transazione di azzeramento, Alice può vedere il saldo modificato e fermarsi prima di concedere la nuova allowance di `50`.

<a id="risks"></a>

## Rischi

- Impostare l'allowance a `0` non revoca una spesa già eseguita e non impedisce l'uso della vecchia allowance prima che venga confermata la transazione di azzeramento.
- Inviare insieme le approvazioni di azzeramento e sostituzione, senza attendere la conferma della prima, reintroduce il rischio legato all'ordine di esecuzione.
- `increaseAllowance` e `decreaseAllowance` non fanno parte dello standard ERC-20 di base; usale solo quando il contratto verificato del token le supporta.
- Un'allowance illimitata può esporre l'intero saldo di token del proprietario finché rimane attiva. Prima di firmare, verifica la rete, il contratto del token, lo spender e l'importo.
- Alcuni token hanno comportamenti di approvazione non standard. Leggi la simulazione del wallet e i calldata della transazione, quindi verifica l'allowance on-chain dopo ogni passaggio.

<a id="misconceptions"></a>

## Errori comuni

- "La transazione di approvazione più recente sostituisce immediatamente quella vecchia." Modifica lo stato solo quando viene eseguita on-chain.
- "Ridurre un'allowance limita la spesa futura totale al nuovo importo." Uno spender può usare la vecchia allowance prima che la modifica venga eseguita.
- "Azzerare prima l'allowance garantisce che non possano uscire altri token." La vecchia allowance rimane utilizzabile finché la transazione di azzeramento non viene confermata.
- "Ogni ERC-20 dispone di `increaseAllowance` e `decreaseAllowance`." Sono estensioni facoltative, non requisiti di ERC-20.
- "Revocare la connessione al sito web revoca l'approvazione del token." Lo stato della connessione del wallet e l'allowance on-chain del contratto del token sono distinti.

<a id="related"></a>

## Argomenti correlati

- [Come distinguere i token canonici da quelli wrapped](/it/crypto/canonical-vs-wrapped-token/)
- [Mempool](/it/crypto/mempool/)
- [Rischio delle firme Permit2](/it/crypto/permit2-signature-risk/)
- [Ordini reduce-only](/it/crypto/reduce-only-order/)
- [Approvazione del wallet](/it/crypto/wallet-approval/)

<a id="sources"></a>

## Fonti

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato il: 2026-08-20)
- [ERC20 | OpenZeppelin Docs](https://docs.openzeppelin.com/contracts/4.x/api/token/erc20) - OpenZeppelin (consultato il: 2026-08-20)

Source: https://wiki.fcontext.com/it/crypto/erc20-approval-race-condition/index.mdx