Perché esistono le approvazioni di token

Intermedio4 nov 2026 · 6 min di lettura

Le approvazioni di token esistono perché un smart contract specifico possa spendere un token dal tuo wallet in seguito — fino a un’allowance che imposti — sotto regole comuni sui token che vietano i prelievi liberi. Il contratto non può semplicemente prendere i token.

Punti chiave

Le approvazioni di token esistono perché le regole comuni sui token impediscono a un contratto di prelevare liberamente i tuoi saldi — serve prima un’allowance a uno spender nominato.
Sui percorsi DEX e dApp che partono dal wallet, Approve è il livello dei permessi. Lo swap o il deposito è di solito una conferma separata.
L’allowance è tipicamente per token e per spender. Un’approvazione non copre ogni token né ogni contratto.
Le approvazioni illimitate esistono per comodità (meno ripetizioni, meno gas). Lasciano anche un rischio persistente più ampio se quello spender fallisce in seguito.
L’allowance residua è stato on-chain. Chiudere il sito o scollegare il wallet non la cancella.
I flussi più nuovi in stile Permit / Permit2 concedono comunque potere di spesa — spesso con meno attrito, non con lettura opzionale.

Risposta breve

Le approvazioni di token esistono perché un smart contract specifico possa spendere un token dal tuo wallet in seguito — fino a un’allowance che imposti — sotto regole comuni sui token che vietano i prelievi liberi.

In parole semplici:

Il contratto non può semplicemente prendere i token. Serve prima il permesso di spesa. Quel permesso è scritto on-chain. Può sopravvivere al clic del trade. Illimitato, residuo, revoca e scorciatoie in stile Permit seguono tutte da quel design.

La definizione del Glossario — cos’è un’approvazione — è su Cos’è un’approvazione di token?.

Questa pagina fissa un solo giudizio: Approve non è attrito a caso. È come si delega il potere di spesa.

La domanda di trading

Apri uno swap che parte dal wallet. La quotazione sembra a posto. Continui — e il wallet chiede Approve prima che il trade possa finire.

Chiediti:

È solo click inutili — o la piattaforma chiede il potere di spesa che le regole del token richiedono?

Sono storie diverse.

Se lo tratti come click inutili, firmi a raffica.

Se lo tratti come design, leggi token / spender / importo prima di firmare.

Scena live: swap bloccato finché non Approvi

Hai USDC e vuoi fare swap su un DEX che parte dal wallet.

Colleghi il wallet. Collegare non è approvare.
Inserisci la quantità e vedi una quotazione.
La conferma si ferma: il wallet mostra Approve USDC per un contratto spender (spesso un router).
Firmi l’allowance. Di solito costa gas.
Una seconda conferma esegue lo swap.
Dopo l’esecuzione, l’allowance non usata può restare on-chain per quel token e quello spender.

Aha:

«Ah — al trade serviva prima il permesso. E il permesso può restare dopo il trade.»

Cosa sia l’allowance e come leggere il prompt → Cos’è un’approvazione di token?.

Come rivedere o revocare i permessi residui → quando ti serve la checklist, vedi le User Guide di gestione/revoca.

Motivo di design: perché esiste la regola

Sotto regole ampiamente usate in stile ERC-20, i saldi non finiscono in un contratto a caso solo perché un sito lo ha chiesto.

Un percorso tipico di prelievo richiede:

Tu (il proprietario) autorizzi uno spender.
Quello spender in seguito chiama qualcosa come `transferFrom` entro l’allowance restante.

Senza quell’autorizzazione, il contratto non dovrebbe poter svuotare il token dal tuo indirizzo.

È il default di sicurezza — e il motivo per cui i flussi DEX mostrano Approve quando devono muovere un token che già detieni.

Le monete native della rete spesso saltano lo stesso passaggio approve in stile ERC-20. Le approvazioni di operatore in stile NFT sono una famiglia di permessi correlata: un clic può autorizzare un contratto su molti item. Questa pagina resta sul pattern approve fungibile che i trader spot DEX incontrano per primi.

Perché il DEX chiede prima (o intorno) al trade

Una piattaforma che fa swap, deposito o altrimenti muove il tuo saldo ERC-20 ha bisogno di potere di spesa per uno spender specifico.

Quindi il prodotto di solito:

chiede un’allowance quando non ne esiste una (o quando un’allowance limitata è esaurita)
poi ti chiede di confermare l’azione di mercato

Approve concede il permesso.

Il trade spende i token sotto quel permesso (o fallisce se manca).

Trattare entrambi i clic come «continua e basta» fonde due decisioni diverse in un’unica abitudine.

Conseguenze di design che continuerai a incontrare

Per token, per spender

Approvare USDC per il Router A non approva USDT, e non approva il Router B.

Una prima visita con diversi token può significare diversi prompt Approve. È la regola di ambito che funziona — non l’app che ti fa cliccare «per sport».

Perché esiste l’illimitato

Le approvazioni illimitate (o al massimo) sono comuni perché tagliano prompt ripetuti e gas ripetuto.

Allargano anche il rischio persistente: se quello spender è malevolo ora, buggato, o compromesso in seguito, può già avere il permesso di prelevare quel token senza un nuovo Approve da te.

Comodità e rischio persistente sono la stessa moneta di design.

Perché restano allowance residue

L’allowance è registrata on-chain per quella relazione proprietario–token–spender.

Il frontend può sparire. Il tuo «scollega» può riuscire. La mappatura può restare finché non viene consumata, abbassata o revocata.

Per questo le piattaforme vecchie che hai smesso di usare possono ancora contare nel tuo libro dei rischi.

Perché esiste revoca / abbassa

La pulizia è una scrittura on-chain separata. Di solito costa gas e richiede la tua firma.

Scollegare ≠ revocare.

Revocare/abbassare aiuta a fermare i prelievi futuri. Non restituisce i token già presi.

Passi pratici e strumenti → User Guide di gestione/revoca. Dettaglio sulle fee → Cos’è la commissione di rete (gas)?.

Pattern più nuovi: meno attrito, stessa famiglia di permessi

Alcuni flussi usano firme in stile Permit così l’allowance può essere impostata senza una transazione approve separata.

Alcuni design (inclusi hub in stile Permit2) passano da un contratto di approvazione condiviso: un’approvazione persistente all’hub, poi firme successive con ambito di importo/tempo per le app.

Questi pattern esistono per ridurre il dolore a due passaggi e, in alcuni design, per aggiungere scadenza o ambiti più fini.

Non rendono la lettura opzionale. Una pagina di phishing che raccoglie una firma Permit sbagliata può comunque concedere potere di spesa nella stessa famiglia di un Approve classico sbagliato.

L’architettura profonda di Permit2 resta fuori da questa pagina. Il giudizio sullo stato attuale è semplice: le scorciatoie spostano comunque potere di spesa.

Perché gli attaccanti badano allo stesso design

I drainer amano approvazioni e firme in stile permit perché possono monetizzare un permesso di spesa persistente senza rubare la tua seed phrase.

Prompt falsi di «claim», «verify», «sync» o «mint» chiedono spesso la stessa superficie di permesso che il DEX reale usa per swap onesti.

Il movente sta qui. Guida completa su link ufficiali e phishing → Come verificare i link ufficiali ed evitare il phishing.

Scene rapide

Scena	Cosa spiega il design
Swap bloccato finché non Approvi	Lo spender non può prelevare senza allowance
Illimitato «così non approvo di nuovo»	Comodità UX vs rischio persistente più ampio
Trade fatto; allowance ancora viva	Permesso on-chain ≠ sessione del sito
Hub in stile Permit2: approvi una volta	Permesso persistente all’hub + firme successive con ambito
Falso claim chiede Approve / Permit	Gli attaccanti riusano il livello del permesso di spesa

Non ti serve ogni riga ogni volta.

Prima di alzare la quantità, nomina se stai concedendo potere di spesa — e a chi.

Non confondere con

Cos’è un’approvazione (definizione / riconoscimento) → Cos’è un’approvazione di token?
Come rivedere o revocare (checklist pratica) → User Guide di gestione/revoca
Matematica del gas → Cos’è la commissione di rete (gas)?
Link ufficiali / come evitare il phishing → Come verificare i link ufficiali ed evitare il phishing
Connect / chiavi / modello di custodia → articoli fratelli su wallet e autocustodia

Questa pagina non è «approvazione definita di nuovo».

È perché esiste il livello dei permessi — e perché illimitato, residuo, revoca e scorciatoie in stile Permit seguono da quel design.

Se fai trading partendo dal wallet — anche su una piattaforma come edgeX — tratta ogni prompt Approve o in stile permit come concessione di potere di spesa persistente sotto le regole del token, non come una spunta decorativa.

Leggi token, spender e importo prima di firmare.

Per la definizione secca, resta su Cos’è un’approvazione di token?.

Pronto per il prossimo passo?

Continua alla registrazione o al trading da questa pagina usando i link ufficiali.

Inizia a fare trading su edgeX

Disclaimer

Questo contenuto ha solo scopo educativo e non costituisce consulenza in materia di investimenti. Il trading di asset digitali e derivati comporta rischi. Assicurati di comprendere i prodotti e valuta la tua situazione prima di fare trading.

Approfondimenti