---
title: "Signature du permis ERC-2612 : Comment vérifier le nonce et la date limite"
description: "Le permis ERC-2612 vous permet de définir une autorisation de jeton avec une signature. Cet article explique l'inspection article par article du propriétaire, du dépensier, de la valeur, du nom occasionnel et de la date limite."
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.

# Signature du permis ERC-2612 : Comment vérifier le nonce et la date limite

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

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

## Réponse directe

ERC-2612 utilise une signature EIP-712 pour définir l'`allowance` d'un jeton ERC-20 sans transaction `approve` séparée. Cet article explique la vérification de Owner, Spender, Value, Nonce et Deadline, puis de l'état sur la chaîne.

Quand un `permit` valide est miné, le contrat fixe `allowance(owner, spender)` à `value` et augmente le `nonce` du propriétaire de 1. Un relayer ou un tiers peut soumettre la signature : le propriétaire n'a donc pas à envoyer la transaction ni à payer son gaz. `deadline` n'est vérifiée qu'à la soumission de `permit` et ne fait pas expirer automatiquement une autorisation déjà écrite. Tant qu'elle n'est pas nulle, Spender peut appeler `transferFrom` dans sa limite.

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

## Comment ça marche

Le message lie `owner`, `spender`, `value`, `nonce` et `deadline` ; le domaine EIP-712 lie la signature au contrat du jeton et à la chaîne visés. Le contrat ne l'accepte que si `block.timestamp <= deadline` ; en cas de succès, il écrit l'autorisation et augmente le `nonce`, tandis qu'une date plus tardive ne réduit pas une autorisation déjà écrite. Une page malveillante peut remplacer Spender par un contrat d'attaque, fixer `value` à `2^256-1` ou éloigner fortement la date limite.

Les opérations en chaîne doivent être divisées en quatre couches : l'interface du portefeuille, la diffusion RPC, l'exécution du contrat et la finalité du bloc. Le succès d’une couche ne peut remplacer la vérification des autres couches. Les résultats réels sont basés sur les reçus de transactions, les événements, le stockage des contrats et les soldes sur la bonne chaîne.

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

## Exemple

L'utilisateur veut autoriser seulement 100 USDC, mais le `value` signé est `2^256-1` et le `deadline` est dans dix ans. Un appel réussi fixe ce maximum et augmente le `nonce` ; même si le premier transfert ne porte que sur 100, l'attaquant peut transférer les USDC déposés ensuite tant que l'autorisation subsiste. Après l'échéance, un permit inutilisé ne peut plus être soumis, mais l'autorisation écrite ne devient pas automatiquement 0. Révoquez-la avec `approve(spender, 0)` ou une autre modification fiable.

Le gaz, le taux de taxe et le temps de blocage dans ce cas ne montrent que des ordres de grandeur. L'état actuel du contrat, la liquidité du pool et les autorisations doivent être lus avant l'opération. Les montants enregistrent simultanément les montants lisibles par l'homme, les valeurs en dollars et les entiers bruts sur la chaîne pour éviter les erreurs de précision.

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

## Risques

Comparez les gains du protocole avec les pertes de sortie les plus défavorables. Supposons que le gaz augmente cinq fois, que l'impact sur les prix augmente deux fois et que le stablecoin soit réduit de 5 %. Si vous vous inscrivez pour un jour de plus, vous ne pourrez pas sortir. Si les rendements hebdomadaires ou mensuels ne peuvent pas couvrir ces frictions, les rendements dits élevés ne fournissent pas de compensation adéquate. Toute défaillance d’un seul protocole ne devrait pas rendre l’ensemble du portefeuille incapable de payer du gaz ou de transférer des actifs.

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

## Idées fausses courantes

- Mythe 1 : L'affichage frontal est le fait sur la chaîne. Le frontal peut être mis en cache, indexé tardivement ou connecté au mauvais réseau et doit être validé de manière croisée.

- Mythe 2 : L'augmentation des gaz ou du glissement peut résoudre n'importe quelle panne. Le gaz n’affecte que le tri, et les dérapages ne font que détendre les prix ; Les erreurs d’autorisation, de nonce et de conditions du contrat ne seront pas automatiquement réparées.

- Mythe 3 : La réussite de tests en petite quantité signifie une sécurité permanente. Les mises à niveau de l'administrateur, les paramètres dynamiques et les changements de liquidité modifieront les résultats et doivent être examinés avant chaque expansion de position.

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

## Sujets connexes

- [Signature structurée EIP-712](/fr/crypto/eip712-typed-signature/)
- [Client léger du nœud lumineux](/fr/crypto/light-client/)
- [Signature Permis2](/fr/crypto/permit2-signature-risk/)
- [Conflit de stockage du contrat d'agent : pourquoi le solde peut être perturbé après la mise à niveau](/fr/crypto/proxy-storage-collision/)
- [Autorisation du portefeuille](/fr/crypto/wallet-approval/)

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

## Sources faisant autorite

- [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/fr/crypto/erc2612-permit-nonce-deadline/index.mdx