Approvazioni di token: i permessi che continui a concedere

Ogni volta che interagisci con un'app DeFi — uno swap su un DEX, un deposito in un mercato di prestiti, un bridge di un ERC-20 — quasi certamente hai concesso un'approvazione di token. La maggior parte degli utenti le firma in pochi secondi e se ne dimentica. Eppure quella singola transazione di approve è una delle cose più importanti che fai su Ethereum: consegna a uno smart contract il permesso permanente di muovere i tuoi token, spesso senza ulteriore conferma. Questa guida illustra cos'è un'approvazione di token, perché le dApp le chiedono, i rischi degli allowance illimitati e cosa significa tutto questo quando firmi approvazioni tramite SSP.

Perché esistono le approvazioni

I token ERC-20 non sono conservati "dentro" il tuo wallet come ETH. Un contratto di token ERC-20 è un libro mastro: una mappatura da indirizzi a saldi. Quando detieni 1.000 USDC, ciò che esiste on-chain è una riga nel contratto USDC che dice che il tuo indirizzo possiede 1.000 unità.

Poiché il saldo vive dentro il contratto del token, solo quel contratto può muoverlo. Quando invii USDC a un amico, il tuo wallet chiama direttamente la funzione transfer del token.

Ma un DEX, dove un contratto diverso (il router) deve prelevare USDC dal tuo indirizzo per eseguire uno swap, non può infilare la mano nel contratto del token e prendersi il tuo saldo. ERC-20 risolve la cosa con un pattern di delega in due passi:

1. Tu chiami approve(spender, amount) sul contratto del token. Questo imposta un allowance: un record che lo spender è autorizzato a muovere fino ad amount dei tuoi token.
2. Lo spender in seguito chiama transferFrom(yourAddress, destination, amount) sul contratto del token. Il contratto verifica l'allowance, lo decrementa e muove i token.

L'approvazione è la chiave. Senza di essa, il router non può toccare i tuoi USDC.

Cosa stai effettivamente concedendo

Leggi approve(spender, amount) alla lettera. Stai dicendo al contratto ERC-20: "questo indirizzo può prelevare fino a questa quantità dei miei token, in qualsiasi momento, in qualsiasi numero di transazioni, fino a quando non la cambierò."

Ne derivano alcune cose:

• Permesso permanente, non azione una tantum. Una volta concesso, lo spender non ha bisogno di nuovo della tua firma per prelevare token finché l'allowance non è esaurito o revocato.
• Per token. Approvare il router del DEX per USDC non gli permette di toccare i tuoi DAI; serve un'approvazione separata per DAI.
• Per spender. Un contratto diverso — anche della stessa dApp — ha il proprio allowance.
• Nessuna scadenza. ERC-20 non ha una deadline incorporata. Un allowance impostato nel 2023 è ancora attivo nel 2026 a meno che non sia stato consumato o revocato.

Puoi ispezionare qualsiasi allowance su un block explorer come etherscan leggendo la funzione allowance(owner, spender) del contratto del token.

Il pattern dell'allowance infinito

Se le approvazioni sono per importo, perché quasi ogni DEX ti chiede un numero enorme — di solito 2^256 - 1, mostrato come "unlimited" o MaxUint256 — invece del solo importo che stai scambiando?

La risposta è UX e gas. Se un DEX chiedesse un allowance nuovo pari alla dimensione del trade per ogni swap, pagheresti una transazione di approvazione ogni volta e dovresti confermare due transazioni per quella che sembra una singola azione. Chiedere un allowance illimitato una sola volta ti permette poi di scambiare liberamente con una sola transazione per trade.

È sinceramente comodo. È anche sinceramente più rischioso. Un allowance illimitato significa che il contratto dello spender è autorizzato a prosciugare l'intero tuo saldo attuale di quel token — e qualsiasi saldo futuro — in qualunque momento, senza che tu firmi altro.

Per un contratto noto, sottoposto ad audit e immutabile, il rischio pratico è di solito basso. Per una dApp appena deployata, un proxy aggiornabile o un contratto sconosciuto, un allowance illimitato è una superficie molto più ampia dell'operazione che intendevi.

Il rischio vero: una chiave permanente ai tuoi token

Il pericolo delle approvazioni non è la transazione di approvazione in sé. È ciò che accade dopo. Considera alcuni scenari:

• Il contratto dello spender ha un bug. Un attaccante sfrutta la sua logica transferFrom e ogni wallet con un allowance non nullo viene prosciugato.
• Il contratto dello spender è aggiornabile. Chi controlla le chiavi di upgrade rilascia una nuova logica che preleva token da chiunque abbia un allowance attivo.
• Hai approvato un clone malevolo. Un sito di phishing ha imitato l'URL di una dApp reale, e il contratto che hai approvato era controllato dall'attaccante fin dall'inizio.
• Le chiavi di firma dello spender sono compromesse. Il contratto ufficiale va bene; il wallet dell'operatore no, e gli allowance vengono esercitati da un intruso.

In ogni caso, non firmi nulla quando avviene il drenaggio. L'approvazione concessa settimane prima è l'unica autorizzazione di cui l'attaccante ha bisogno. "Approva solo ciò che ti serve e revoca ciò che non usi più" non è paranoia; è lo stesso principio del non lasciare copie delle chiavi di casa a tutti gli artigiani che hai mai assunto.

Come si accumulano silenziosamente le approvazioni

Un wallet attivo da uno o due anni in DeFi ha accumulato decine di approvazioni: ogni DEX, ogni aggregatore, ogni deposito in mercati di prestiti, ogni marketplace di NFT, ogni bridge. Gli utenti non revocano quasi mai. Il risultato è una lunga coda di permessi permanenti, molti illimitati, molti concessi a contratti con cui l'utente non interagisce più.

Questa è la superficie d'attacco silenziosa. Non compare in nessuna singola transazione; è il residuo cumulativo di un uso normale. Auditare e potare quella lista è una delle abitudini di sicurezza più efficaci nella self-custody — il prossimo articolo spiega esattamente come in revocare approvazioni di token da SSP.

Un pattern più recente: EIP-2612 permit

ERC-20 precede gran parte della DeFi moderna, e il balletto a due transazioni approve-poi-swap è da tempo riconosciuto come scomodo. EIP-2612 ha introdotto un'alternativa per i token che la supportano: invece di inviare una transazione approve on-chain, l'utente firma un messaggio off-chain (un permit) che autorizza uno spender, un importo e una deadline specifici. La dApp invia quella firma insieme allo swap in una singola transazione.

permit è efficiente in termini di gas, circoscritto (porta un importo e una scadenza espliciti) e più difficile da lasciar pendere perché la deadline ne forza la scadenza. Non tutti gli ERC-20 lo supportano — USDC e DAI sì, molti token più vecchi no — ma dove disponibile è in genere più sicuro di un allowance approve a lunga durata. Detto questo, anche le firme permit possono essere oggetto di phishing: un sito malevolo che ti chiede di "fare il login" può infilarci sotto un permit. Leggi cosa stai firmando.

Cosa significa tutto questo dentro SSP

SSP è un wallet multisig 2-di-2 self-custodial: ogni transazione on-chain è co-firmata dall'estensione SSP del browser e dall'app mobile SSP Key. Su Ethereum e sulle reti EVM supportate da SSP (Polygon, Base, BNB Smart Chain, Avalanche), questo è implementato come uno smart account ERC-4337 con firma Schnorr aggregata — ma a livello applicativo, un'approvazione sembra una qualsiasi altra transazione.

Alcune cose da tenere a mente:

• Un'approvazione è una transazione che il tuo 2-di-2 deve co-firmare. Quando una dApp chiede approve, SSP la presenta come una qualsiasi altra tx. Vedi l'indirizzo dello spender e l'importo richiesto su entrambi i dispositivi prima di confermare.
• Una volta concessa, lo spender non ha più bisogno di SSP per agire. Il multisig protegge il momento dell'approvazione, non il permesso permanente che segue. Se concedi un allowance illimitato a un contratto malevolo, il tuo multisig non ti salverà dal drenaggio successivo.
• Guarda l'indirizzo dello spender. Le dApp talvolta aggiornano i router; se lo spender nella schermata di approvazione non corrisponde al contratto che ti aspetti, fermati e verifica.
• Le approvazioni avviate via WalletConnect hanno lo stesso aspetto. Che la dApp te lo chieda nella sua pagina o tramite WalletConnect, il flusso e i rischi sono identici.

Abitudini da costruire

Alcune pratiche concrete mantengono gestibile la superficie di approvazione:

• Preferisci l'allowance più piccolo possibile. Quando una dApp offre "importo esatto" rispetto a "unlimited", l'esatto è la scelta predefinita più sicura per contratti che non usi regolarmente.
• Tratta gli allowance illimitati come impegni. Riservali a un piccolo insieme di contratti di cui ti fidi e che usi spesso. Per tutto il resto, circoscrivi.
• Auditale periodicamente. Una volta a trimestre, elenca le tue approvazioni attive su ogni catena e revoca tutto ciò che non usi più. Strumenti come revoke.cash lo rendono di routine.
• Diffida delle dApp sconosciute. Un protocollo nuovo senza storico di audit che chiede un allowance illimitato è la combinazione a più alto rischio in DeFi.
• Proteggi le chiavi che concedono approvazioni. Il multisig di SSP alza l'asticella, ma l'igiene standard si applica comunque — vedi buone pratiche per la frase seed.

Il modello mentale da portarti a casa

Un'approvazione di token non è un clic; è una chiave. Ognuna resta nella serratura finché non la togli, e ognuna conferisce a chi la possiede la capacità di muovere token che non hai ancora guadagnato. Usati con cura, gli allowance sono le tubature che fanno funzionare la DeFi. Trattati come clic usa-e-getta, sono l'accumulo lento di rischi che ti sei dimenticato di aver assunto.

Comprendi il permesso che stai concedendo, preferisci concessioni circoscritte dove la dApp lo permette e pota le tue approvazioni permanenti con regolarità. Per i dettagli più profondi del protocollo, la documentazione dello standard ERC-20 su ethereum.org è il riferimento canonico. Nuovo nell'uso di SSP su Ethereum? La nostra guida Ethereum in SSP copre le basi.