Permit2 crypto è un sistema di autorizzazioni sviluppato da Uniswap Labs per rendere più uniforme l’uso dei token ERC-20 nelle applicazioni. Non sostituisce il wallet e non rende sicura una firma sbagliata: separa invece l’approvazione on-chain del token dalle autorizzazioni che l’utente firma per una specifica applicazione. Questa distinzione riduce transazioni ripetute e frammentazione delle allowance, ma crea un punto importante da capire: dopo aver approvato il contratto Permit2, una firma malevola può avere conseguenze economiche reali.
La sicurezza dipende quindi da tre controlli diversi: quale contratto riceve l’approvazione ERC-20, che cosa contiene il messaggio firmato e quale spender potrà eseguire il trasferimento. Questa guida spiega i due modelli di Permit2, expiration e nonce, i limiti del protocollo e una procedura pratica per verificare e revocare i permessi senza confondere una firma off-chain con una transazione.
Permit2 crypto: che cosa cambia davvero
Nel modello ERC-20 tradizionale, prima di usare un token in una dApp l’utente invia una transazione approve(spender, amount) al contratto del token. Lo spender — di solito un router — ottiene poi il diritto di chiamare transferFrom fino all’importo approvato. Ogni nuovo spender richiede una nuova allowance e gas; un’approvazione illimitata può rimanere attiva per anni.
Con Permit2, l’utente approva una volta il contratto Permit2 come spender ERC-20. Le applicazioni integrate chiedono poi permessi più granulari tramite firme EIP-712. Il contratto verifica firma, dominio, spender, token, importo, scadenza e nonce prima di trasferire i fondi. L’app non riceve automaticamente l’allowance ERC-20 primaria: riceve il diritto definito dal messaggio firmato e dalle regole del modulo utilizzato.
Il vantaggio è operativo: un unico contratto verificato può servire più protocolli e le autorizzazioni successive non richiedono sempre una transazione di approval. Il costo è una superficie di consenso meno intuitiva. Il wallet può mostrare “firma” e zero gas, ma il messaggio può autorizzare il prelievo di token già approvati a Permit2.
AllowanceTransfer e SignatureTransfer a confronto
Permit2 espone due meccanismi distinti. Confonderli porta a valutare male durata e possibilità di riutilizzo.
| Domanda | AllowanceTransfer | SignatureTransfer |
|---|---|---|
| Che cosa autorizza? | Un’allowance memorizzata per token, proprietario e spender | Uno o più trasferimenti descritti dalla firma |
| Il permesso resta disponibile? | Sì, fino a importo residuo o scadenza | No nel flusso standard: il nonce impedisce il replay dopo l’uso |
| Come si limita? | Importo, spender ed expiration | Token, importo massimo, spender, deadline e nonce |
| Quando è adatto? | Interazioni ricorrenti con una dApp affidabile | Operazione singola o batch atomico |
| Rischio tipico | Allowance persistente troppo ampia | Firma rubata eseguita prima della deadline |
AllowanceTransfer registra un’autorizzazione nel contratto. L’app può consumarla in più operazioni, entro l’importo residuo e prima della scadenza. SignatureTransfer usa invece una firma per autorizzare un trasferimento immediato: i nonce sono bitmap unordered, così più permessi indipendenti possono essere preparati senza una sequenza rigida. La variante witness lega la firma anche a dati applicativi aggiuntivi, ma tali dati devono essere presentati e verificati correttamente dall’integrazione.
L’approvazione ERC-20 a Permit2 è il livello di base
La prima operazione resta una normale transazione on-chain sul contratto del token. Il campo spender deve essere l’indirizzo ufficiale del contratto Permit2 sulla rete in uso, non l’interfaccia web, il router della dApp o un indirizzo copiato da un messaggio. Prima di confermare conviene confrontare rete, token, spender e importo con la documentazione ufficiale dell’applicazione.
Un’approvazione esatta limita l’esposizione ma va rinnovata; una allowance elevata riduce attrito e gas nelle interazioni future, però amplia la quantità accessibile se si firma successivamente un permesso pericoloso. L’approvazione illimitata non consegna da sola i token a qualsiasi sito: abilita Permit2 a muoverli secondo autorizzazioni valide. Rimane comunque un’autorità potente e duratura, da trattare come parte della superficie di rischio del wallet.
La revoca primaria si esegue impostando a zero l’allowance ERC-20 concessa a Permit2. È la misura più netta: impedisce nuovi trasferimenti di quel token tramite Permit2, anche se esistono permessi secondari non scaduti. Richiede gas e va fatta sulla stessa rete e sullo stesso contratto token dell’approvazione originale.
Firme EIP-712, expiration, deadline e nonce
Le firme tipizzate EIP-712 sono leggibili dalle applicazioni perché includono un dominio e campi strutturati. Il dominio lega normalmente la firma a nome, chain ID e verifying contract; non basta però vedere una finestra ben formattata. Bisogna controllare che il verifying contract sia Permit2, che la chain sia quella prevista e che lo spender indicato sia il contratto realmente necessario.
In AllowanceTransfer, expiration determina fino a quando lo spender può usare l’allowance, mentre nonce ordina gli aggiornamenti e impedisce il riuso di vecchie autorizzazioni sostituite. È presente anche una sigDeadline: limita il tempo entro cui la firma che imposta l’allowance può essere presentata on-chain. Scadenza dell’allowance e deadline della firma non sono quindi la stessa cosa.
In SignatureTransfer, la deadline stabilisce entro quando il trasferimento firmato può essere eseguito. Il nonce viene marcato come usato; una seconda esecuzione fallisce. Un nonce protegge dal replay, non da una prima esecuzione malevola. Se la firma è stata consegnata a un sito ostile, una deadline breve riduce la finestra ma non annulla ciò che è già stato trasmesso.
Scenario pratico: swap ricorrente o operazione una tantum
Immaginiamo un utente con 5.000 USDC che vuole scambiarne 300 su un aggregatore. Il sito chiede prima l’approvazione ERC-20 di USDC a Permit2. L’utente verifica rete, contratto USDC e indirizzo Permit2, quindi sceglie un importo contenuto invece di un massimale illimitato.
Per un singolo swap, SignatureTransfer è spesso coerente: la firma indica USDC, un massimo di 300, lo spender dell’aggregatore, un nonce inutilizzato e una deadline vicina. Il contratto chiamante può spendere meno del massimo se il preventivo cambia, ma non più del limite firmato. Se lo swap fallisce e il nonce non viene consumato, la firma può restare eseguibile fino alla deadline: non va ignorata solo perché la UI mostra un errore.
Se lo stesso utente effettua swap settimanali con un protocollo verificato, AllowanceTransfer può evitare nuove firme di trasferimento per ogni azione. Una scelta prudente è autorizzare lo spender per 1.000 USDC con scadenza di trenta giorni, poi rinnovare se serve. A fine periodo si controllano sia l’allowance interna sia l’approvazione ERC-20 di base.
Vincoli e responsabilità che Permit2 non elimina
Permit2 opera soltanto sui token che seguono in modo compatibile il modello ERC-20 e per i quali il proprietario ha concesso l’approval necessaria. Non può spostare il token nativo senza una rappresentazione ERC-20 come WETH. Comportamenti non standard dei token, pause, blacklist, fee on transfer o saldi insufficienti possono far fallire l’esecuzione.
Il contratto non certifica l’onestà dello spender. Verifica che la firma sia valida e che i limiti siano rispettati; non sa se l’utente abbia compreso una pagina contraffatta. Anche l’integrazione della dApp conta: gestione errata del witness, chiamante non vincolato o dati mostrati in modo ambiguo possono indebolire le garanzie attese. Per capire il contesto conviene conoscere i rischi degli smart contract e il funzionamento della DeFi.
Una revoca non recupera fondi già trasferiti. Revocare soltanto un permesso interno lascia attiva l’approvazione ERC-20 a Permit2; azzerare soltanto il token approval non cancella necessariamente lo stato interno. Sono livelli diversi.
Phishing di firme: segnali da non ignorare
Il phishing moderno evita spesso una transazione visibilmente costosa e chiede una firma “per accedere”, “verificare il wallet” o “ricevere un airdrop”. Se il wallet mostra Permit2, PermitSingle, PermitBatch o un trasferimento tipizzato, la firma non è un login innocuo. Può creare un’allowance o autorizzare un trasferimento.
- Il dominio è arrivato da un annuncio, DM, email urgente o risultato sponsorizzato.
- Lo spender non coincide con il contratto documentato dalla dApp.
- Importo massimo o batch comprende token non necessari all’azione.
- Expiration o deadline sono molto lontane, oppure il wallet non decodifica i campi.
- Il sito sollecita a firmare di nuovo dopo un errore senza spiegare nonce e richiesta precedente.
In presenza di un campo opaco, rifiutare è la decisione corretta. Un hardware wallet protegge la chiave, non interpreta l’intento: se l’utente conferma una firma malevola sul dispositivo, la firma è valida. Per somme importanti è preferibile separare il wallet operativo dal deposito, come spiegato nella guida ai wallet custodial, non custodial, hot e cold.
Come controllare e revocare allowance e firme
Il controllo parte da un explorer affidabile o da uno strumento di revoca noto, aperto da un bookmark. Si seleziona la rete corretta e si cerca l’allowance del token verso Permit2. Poi si controllano le allowance interne di Permit2 per proprietario, token e spender. Un normale approval checker potrebbe mostrare solo il primo livello e non tutti i permessi secondari.
Per rimuovere un’allowance persistente si può chiamare la funzione di lockdown/revoca prevista da Permit2 o usare un’interfaccia che la componga in modo trasparente. Per SignatureTransfer non esiste un saldo residuo classico: i nonce già usati non sono riutilizzabili; quelli ancora validi possono essere invalidati tramite le funzioni dedicate alle bitmap di nonce. Una firma non ancora trasmessa e con deadline breve può semplicemente scadere, ma se è stata esposta è più prudente invalidarne il nonce.
Se si sospetta una compromissione, la priorità è revocare l’approval ERC-20 a Permit2 per i token a rischio, revocare anche eventuali spender diretti e spostare gli asset verso un wallet pulito se la seed phrase o la chiave potrebbero essere state sottratte. Una guida operativa su come revocare le autorizzazioni crypto aiuta a distinguere approvazioni e trasferimenti già avvenuti.
Errori comuni e decisioni migliori
Considerare tutte le firme prive di rischio. Una firma Permit2 può essere economicamente equivalente a un’autorizzazione. Leggere sempre token, spender, importo e tempo.
Revocare sul network sbagliato. Le allowance sono specifiche per rete, token e proprietario. Una revoca su Ethereum non modifica la stessa posizione su una L2.
Controllare solo il nome del token. Token contraffatti possono usare simboli identici. Serve l’indirizzo del contratto.
Usare allowance illimitate per comodità. Sono sensate solo quando frequenza, costo del gas e fiducia nello spender giustificano l’esposizione. Per un’azione unica, importo esatto e deadline breve sono migliori.
Firmare più volte dopo un timeout. La prima richiesta potrebbe essere ancora valida. Prima di riprovare, verificare stato della transazione, nonce e scadenza.
Checklist di igiene del wallet
- Aprire le dApp da bookmark e verificare dominio, rete e contratto.
- Tenere nel wallet operativo solo il capitale necessario.
- Controllare l’indirizzo ufficiale di Permit2 per la chain utilizzata.
- Preferire importi limitati e scadenze brevi quando l’uso non è ricorrente.
- Leggere spender, token, amount, expiration, deadline e nonce prima di firmare.
- Rifiutare messaggi non decodificati o batch non giustificati.
- Controllare periodicamente approval ERC-20 e allowance interne.
- Revocare permessi inutilizzati dopo campagne, mint, swap occasionali o test.
- Non importare mai la seed phrase in un sito di revoca o assistenza.
- Dopo una firma sospetta, invalidare i permessi e trasferire gli asset se la chiave è a rischio.
Conclusione: usare Permit2 senza delegare la sicurezza
Permit2 crypto migliora l’esperienza delle dApp perché centralizza l’approvazione ERC-20 e consente autorizzazioni firmate più granulari. AllowanceTransfer è adatto a rapporti ricorrenti ma lascia uno stato spendibile fino a importo e scadenza; SignatureTransfer è orientato a operazioni puntuali, con nonce anti-replay e deadline, ma una firma sottratta può essere eseguita una volta.
La regola pratica è separare i livelli: verificare l’approval del token a Permit2, poi il permesso firmato verso lo spender. Limiti bassi, scadenze brevi e wallet compartimentati riducono l’impatto di un errore.
