---
title: "Risiko einer Permit2-Signatur"
description: "Permit2 trennt wiederverwendbare Allowances von einmaligen Signaturübertragungen; sicheres Signieren erfordert die genaue Prüfung von Deployment, Domain, spender, Empfänger, Betrag, Nonce, Frist, Witness und Ausführungs-Calldata."
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.
# Risiko einer Permit2-Signatur
> Nur zu Bildungszwecken; keine Anlageberatung oder Anlageempfehlung. Anlagen können zu Verlusten führen.
## Direkte Antwort
Permit2 verbindet zwei getrennte Autorisierungssysteme. `AllowanceTransfer` speichert eine wiederverwendbare Owner-Token-spender-Allowance mit Betrag, Ablauf und geordneter Nonce. `SignatureTransfer` verbraucht einen einmal signierten Höchstbetrag mit ungeordneter Bitmap-Nonce und erzeugt keine dauerhafte spender-Allowance. Beide hängen weiterhin von der ERC-20-Allowance des Owners für Permit2 ab.
Eine gaslose Signatur kann Vermögenswerte bewegen, wenn spender oder Relayer die Ausführung bezahlt. Exakte Chain, bereitgestellten Permit2-Code, EIP-712-Domain, Modul, Token, spender, signierten Höchstbetrag, Empfänger-Calldata, Nonce und Uhren prüfen. Der echte Permit2-Vertrag macht bösartige spender, Empfänger, Router oder Witness nicht sicher.
## Funktionsweise
1. `chainId`, Netzwerk, Permit2-`verifyingContract`, bereitgestellten Runtime-Code, Token-Adresse und Dezimalstellen, Owner-Wallet-Typ und beabsichtigte Anwendung festlegen. Einen offiziellen Deployment-Eintrag verwenden; bekannte Adresse oder Bezeichnung genügt nicht.
2. Vorgelagerte ERC-20-Allowance und Saldo des Owners für Permit2 lesen. Endliche oder unbegrenzte Genehmigung und tokenspezifisches Übertragungsverhalten erkennen; dieses Buch überlebt den Ablauf einer Permit2-Signatur oder gespeicherten nachgelagerten Allowance.
3. Exakten Pfad und signierten Primary Type erkennen: AllowanceTransfer `PermitSingle` oder `PermitBatch`, beziehungsweise SignatureTransfer `PermitTransferFrom` oder dessen Batch- und Witness-Varianten. `transferFrom` nicht als signierten Typ behandeln.
4. EIP-712-Domain und jeden Nachrichteneintrag decodieren. Bei AllowanceTransfer Token, `uint160 amount`, `expiration`, geordnete Nonce, spender und `sigDeadline` prüfen. Bei SignatureTransfer erlaubten Token und Betrag, ungeordnete Nonce, Deadline sowie den über den Caller-Kontext gebundenen spender prüfen.
5. Ausführungs-Calldata getrennt decodieren. Bei einfachem SignatureTransfer sind `SignatureTransferDetails.to` und `requestedAmount` Ausführungsparameter, keine Felder des signierten Basis-Permits; der angeforderte Betrag muss lediglich unter dem signierten Maximum bleiben. Jeden Batch-Index sowie exakten Witness-Hash und Type String prüfen.
6. Aktuelle geordnete Allowance-Nonce oder ungeordnetes Bitmap-Wort und Bit abfragen und exakten Caller, Calldata, Chain und Zustand simulieren. Empfänger, Router-Aktionen, Token-Eigenheiten, Saldo und beide Allowance-Bücher abstimmen; Simulation kann sich durch Zustand, Reihenfolge oder Reorganisation ändern.
7. Beträge und Laufzeiten minimieren. Bei Verdacht Typed Data aufbewahren und korrekten vorgelagerten Revoke, nachgelagerten Allowance-Revoke oder Nonce-Invalidierung über vertrauenswürdigen Pfad einreichen, als Mempool-Rennen behandeln; Bestätigung abwarten und Übertragungen, Salden, Allowances und Bits abstimmen.
Das `sigDeadline` von AllowanceTransfer begrenzt, wann das signierte Permit gespeicherte Autorität anlegen oder ändern darf; `expiration` begrenzt deren Nutzung. Die Deadline von SignatureTransfer begrenzt die einmalige Ausführung. EIP-712 liefert typisierten Hash und Domain-Trennung, nicht Replay-Schutz oder Absichtssicherheit; Permit2-Nonce und -Frist setzen diese Grenzen.
Bei einer Vertrags-Wallet hängt ERC-1271-Gültigkeit von aktueller `isValidSignature`-Policy, Modulen, Schwellen und Code ab. Labels, abgeschnittene Hardware-Wallet-Anzeigen und erfolgreiche Simulationen sind Indizien, keine Garantien. Das Trennen eines Frontends widerruft weder Genehmigung noch Signatur.
## Beispiele
- **Zwei Allowance-Bücher.** Die endliche Token-Allowance für Permit2 beginnt bei `1,000 USDC`; ein `PermitSingle` speichert `600 USDC` für spender S. Nach einer Übertragung von `225 USDC` durch S verbleiben `600 - 225 = 375 USDC`; eine standardmäßige endliche vorgelagerte Token-Allowance wird zu `1,000 - 225 = 775 USDC`. Ablauf oder Widerruf von 375 beseitigt 775 nicht; nicht standardmäßige Token können abweichen.
- **Einmaliger Empfänger und Betrag.** SignatureTransfer signiert maximal `250 USDC`; Calldata fordert `180 USDC` für einen Händler. Bei ausreichendem Saldo und vorgelagerter Allowance kann die Ausführung 180 übertragen. Die Nonce wird verbraucht, also sind die ungenutzten `70 USDC` nicht wiederverwendbar. Nennt die Calldata einen Angreifer, verhindert das Basis-Permit diese Umleitung durch den gebundenen spender nicht.
- **Ungeordnete Nonce-Bitmap.** Für Nonce `513` gelten `wordPos = 513 >> 8 = 2`, `bitPos = 513 & 255 = 1` und `mask = 1 << 1 = 2`. Die Ausführung setzt Bit 1 in Wort 2; Wiederholung von 513 scheitert, während Nonce `512` an Bit 0 unabhängig bleibt.
- **Widerrufsrennen.** Eine gespeicherte Allowance beträgt `400 USDC`. Der Owner sendet Widerruf auf null, aber zuerst wird eine Übertragung von `300 USDC` ausgeführt, sodass `100 USDC` verbleiben; der spätere Widerruf setzt den Rest auf `0`. Endgültige Allowance null macht den realisierten Verlust von `300 USDC` nicht rückgängig; Reihenfolge und Salden sind abzustimmen.
## Risiken
- Falsche Chain ID, Deployment oder Runtime-Code.
- Gefälschter oder unerwarteter Verifying Contract.
- Verwechslung von AllowanceTransfer und SignatureTransfer.
- Bösartiger oder irrtümlicher spender und Caller.
- Durch Ausführungs-Calldata gewählter Empfänger.
- Angeforderter Betrag nahe dem signierten Maximum.
- Falsche Token-Adresse, Symbol, Dezimalstellen oder Raw-Einheiten.
- Dauerhafte oder unbegrenzte vorgelagerte ERC-20-Genehmigung.
- Übermäßiger nachgelagerter Betrag oder Ablauf.
- Verwechslung von Deadline, Signature Deadline und Expiration.
- Veraltete oder in einem Rennen befindliche geordnete Nonce.
- Wiederverwendetes Bitmap-Bit oder zu breite Invalidierungsmaske.
- Abweichender Witness-Hash oder exakter Type String.
- Versteckter, doppelter oder falsch indexierter Batch-Eintrag.
- Frontend-Anzeige oder Calldata weicht von der Absicht ab.
- Widerruf verliert Mempool- oder MEV-Rennen.
- Änderung von ERC-1271-Modul, Signer, Schwelle oder Upgrade.
- Fee-on-Transfer-, Rebasing-, pausierter, blockierter oder Callback-Token.
- Zustandsdrift, Fehlschlag oder Reorganisation nach Simulation.
- Hardware-Wallet-Bestätigung oder Trennung wird mit Sicherheit verwechselt.
## Häufige Irrtümer
- **Eine Signatur ohne Gas-Abfrage kann keine Token bewegen.** Eine andere Partei kann das Ausführungs-Gas bezahlen.
- **Die offizielle Permit2-Adresse beweist, dass spender und Empfänger sicher sind.** Permit2 kann bösartige Autorität korrekt ausführen.
- **SignatureTransfer und AllowanceTransfer erzeugen dieselbe dauerhafte Berechtigung.** Eines wird einmalig genutzt, das andere speichert wiederverwendbare Allowance.
- **Trennen oder Widerrufen einer Ebene beendet alle Pfade und ausstehenden Signaturen.** Vorgelagerter, nachgelagerter und Nonce-Zustand sind getrennt; Rennen bleiben.
- **EIP-712, Hardware-Wallet oder erfolgreiche Simulation beweist Absicht und Finalität.** Sie verbessern Sichtbarkeit oder Tests, ersetzen aber keine Prüfung von Feldern, Calldata und bestätigtem Zustand.
## Verwandte Themen
- [EIP-712-Signatur für typisierte Daten](/de/crypto/eip712-typed-signature/)
- [Wallet-Genehmigung](/de/crypto/wallet-approval/)
- [Wallet-Signatur](/de/crypto/wallet-signature/)
## Quellen
- [Overview](https://developers.uniswap.org/docs/protocols/permit2/overview) - Uniswap Developers (abgerufen am 2026-08-13)
- [Allowance Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/allowance-transfer) - Uniswap Developers (abgerufen am 2026-08-13)
- [Signature Transfer](https://developers.uniswap.org/docs/protocols/permit2/concepts/signature-transfer) - Uniswap Developers (abgerufen am 2026-08-13)
- [Deployments](https://developers.uniswap.org/deployments) - Uniswap Developers (abgerufen am 2026-08-13)
- [PermitHash.sol](https://github.com/Uniswap/permit2/blob/main/src/libraries/PermitHash.sol) - Uniswap Permit2 (abgerufen am 2026-08-13)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (abgerufen am 2026-08-13)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (abgerufen am 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen am 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/permit2-signature-risk/index.mdx