---
title: "ERC-2612-Genehmigungssignatur: So überprüfen Sie Nonce und Deadline"
description: "Mit der ERC-2612-Genehmigung können Sie die Token-Autorisierung mit einer Signatur festlegen. In diesem Artikel wird die Einzelprüfung von Eigentümer, Spender, Wert, Nonce und Frist erläutert."
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-Genehmigungssignatur: So überprüfen Sie Nonce und Deadline

> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

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

## Direkte Antwort

ERC-2612 verwendet eine EIP-712-Signatur, um die ERC-20-`allowance` ohne separate `approve`-Transaktion festzulegen. Dieser Artikel erklärt die Prüfung von Owner, Spender, Value, Nonce und Deadline sowie des On-Chain-Ergebnisses.

Wenn ein gültiges `permit` gemined ist, setzt der Tokenvertrag `allowance(owner, spender)` auf `value` und erhöht die `nonce` des Eigentümers um 1. Ein Relayer oder Dritter kann die Signatur einreichen; der Eigentümer muss weder die Transaktion senden noch ihr Gas bezahlen. `deadline` wird nur bei der Einreichung von `permit` geprüft und lässt eine bereits geschriebene Allowance nicht automatisch ablaufen. Solange sie ungleich null ist, kann der Spender `transferFrom` innerhalb des Limits aufrufen.

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

## Wie es funktioniert

Die Nachricht bindet `owner`, `spender`, `value`, `nonce` und `deadline`; die EIP-712-Domain bindet die Signatur an den Tokenvertrag und die Chain-ID. Der Vertrag akzeptiert sie nur bei `block.timestamp <= deadline`; bei Erfolg schreibt er die Allowance und erhöht die `nonce`, während eine spätere Frist eine bereits geschriebene Allowance nicht verkürzt. Schädliche Seiten können den Spender durch einen Angriffsvertrag ersetzen, `value` auf `2^256-1` setzen oder die Frist weit in die Zukunft legen.

On-Chain-Operationen sollten in vier Schichten unterteilt werden: Wallet-Schnittstelle, RPC-Broadcast, Vertragsausführung und Blockendgültigkeit. Der Erfolg einer Schicht kann die Verifizierung anderer Schichten nicht ersetzen. Die tatsächlichen Ergebnisse basieren auf den Transaktionsbelegen, Ereignissen, Vertragsspeichern und Salden in der richtigen Kette.

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

## Beispiel

Der Benutzer möchte nur 100 USDC autorisieren, aber der signierte `value` ist `2^256-1` und die `deadline` liegt zehn Jahre später. Ein erfolgreicher Aufruf setzt dieses Limit und erhöht die `nonce`; auch nach einem ersten Transfer von 100 kann der Angreifer später eingezahlte USDC übertragen, solange die Allowance besteht. Nach Ablauf kann ein ungenutztes Permit nicht mehr eingereicht werden, aber eine bereits geschriebene Allowance wird nicht automatisch 0. Widerrufe sie mit `approve(spender, 0)` oder einer anderen vertrauenswürdigen Änderung.

Der Gas-, Steuersatz und die Blockzeit zeigen in diesem Fall nur Größenordnungen. Der aktuelle Vertragsstatus, die Poolliquidität und die Berechtigungen müssen vor dem Betrieb gelesen werden. Beträge zeichnen gleichzeitig für Menschen lesbare Beträge, Dollarwerte und rohe ganze Zahlen in der Kette auf, um Präzisionsfehler zu vermeiden.

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

## Risiken

Vergleichen Sie Protokollgewinne mit Ausstiegsverlusten im schlimmsten Fall. Gehen Sie davon aus, dass sich Gas um das Fünffache erhöht, der Preiseffekt um das Doppelte zunimmt und der Stablecoin um 5 % abgezinst wird. Wenn Sie für einen weiteren Tag beitreten, können Sie nicht austreten. Können wöchentliche oder monatliche Renditen diese Friktionen nicht abdecken, bieten sogenannte Hochrenditen keinen ausreichenden Ausgleich. Ein Ausfall eines einzelnen Protokolls sollte nicht dazu führen, dass das gesamte Wallet nicht mehr in der Lage ist, Benzin zu bezahlen oder Vermögenswerte zu übertragen.

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

## Häufige Irrtümer

- Mythos 1: Das Front-End-Display ist die Tatsache an der Kette. Das Front-End ist möglicherweise zwischengespeichert, spät indiziert oder mit dem falschen Netzwerk verbunden und muss einer Kreuzvalidierung unterzogen werden.

- Mythos 2: Zunehmendes Gas oder Schlupf kann jeden Fehler beheben. Gas wirkt sich nur auf die Sortierung aus, und Slippage senkt nur den Preis; Berechtigungs-, Nonce- und Vertragsbedingungsfehler werden nicht automatisch repariert.

- Mythos 3: Erfolgreiche Tests in kleinen Mengen bedeuten dauerhafte Sicherheit. Administrator-Upgrades, dynamische Parameter und Liquiditätsänderungen verändern die Ergebnisse und sollten vor jeder Positionserweiterung überprüft werden.

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

## Verwandte Themen

- [Strukturierte EIP-712-Signatur](/de/crypto/eip712-typed-signature/)
- [Light-Knoten-Light-Client](/de/crypto/light-client/)
- [Permit2-Signatur](/de/crypto/permit2-signature-risk/)
- [Speicherkonflikt im Agentenvertrag: Warum der Kontostand nach dem Upgrade durcheinander geraten kann](/de/crypto/proxy-storage-collision/)
- [Wallet-Autorisierung](/de/crypto/wallet-approval/)

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

## Quellen

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