---
title: "Rischio della firma Permit2"
description: "Permit2 separa le allowance riutilizzabili dai trasferimenti una tantum autorizzati tramite firma; firmare in sicurezza richiede di verificare deployment, dominio, spender, destinatario, importo, nonce, scadenza, witness e calldata di esecuzione."
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.
# Rischio della firma Permit2
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Permit2 riunisce due sistemi di autorizzazione distinti. `AllowanceTransfer` registra un'allowance riutilizzabile tra proprietario, token e spender, con importo, scadenza e nonce ordinato. `SignatureTransfer` consuma un massimale firmato una tantum mediante un nonce bitmap non ordinato e non crea alcuna allowance persistente a valle. Entrambi dipendono comunque dall'allowance ERC-20 concessa dal proprietario del token a Permit2.
Una firma senza gas a carico dell'utente può spostare asset quando uno spender o un relayer paga l'esecuzione. Occorre verificare esattamente chain, codice Permit2 distribuito, dominio EIP-712, modulo, token, spender, massimale firmato, calldata del destinatario, nonce e vincoli temporali. La legittimità del contratto Permit2 non rende sicuri uno spender, un destinatario, un router o un witness malevoli.
## Come funziona
1. Fissare `chainId`, rete, `verifyingContract` di Permit2, codice runtime distribuito, indirizzo e decimali del token, tipo di wallet del proprietario e applicazione prevista. Usare un registro ufficiale dei deployment: un indirizzo o un'etichetta familiari non bastano.
2. Leggere saldo e allowance ERC-20 a monte dal proprietario a Permit2. Distinguere un'approvazione finita da una illimitata e identificare il comportamento specifico del token nei trasferimenti; questo registro sopravvive alla scadenza di una firma Permit2 o di un'allowance a valle memorizzata.
3. Identificare il percorso e il tipo primario firmato: `PermitSingle` o `PermitBatch` per AllowanceTransfer, oppure `PermitTransferFrom` o le varianti batch e witness per SignatureTransfer. Non confondere `transferFrom` con il tipo firmato.
4. Decodificare il dominio EIP-712 e ogni voce del messaggio. Per AllowanceTransfer verificare token, `uint160 amount`, `expiration`, nonce ordinato, spender e `sigDeadline`. Per SignatureTransfer verificare token e importo consentiti, nonce non ordinato, scadenza e spender vincolato dal contesto del chiamante.
5. Decodificare separatamente la calldata di esecuzione. Nel SignatureTransfer di base, `SignatureTransferDetails.to` e `requestedAmount` sono parametri di esecuzione, non campi del permesso firmato di base; l'importo richiesto deve soltanto restare entro il massimale firmato. Verificare ogni indice del batch e, se presente, l'hash del witness e la stringa di tipo esatti.
6. Interrogare il nonce corrente dell'allowance ordinata oppure parola e bit della bitmap non ordinata, quindi simulare chiamante, calldata, chain e stato esatti. Riconciliare destinatario, azioni del router, peculiarità del token, saldo ed entrambi i registri delle allowance; la simulazione può divergere per stato, ordinamento o riorganizzazione.
7. Ridurre al minimo importi e durate. In caso di sospetto, conservare i dati tipizzati e inviare, tramite un percorso fidato, la revoca corretta dell'approvazione a monte, dell'allowance a valle o l'invalidazione del nonce, trattandola come una corsa nel mempool; attendere la conferma e riconciliare trasferimenti, saldi, allowance e bit della bitmap.
Il `sigDeadline` di AllowanceTransfer limita il momento entro cui il permesso firmato può creare o aggiornare l'autorità memorizzata; `expiration` limita il periodo in cui tale autorità può essere spesa. La deadline di SignatureTransfer limita la sua esecuzione una tantum. EIP-712 fornisce hashing tipizzato e separazione del dominio, non protezione dal replay né sicurezza dell'intento: questi limiti dipendono dalle regole di nonce e scadenza di Permit2.
Per un wallet contrattuale, la validità ERC-1271 dipende dalla politica `isValidSignature` corrente, dai moduli, dalle soglie e dal codice del wallet. Etichette del wallet, schermate abbreviate di un hardware wallet e simulazioni riuscite sono elementi informativi, non garanzie. Disconnettere un frontend non revoca alcuna approvazione o firma.
## Esempio
- **Due registri di allowance.** L'allowance finita del token verso Permit2 parte da `1,000 USDC`; un `PermitSingle` registra `600 USDC` per lo spender S. Dopo il trasferimento di `225 USDC` da parte di S, l'importo memorizzato è `600 - 225 = 375 USDC`, mentre una normale allowance finita a monte diventa `1,000 - 225 = 775 USDC`. La scadenza o revoca di 375 non azzera automaticamente 775; token non standard possono comportarsi diversamente.
- **Destinatario e importo una tantum.** Un SignatureTransfer firma un massimale di `250 USDC`; la calldata richiede `180 USDC` a favore di un esercente. Se saldo e allowance a monte sono sufficienti, l'esecuzione può trasferire 180. Il nonce viene consumato, quindi i `70 USDC` inutilizzati non sono riutilizzabili. Se la calldata indica come destinatario un attaccante, il permesso di base da solo non impedisce allo spender vincolato di reindirizzare il trasferimento.
- **Bitmap dei nonce non ordinati.** Per il nonce `513`, `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1` e `mask = 1 << 1 = 2`. L'esecuzione imposta il bit 1 della parola 2; il replay di 513 fallisce, mentre il nonce `512`, associato al bit 0, resta indipendente.
- **Corsa alla revoca.** Un'allowance memorizzata è pari a `400 USDC`. Il proprietario trasmette una revoca a zero, ma prima viene eseguito un trasferimento di `300 USDC`, che lascia `100 USDC`; la revoca successiva porta il residuo a `0`. Un saldo finale dell'allowance pari a zero non annulla la perdita realizzata di `300 USDC`: occorre riconciliare ordinamento delle transazioni e saldi.
## Rischi
- Chain ID, deployment o codice runtime errati
- Contratto di verifica contraffatto o inatteso
- Confusione tra AllowanceTransfer e SignatureTransfer
- Spender o chiamante malevolo oppure indicato per errore
- Destinatario scelto tramite la calldata di esecuzione
- Importo richiesto prossimo al massimale firmato
- Indirizzo, simbolo, decimali o unità raw del token errati
- Approvazione ERC-20 a monte persistente o illimitata
- Importo o scadenza a valle eccessivi
- Confusione tra deadline, signature deadline ed expiration
- Nonce ordinato obsoleto o oggetto di una corsa
- Bit della bitmap riutilizzato o maschera di invalidazione troppo ampia
- Hash del witness o stringa di tipo esatta non corrispondenti
- Voce batch nascosta, duplicata o con indice errato
- Differenza tra quanto mostra il frontend, la calldata e l'intento
- Revoca battuta in una corsa nel mempool o da MEV
- Modifica di modulo, firmatario, soglia o upgrade ERC-1271
- Token con commissione sul trasferimento, rebasing, pausa, blocco o callback
- Deriva dello stato simulato, errore di simulazione o riorganizzazione
- Conferma su hardware wallet o disconnessione scambiate per sicurezza
## Idee sbagliate comuni
- **Una firma senza richiesta di gas non può spostare token.** Un'altra parte può pagare il gas dell'esecuzione.
- **L'indirizzo Permit2 ufficiale dimostra che spender e destinatario sono sicuri.** Permit2 può eseguire fedelmente un'autorità malevola.
- **SignatureTransfer e AllowanceTransfer creano la stessa autorizzazione persistente.** Il primo è monouso; il secondo memorizza un'allowance riutilizzabile.
- **Disconnettersi o revocare un livello annulla ogni percorso e firma in sospeso.** Stato a monte, stato a valle e nonce sono separati e le corse restano possibili.
- **EIP-712, un hardware wallet o una simulazione riuscita dimostrano intento e finalità.** Migliorano visibilità o test, ma non sostituiscono la verifica di campi, calldata e stato confermato.
## Argomenti correlati
- [Firma tipizzata EIP-712](/it/crypto/eip712-typed-signature/)
- [Approvazione del wallet](/it/crypto/wallet-approval/)
- [Firma del wallet](/it/crypto/wallet-signature/)
## Fonti
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (consultato il 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (consultato il 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (consultato il 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (consultato il 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (consultato il 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultato il 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consultato il 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato il 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/permit2-signature-risk/index.mdx