Krypto Permit2 ist ein von Uniswap Labs entwickeltes Autorisierungssystem, das die Nutzung von ERC-20-Token in Anwendungen vereinheitlicht. Es ersetzt weder die Wallet noch macht es eine gefährliche Signatur sicher. Stattdessen trennt Permit2 das Onchain-Approval des Tokens von den Berechtigungen, die der Nutzer für eine bestimmte Anwendung signiert. Das kann wiederholte Transaktionen und verstreute Allowances reduzieren, führt aber zu einer entscheidenden Sicherheitsfrage: Nachdem ein Token für Permit2 freigegeben wurde, kann eine bösartige Signatur echte finanzielle Verfügungsgewalt übertragen.
Für eine sichere Nutzung sind deshalb drei getrennte Prüfungen nötig: Welcher Vertrag erhält das ERC-20-Approval, was steht genau in der signierten Nachricht und welcher Spender darf anschließend handeln? Dieser Ratgeber erklärt die beiden Transfermodelle, Expiration und Nonce, Phishing-Risiken, technische Grenzen sowie das Prüfen und Widerrufen von Rechten, ohne eine Offchain-Signatur mit einer harmlosen Anmeldung zu verwechseln.
Krypto Permit2: Was sich tatsächlich ändert
Im herkömmlichen ERC-20-Ablauf sendet der Nutzer vor der Verwendung einer dApp eine Transaktion approve(spender, amount) an den Token-Vertrag. Der Spender, meistens ein Router, darf danach transferFrom bis zur genehmigten Höhe aufrufen. Jeder neue Spender benötigt eine eigene Allowance und Onchain-Transaktion; eine unbegrenzte Freigabe kann jahrelang bestehen bleiben.
Bei Permit2 genehmigt der Nutzer zunächst den Permit2-Vertrag als ERC-20-Spender. Integrierte Anwendungen fordern danach feinere Berechtigungen über EIP-712-Signaturen an. Permit2 prüft Signatur, Domain, Spender, Token, Betrag, Ablauf und Nonce, bevor Token bewegt werden. Die Anwendung erbt nicht automatisch die primäre ERC-20-Allowance. Sie erhält ausschließlich die im signierten Text und im verwendeten Modul definierte Verfügungsgewalt.
Der operative Vorteil ist klar: Ein gemeinsamer Vertrag kann mehreren Protokollen dienen, und spätere Autorisierungen brauchen nicht immer eine weitere Approval-Transaktion. Dafür wird die Zustimmung weniger intuitiv. Die Wallet kann „Signieren“ und null Gasgebühr anzeigen, obwohl die Nachricht den Transfer zuvor für Permit2 freigegebener Token erlaubt.
AllowanceTransfer und SignatureTransfer im Vergleich
Permit2 stellt zwei unterschiedliche Mechanismen bereit. Die Entscheidung hängt davon ab, ob wiederverwendbare Rechte oder eine einzelne Ausführung gebraucht werden.
| Frage | AllowanceTransfer | SignatureTransfer |
|---|---|---|
| Was wird erlaubt? | Gespeicherte Allowance für Eigentümer, Token und Spender | Ein signierter Transfer oder Batch |
| Bleibt das Recht bestehen? | Ja, bis Restbetrag oder Ablauf erreicht ist | Nach Standardausführung nicht; die Nonce ist verbraucht |
| Welche Grenzen gibt es? | Betrag, Spender und Expiration | Token, Höchstbetrag, Spender, Deadline und Nonce |
| Geeigneter Einsatz | Wiederkehrende Nutzung einer vertrauenswürdigen dApp | Einzelaktion oder atomarer Batch |
| Typisches Risiko | Zu große, dauerhaft aktive Allowance | Gestohlene Signatur vor ihrer Deadline |
AllowanceTransfer speichert eine Berechtigung im Vertrag. Die Anwendung kann sie über mehrere Vorgänge hinweg innerhalb des Restbetrags und vor Ablauf verbrauchen. SignatureTransfer nutzt eine Signatur für einen unmittelbaren Transfer. Ungeordnete Bitmap-Nonces erlauben unabhängige Permits ohne starre Reihenfolge. Die Witness-Variante bindet zusätzliche Anwendungsdaten an die Signatur, doch die Integration muss diese Daten korrekt definieren, anzeigen und prüfen.
Das ERC-20-Approval für Permit2 bildet die Grundlage
Der erste Schritt bleibt eine normale Onchain-Transaktion an den Token-Vertrag. Im Spender-Feld muss die offizielle Permit2-Vertragsadresse des aktiven Netzwerks stehen – nicht die Website, der dApp-Router oder eine aus einer Nachricht kopierte Adresse. Vor der Bestätigung sollten Chain, Token-Vertrag, Spender und Betrag mit der offiziellen Dokumentation der Anwendung verglichen werden.
Ein exakt bemessenes Approval begrenzt das Risiko, muss aber erneuert werden. Eine hohe Allowance spart später Reibung und Gas, vergrößert jedoch den zugänglichen Betrag, falls der Eigentümer danach eine gefährliche Berechtigung signiert. Eine unbegrenzte Freigabe erlaubt nicht automatisch jeder Website den Zugriff: Sie befähigt Permit2, Token unter einer gültigen Autorisierung zu bewegen. Trotzdem ist sie eine weitreichende, langlebige Berechtigung und Teil der Angriffsfläche.
Der primäre Widerruf setzt die ERC-20-Allowance des Tokens für Permit2 auf null. Das ist der umfassendste Stoppschalter: Weitere Permit2-Transfers dieses Tokens scheitern auch dann, wenn interne Berechtigungen noch nicht abgelaufen sind. Die Transaktion kostet Gas und muss auf derselben Chain sowie am selben Token-Vertrag wie das ursprüngliche Approval ausgeführt werden.
EIP-712-Signaturen, Expiration, Deadline und Nonce
Typisierte EIP-712-Signaturen lassen sich decodieren, weil sie eine Domain und strukturierte Felder enthalten. Die Domain bindet eine Signatur gewöhnlich an Namen, Chain-ID und Verifizierungsvertrag. Eine übersichtlich formatierte Wallet-Anfrage beweist dennoch keine Sicherheit. Der Nutzer muss prüfen, ob Permit2 der Verifizierungsvertrag ist, die Chain stimmt und der angegebene Spender für den Vorgang tatsächlich erforderlich ist.
Bei AllowanceTransfer bestimmt expiration, wie lange der Spender die gespeicherte Allowance nutzen darf. Die nonce ordnet Aktualisierungen und verhindert die Wiederverwendung einer ersetzten alten Berechtigung. Eine getrennte sigDeadline begrenzt, wann die Signatur zur Einrichtung der Allowance on-chain eingereicht werden kann. Allowance-Ablauf und Einreichungsfrist der Signatur sind somit zwei verschiedene Kontrollen.
Bei SignatureTransfer legt die deadline den letzten Zeitpunkt für die Ausführung des signierten Transfers fest. Danach wird die Nonce als benutzt markiert, sodass ein Replay scheitert. Eine Nonce verhindert eine zweite Ausführung, nicht die erste bösartige Ausführung. Wurde die Signatur einer feindlichen Website übergeben, verkürzt eine knappe Deadline zwar das Zeitfenster, ruft offengelegte Daten aber nicht zurück.
Praxisbeispiel: Regelmäßiger Swap oder Einzelaktion
Ein Nutzer hält 5.000 USDC und möchte 300 USDC über einen Aggregator tauschen. Die Website verlangt zuerst das ERC-20-Approval von USDC für Permit2. Der Nutzer prüft Netzwerk, echten USDC-Vertrag und Permit2-Adresse und wählt anschließend einen begrenzten Betrag statt eines unbegrenzten Maximums.
Für einen einzelnen Swap passt häufig SignatureTransfer. Die signierte Nachricht nennt USDC, maximal 300, den Spender des Aggregators, eine unbenutzte Nonce und eine kurze Deadline. Der aufrufende Vertrag darf bei geänderter Ausführung weniger als das Maximum ausgeben, aber niemals mehr. Scheitert der Swap, bevor die Nonce verbraucht wurde, kann die Signatur bis zur Deadline ausführbar bleiben. Eine Fehlermeldung der Oberfläche hebt sie nicht automatisch auf.
Führt derselbe Nutzer wöchentlich Swaps über ein sorgfältig geprüftes Protokoll aus, kann AllowanceTransfer wiederholte Anfragen reduzieren. Denkbar sind 1.000 USDC für den Spender mit einer Expiration von 30 Tagen und eine Verlängerung nur bei Bedarf. Am Periodenende werden sowohl die interne Permit2-Allowance als auch das zugrunde liegende ERC-20-Approval geprüft.
Grenzen und Pflichten, die Permit2 nicht beseitigt
Permit2 funktioniert nur mit Token, die sich kompatibel zum ERC-20-Modell verhalten und für die der Eigentümer das erforderliche Approval erteilt hat. Der native Netzwerk-Asset lässt sich ohne ERC-20-Repräsentation wie WETH nicht bewegen. Ungewöhnliches Token-Verhalten, Pausen, Blacklists, Transfergebühren oder ein unzureichendes Guthaben können die Ausführung scheitern lassen.
Permit2 bestätigt nicht, dass ein Spender ehrlich ist. Der Vertrag prüft die gültige Autorisierung und setzt deren Grenzen durch; er erkennt nicht, ob ein Nutzer eine gefälschte Seite missverstanden hat. Auch die dApp-Integration ist relevant. Fehler beim Witness, eine unzureichende Bindung des Aufrufers oder mehrdeutige Anzeigen können erwartete Garantien schwächen. Hintergrund liefern die CryptoRoad-Ratgeber zu Smart Contracts und ihren Risiken sowie zur Funktionsweise von DeFi.
Ein Widerruf holt bereits transferierte Mittel nicht zurück. Wird nur eine interne Berechtigung gelöscht, bleibt das ERC-20-Approval für Permit2 aktiv. Umgekehrt blockiert ein Token-Approval von null die unmittelbare Nutzung, bereinigt aber nicht zwingend interne Permit2-Einträge. Beide Ebenen müssen getrennt kontrolliert werden.
Signatur-Phishing: Diese Warnzeichen zählen
Modernes Phishing vermeidet häufig eine sichtbar teure Transaktion und fordert stattdessen eine Signatur „zur Anmeldung“, „zur Wallet-Verifizierung“ oder „für einen Airdrop“. Zeigt die Wallet Permit2, PermitSingle, PermitBatch oder einen typisierten Transfer, handelt es sich nicht um eine gewöhnliche Authentifizierung. Die Anfrage kann eine Allowance einrichten oder Tokenbewegungen erlauben.
- Die Domain stammt aus einer Anzeige, Direktnachricht, dringenden E-Mail oder einem gesponserten Suchtreffer.
- Der Spender weicht vom dokumentierten Vertrag der echten dApp ab.
- Höchstbetrag oder Batch umfassen Token, die für die versprochene Aktion unnötig sind.
- Expiration oder Deadline liegen weit in der Zukunft, oder die Wallet decodiert wichtige Felder nicht.
- Nach einem Fehler werden weitere Signaturen verlangt, ohne die vorige Nonce zu erklären.
Eine undurchsichtige Nachricht abzulehnen ist richtig. Eine Hardware-Wallet schützt das Schlüsselmaterial, nicht die Entscheidung: Bestätigt der Nutzer darauf eine schädliche Signatur, ist sie gültig. Größere Guthaben gehören getrennt von der täglichen dApp-Wallet verwahrt, wie der Überblick zu Custodial-, Non-Custodial-, Hot- und Cold-Wallets erläutert.
Allowances und Signaturen prüfen und widerrufen
Die Prüfung beginnt bei einem seriösen Explorer oder Allowance-Manager, der über ein Lesezeichen geöffnet wird. Nach Auswahl des richtigen Netzwerks wird zuerst die Token-Allowance für Permit2 untersucht. Danach folgen die internen Permit2-Allowances nach Eigentümer, Token und Spender. Ein herkömmlicher Approval-Checker zeigt womöglich nur die erste Ebene und übersieht sekundäre Rechte.
Eine dauerhafte Allowance lässt sich über die Lockdown- beziehungsweise Widerrufsfunktion von Permit2 oder eine transparente Oberfläche mit dem richtigen Call entfernen. SignatureTransfer besitzt keine klassische Rest-Allowance: Benutzte Nonces sind nicht erneut ausführbar, unbenutzte können über die Bitmap-Funktionen invalidiert werden. Eine nicht weitergegebene Signatur mit naher Deadline kann verfallen; nach einer Offenlegung sollte ihre Nonce aktiv ungültig gemacht werden.
Bei Verdacht auf Kompromittierung hat das Zurücksetzen des ERC-20-Approvals für Permit2 bei betroffenen Token Priorität. Direkte Spender sollten ebenfalls widerrufen und die Assets in eine saubere Wallet verschoben werden, falls Seed Phrase oder Private Key offengelegt sein könnten. Der CryptoRoad-Leitfaden zum Widerrufen von Krypto-Approvals trennt noch bestehende Rechte von bereits erfolgten Transfers.
Häufige Fehler und bessere Entscheidungen
Jede Signatur für harmlos halten. Eine Permit2-Signatur kann wirtschaftlich einer Autorisierung entsprechen. Token, Spender, Betrag und Zeitgrenzen müssen gelesen werden.
Im falschen Netzwerk widerrufen. Allowances gelten je Chain, Token und Eigentümer. Ein Widerruf auf Ethereum verändert die entsprechende Position auf einer L2 nicht.
Nur das Token-Symbol prüfen. Gefälschte Token können Namen und Kürzel kopieren. Maßgeblich ist die Vertragsadresse.
Standardmäßig unbegrenzt freigeben. Das ist nur sinnvoll, wenn Häufigkeit, Gaskosten und Vertrauen in den Spender das Risiko rechtfertigen. Für eine Einzelaktion sind begrenzter Betrag und kurze Deadline besser.
Nach einem Timeout erneut signieren. Die erste Anfrage kann weiter gültig sein. Vor einer neuen Signatur müssen Transaktionsstatus, Nonce und Ablauf geprüft werden.
Checkliste für eine saubere Wallet-Hygiene
- dApps über Lesezeichen öffnen und Domain, Netzwerk sowie Vertrag prüfen.
- Nur das für laufende Vorgänge nötige Kapital in der operativen Wallet halten.
- Die offizielle Permit2-Adresse für die verwendete Chain bestätigen.
- Bei einmaligen Aktionen begrenzte Beträge und kurze Laufzeiten wählen.
- Spender, Token, Betrag, Expiration, Deadline und Nonce vor der Signatur lesen.
- Nicht decodierte Nachrichten und unbegründete Token-Batches ablehnen.
- ERC-20-Approvals und interne Permit2-Allowances regelmäßig kontrollieren.
- Rechte nach Kampagnen, Mints, Einzel-Swaps und Tests widerrufen.
- Eine Seed Phrase niemals auf einer Widerrufs- oder Support-Website eingeben.
- Nach verdächtiger Signatur Rechte invalidieren und bei möglichem Schlüsseldiebstahl Assets verschieben.
Fazit: Komfort nutzen, Sicherheit nicht delegieren
Krypto Permit2 vereinfacht dApp-Interaktionen durch ein zentrales ERC-20-Approval und feinere signierte Berechtigungen. AllowanceTransfer eignet sich für wiederkehrende Beziehungen, hinterlässt aber bis zum Verbrauch oder Ablauf nutzbare Rechte. SignatureTransfer ist mit Anti-Replay-Nonce und Deadline auf Einzelvorgänge ausgelegt; eine gestohlene Signatur kann dennoch einmal ausgeführt werden.
Die praktische Regel lautet, beide Ebenen zu trennen: zuerst das Token-Approval für Permit2 prüfen, danach die signierte Berechtigung für den Anwendungs-Spender. Niedrige Limits, kurze Laufzeiten, getrennte Wallets und regelmäßige Kontrollen begrenzen Fehlerfolgen. Keine Oberfläche ersetzt die Prüfung von Vertragsadresse und signierten Feldern.
