---
title: "ERC-2612 Firma del permesso: come controllare il Nonce e la scadenza"
description: "Il permesso ERC-2612 consente di impostare l'autorizzazione del token con una firma. Questo articolo spiega l'ispezione articolo per articolo di Proprietario, Spendere, Valore, Nonce e Scadenza."
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.

# ERC-2612 Firma del permesso: come controllare il Nonce e la scadenza

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

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

## Risposta diretta

ERC-2612 usa una firma EIP-712 per impostare l'`allowance` di un token ERC-20 senza una transazione `approve` separata. L'articolo spiega come verificare Owner, Spender, Value, Nonce e Deadline e poi lo stato on-chain.

Quando un `permit` valido viene incluso, il contratto imposta `allowance(owner, spender)` su `value` e incrementa il `nonce` del proprietario di 1. Un relayer o una terza parte può inviare la firma: il proprietario non deve inviare la transazione né pagarne il gas. `deadline` viene controllata solo quando si invia `permit`; non fa scadere automaticamente un'allowance già scritta. Finché non è zero, Spender può chiamare `transferFrom` entro il limite.

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

## Come funziona

Il messaggio lega `owner`, `spender`, `value`, `nonce` e `deadline`; il dominio EIP-712 lega la firma al contratto del token e alla chain ID corretti. Il contratto la accetta solo quando `block.timestamp <= deadline`; in caso di successo scrive l'allowance e incrementa il `nonce`, mentre una scadenza successiva non riduce un'allowance già scritta. Una pagina dannosa può sostituire Spender con un contratto d'attacco, impostare `value` su `2^256-1` o fissare una scadenza molto lontana.

Le operazioni on-chain dovrebbero essere suddivise in quattro livelli: interfaccia del portafoglio, trasmissione RPC, esecuzione del contratto e finalità del blocco. Il successo di qualsiasi livello non può sostituire la verifica degli altri livelli. I risultati reali si basano sulle ricevute delle transazioni, sugli eventi, sull'archiviazione dei contratti e sui saldi sulla catena corretta.

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

## Esempio

L'utente vuole autorizzare solo 100 USDC, ma il `value` firmato è `2^256-1` e la `deadline` è tra dieci anni. Una chiamata riuscita imposta quel massimo e incrementa il `nonce`; anche se il primo trasferimento è di soli 100, l'aggressore può trasferire gli USDC depositati in seguito finché l'allowance esiste. Dopo la scadenza un permit inutilizzato non può più essere inviato, ma l'allowance già scritta non diventa automaticamente 0. Revocala con `approve(spender, 0)` o con un'altra modifica affidabile.

Il gas, l'aliquota fiscale e il tempo di blocco nel caso mostrano solo ordini di grandezza. Lo stato attuale del contratto, la liquidità del pool e le autorizzazioni devono essere letti prima dell'operazione. Gli importi registrano simultaneamente importi leggibili dall'uomo, valori in dollari e numeri interi grezzi sulla catena per evitare errori di precisione.

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

## Rischi

Confronta i guadagni del protocollo con le perdite di uscita nel caso peggiore. Supponiamo che il gas si espanda cinque volte, che l'impatto sul prezzo si espanda due volte e che la stablecoin sia scontata del 5%. Se ti iscrivi per un altro giorno, non potrai uscire. Se i rendimenti settimanali o mensili non riescono a coprire questi attriti, i cosiddetti rendimenti elevati non forniscono una compensazione adeguata. Qualsiasi singolo errore del protocollo non dovrebbe rendere l’intero portafoglio incapace di pagare gas o trasferire risorse.

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

## Errori comuni

- Mito 1: il display front-end è il fatto della catena. Il front-end potrebbe essere memorizzato nella cache, indicizzato in ritardo o connesso alla rete sbagliata e deve essere sottoposto a convalida incrociata.

- Mito 2: Aumentare il Gas o lo Slippage può risolvere qualsiasi fallimento. Il gas influisce solo sullo smistamento e lo slittamento non fa altro che allentare il prezzo; Gli errori di autorizzazione, Nonce e condizione del contratto non verranno riparati automaticamente.

- Mito 3: il successo dei test di piccola entità significa sicurezza permanente. Gli aggiornamenti dell'amministratore, i parametri dinamici e le modifiche alla liquidità cambieranno i risultati e dovrebbero essere rivisti prima di ogni espansione di posizione.

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

## Argomenti correlati

- [Firma strutturata EIP-712](/it/crypto/eip712-typed-signature/)
- [Nodo luce Light Client](/it/crypto/light-client/)
- [Firma autorizzazione2](/it/crypto/permit2-signature-risk/)
- [Conflitto di archiviazione del contratto dell'agente: perché il saldo potrebbe essere incasinato dopo l'aggiornamento](/it/crypto/proxy-storage-collision/)
- [Autorizzazione del portafoglio](/it/crypto/wallet-approval/)

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

## Fonti autorevoli

- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (accessed: 2026-07-28)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (accessed: 2026-07-28)

Source: https://wiki.fcontext.com/it/crypto/erc2612-permit-nonce-deadline/index.mdx