ERC-2612 Permit erklärt: Token-Freigaben per Signatur und Risiken
Eine Freigabe von Kryptowährungen ist nicht dasselbe wie eine Überweisung. Wer mit dezentralen Anwendungen arbeitet, erlaubt einem Smart Contract häufig zuerst, eine bestimmte Menge seiner ERC-20-Token zu bewegen. ERC-2612 erweitert diesen Mechanismus: Statt selbst eine separate Freigabetransaktion zu senden, unterschreibst Du eine strukturierte Nachricht. Eine andere Partei kann diese Signatur später in einer Blockchain-Transaktion einreichen. Das kann Abläufe vereinfachen, eröffnet aber neue Angriffsflächen.
Dieser Leitfaden konzentriert sich ausschliesslich auf den ERC-2612-Standard und seine technische und praktische Bedeutung. Allgemeine Token-Approvals, die Sicherheitsgrundlagen von Wallets und Account Abstraction behandeln wir in separaten Beiträgen. Du erfährst, wie Permit funktioniert, was genau Du unterschreibst, weshalb eine Signatur nicht automatisch harmlos ist und wie Du eine verdächtige Freigabe beurteilst.
Was ist ERC-2612?
ERC-2612 ist eine Erweiterung des ERC-20-Tokenstandards um eine signaturbasierte Freigabe namens permit. ERC-20 beschreibt unter anderem Guthaben, Transfers und das Zusammenspiel von approve, allowance und transferFrom. ERC-2612 ersetzt diese Funktionen nicht. Es ergänzt einen alternativen Weg, eine Allowance zu setzen. Die ausführliche Spezifikation beschreibt die Funktionen permit, nonces und DOMAIN_SEPARATOR. Ob ein konkreter Token diesen Standard tatsächlich implementiert, muss am jeweiligen Contract geprüft werden.
Bei der klassischen Variante schickt der Tokeninhaber eine approve-Transaktion an den Token-Contract. Diese verändert die Allowance auf der Blockchain und kostet Netzwerkgebühren. Bei Permit erzeugt der Inhaber zunächst nur eine kryptografische Signatur ausserhalb der Blockchain. Die Blockchain verändert ihren Zustand erst, wenn jemand permit mit dieser Signatur erfolgreich aufruft. Eine signierte Nachricht ist daher keine abgeschlossene Freigabe, sondern eine potenziell einlösbare Autorisierung.
Warum gibt es Permit überhaupt?
Bei einer typischen DeFi-Anwendung musste ein neuer Nutzer früher oft zwei Schritte ausführen: zunächst einen Token freigeben, anschliessend den eigentlichen Tausch oder die Einzahlung starten. Für beide Schritte konnten separate Blockchain-Transaktionen nötig sein. Das ist umständlich und kann verlangen, dass die Wallet bereits den nativen Coin für Gebühren besitzt. Ein signierter Permit lässt sich dagegen von einer anderen Adresse übermitteln und mit weiteren Aktionen kombinieren, wenn die beteiligten Contracts dies unterstützen.
Wichtig ist die Unterscheidung zwischen gasloser Unterschrift und gebührenfreier Ausführung. Die Unterschrift selbst ist keine On-Chain-Transaktion. Irgendjemand muss die anschliessende Blockchain-Transaktion bezahlen. Das kann eine Anwendung, ein Relayer oder indirekt der Nutzer über einen anderen Kostenmechanismus sein. ERC-2612 garantiert weder eine kostenlose Dienstleistung noch einen günstigen Swap. Auch schützt der Standard nicht vor schlechtem Preis, Slippage oder einem bösartigen Empfänger.
Der Ablauf Schritt für Schritt
1. Die Anwendung formuliert eine konkrete Berechtigung
Zunächst werden die Angaben zusammengestellt: owner ist die Adresse des Tokeninhabers, spender die berechtigte Adresse, value die Tokenmenge in kleinsten Einheiten, nonce eine fortlaufende Nummer und deadline die zeitliche Grenze. Zusätzlich wird eine EIP-712-Domain verwendet, die normalerweise den Namen und die Version des Token-Contracts, die Chain-ID und die verifizierende Contract-Adresse einbindet. Die genaue Implementierung muss zum Token passen.
2. Die Wallet unterschreibt strukturierte Daten
Die Wallet erzeugt mit dem privaten Schlüssel eine Signatur über die definierten Daten. Der private Schlüssel wird dabei nicht an die Anwendung übermittelt. Trotzdem ist die Signatur rechtlich und technisch nicht bloss eine unverbindliche Lesebestätigung: Sie kann die Grundlage für eine spätere Änderung Deiner Token-Berechtigungen sein. Besonders wichtig ist deshalb, die tatsächlich angezeigten Felder zu verstehen. Unklare Signaturdialoge sind ein Anlass, den Vorgang abzubrechen.
3. Eine Transaktion löst die Berechtigung ein
Ein Relayer oder ein anderer Aufrufer übergibt die Signatur an permit. Der Contract prüft unter anderem Signatur, Nonce, Frist und die EIP-712-Domain. Bei Erfolg wird die Allowance für den angegebenen Spender gesetzt, die Nonce erhöht und ein Approval-Ereignis ausgelöst. Die Transaktion kann danach, sofern die Architektur dies vorsieht, mit einem transferFrom oder einer weiteren Protokollaktion verbunden werden. Der Aufrufer muss nicht mit owner identisch sein.
Welche Daten sind sicherheitsentscheidend?
Der Wert owner bezeichnet die Wallet, deren Token freigegeben werden. Spender ist die Adresse, die anschliessend innerhalb der erlaubten Menge Token bewegen darf. Die value-Angabe ist nicht automatisch ein Betrag in ETH oder Franken, sondern eine Ganzzahl in den kleinsten Einheiten des jeweiligen Tokens. Deadline ist typischerweise ein Unix-Zeitstempel. Nonce verhindert, dass dieselbe gültige Autorisierung beliebig oft wiederholt wird. Der Domain Separator grenzt die Signatur an einen bestimmten Kontext.
Diese Felder wirken gemeinsam. Eine korrekte Nonce allein schützt nicht vor einer bösartigen Freigabe, und eine kurze Frist schützt nicht vor einem unmittelbar ausgeführten Angriff. Eine Domain mit Chain-ID und Contract-Adresse erschwert die Wiederverwendung der Signatur in einem anderen Netzwerk oder bei einem anderen Token. Der Schutz hängt allerdings von der korrekten Implementierung ab. Bei abweichenden Token-Varianten können andere Datenformate und Regeln gelten.
Rechenbeispiel: Freigabe von 250 Token
Angenommen, ein Token verwendet sechs Dezimalstellen. Du möchtest 250 Einheiten für einen seriösen Contract freigeben. Im Signaturfeld value steht dann 250 × 1 000 000 = 250 000 000 Basiseinheiten. Die Zahl ist nicht mit 250 Millionen ganzen Token gleichzusetzen. Wird value stattdessen auf eine sehr grosse Ganzzahl gesetzt, kann die Freigabe praktisch unbegrenzt wirken. Ohne Kenntnis der decimals und der genauen Tokenadresse lässt sich eine solche Zahl nicht seriös beurteilen.
Nehmen wir weiter an, der Contract darf 250 Token ausgeben und verbraucht davon 90. Dann bleiben bei einer üblichen ERC-20-Allowance grundsätzlich 160 Token an Freigabe übrig, solange keine andere Änderung erfolgt. Wenn der Tokenpreis später steigt, steigt auch der finanzielle Gegenwert der verbleibenden Berechtigung. Deshalb ist eine unnötig hohe oder zeitlich unbeschränkte Allowance riskant, selbst wenn der ursprüngliche Vorgang klein war.
ERC-2612 gegenüber klassischem approve
Beim klassischen approve unterschreibst und sendest Du eine On-Chain-Transaktion. Die Freigabe ist danach unmittelbar als Zustand im Token-Contract gespeichert. Bei ERC-2612 signierst Du zunächst Off-Chain-Daten, die erst durch einen erfolgreichen permit-Aufruf wirksam werden. Beide Wege können letztlich zur gleichen Allowance führen. Der Sicherheitsunterschied liegt insbesondere darin, dass eine noch nicht eingereichte Permit-Signatur ausserhalb der Blockchain existieren kann und deshalb in einem gewöhnlichen Explorer noch nicht als aktive Freigabe sichtbar sein muss.
Eine weitere Feinheit: Die Deadline begrenzt das Zeitfenster, in dem die Signatur eingereicht werden darf. Sie bedeutet nicht automatisch, dass eine bereits gesetzte Allowance zum gleichen Zeitpunkt erlischt. Wird permit rechtzeitig eingelöst, bleibt die daraus entstandene Freigabe nach den normalen Tokenregeln bestehen, bis sie verbraucht oder verändert wird. Wer diese beiden Zeitbegriffe verwechselt, unterschätzt möglicherweise sein Risiko.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Gutscheincode: AUSWANDERNSCHWEIZ. Relai verkauft hier keine der im Fachartikel besprochenen Altcoins.
EIP-712 und der Domain Separator
EIP-712 definiert die Signatur strukturierter Daten. Der Nutzer soll nicht bloss einen undurchsichtigen Hash bestätigen, sondern typisierte Informationen zu einer bestimmten Aktion. Die Domain dient der Trennung verschiedener Anwendungen und Contracts. Bei einer verbreiteten Konstruktion enthält sie Name, Version, chainId und verifyingContract. Der kryptografische Hash der Domain und der Nachricht bildet die Grundlage der Unterschrift. Ob die Wallet die Daten tatsächlich verständlich darstellt, hängt vom Wallet-Programm und der Anwendung ab.
Eine sauber implementierte Domain verhindert nicht jede Form von Betrug. Wenn Du eine gültige Freigabe für einen bösartigen Spender unterschreibst, ist die Signatur auch dann gefährlich, wenn die Chain-ID korrekt ist. Zudem existieren Token mit historisch abweichenden Permit-Varianten. Der DAI-Stil verwendet beispielsweise andere Parameter als die standardisierte ERC-2612-Variante. Verlass Dich daher nicht allein auf die Bezeichnung Permit in einer Benutzeroberfläche.
Nonce und Schutz gegen Replay-Angriffe
Jede erfolgreiche ERC-2612-Permit-Ausführung erhöht die für den Tokeninhaber gespeicherte Nonce. Ein erneuter Versuch mit derselben Signatur scheitert, weil die signierte Nonce nicht mehr zum aktuellen Zustand passt. Dieses Prinzip verhindert das einfache mehrfache Einlösen einer einzelnen Autorisierung auf demselben korrekt implementierten Contract. Es verhindert jedoch nicht, dass ein Angreifer eine bisher unbenutzte Signatur zuerst einreicht.
Eine signierte Freigabe kann deshalb eine Art ausstehende Option darstellen. Solange die Deadline noch nicht erreicht ist und die Nonce unverändert bleibt, könnte jemand mit der Signatur sie einreichen. Das blosse Löschen einer Nachricht aus Deinem Browser oder einer Anwendung widerruft diese kryptografische Möglichkeit nicht. Die praktische Invalidierung hängt vom jeweiligen Token und dessen verfügbaren Funktionen ab. Das kann technisch aufwendig sein und erfordert eine gezielte Prüfung.
Permit-Phishing: Wie der Angriff funktioniert
Bei Permit-Phishing bringt eine betrügerische Website den Nutzer dazu, eine scheinbar harmlose Signaturanfrage zu bestätigen. Die Seite behauptet beispielsweise, die Signatur diene nur dem Login, der Teilnahme an einem Airdrop oder einer Kontoprüfung. Tatsächlich kann sie eine weitreichende Token-Freigabe an eine vom Angreifer kontrollierte Adresse enthalten. Sobald die Signatur gültig ist, kann der Angreifer sie einreichen und die daraus entstandene Allowance ausnutzen.
Das Gefährliche ist die fehlende offensichtliche Transaktionsgebühr beim Unterschreiben. Manche Nutzer haben gelernt, dass nur kostenpflichtige Blockchain-Transaktionen Geld bewegen können. Das ist falsch. Eine Off-Chain-Signatur kann später eine On-Chain-Berechtigung auslösen. Auch die Tatsache, dass eine Website ein bekanntes Wallet-Logo zeigt, ist kein Sicherheitsbeweis. Entscheidend sind die Contract-Adresse, der Spender, die Menge, die Frist und die konkrete Signaturart.
Warnzeichen vor der Unterschrift
Besonders verdächtig sind unerwartete Aufforderungen zu unbegrenzten Freigaben, Domains mit vertauschten Buchstaben, angeblich dringende Sicherheitsüberprüfungen und Signaturdialoge ohne verständliche Angaben zum Spender. Prüfe die Zieladresse nicht nur anhand der ersten und letzten Zeichen. Nutze offizielle Projektlinks und unabhängige Contract-Referenzen. Wenn die Wallet nur einen unlesbaren Datenblock anzeigt, ist es vernünftiger, nicht zu signieren, statt den unbekannten Inhalt zu erraten.
Eine Hardware-Wallet schützt den privaten Schlüssel davor, einfach aus dem Gerät ausgelesen zu werden. Sie schützt aber nicht zuverlässig davor, dass Du selbst eine gefährliche Signatur autorisierst. Auch ein zweites Gerät kann einen Phishing-Vorgang nicht automatisch erkennen. Sicherheit entsteht durch die Kombination aus überprüfbarer Anzeige, sorgfältiger Adresskontrolle, begrenzten Berechtigungen und einem bewussten Umgang mit neuen Anwendungen.
Was passiert, wenn eine Signatur bereits abgegeben wurde?
Zuerst solltest Du die verdächtige Website verlassen und keine weiteren Signaturen abgeben. Danach musst Du unterscheiden, ob die Permit-Signatur bereits eingelöst wurde oder noch aussteht. Bei einer bereits eingelösten Freigabe kann eine Reduktion oder Aufhebung der Allowance erforderlich sein. Bei einer noch nicht eingelösten Signatur reicht eine gewöhnliche Freigabeaufhebung unter Umständen nicht aus, um die alte signierte Nonce ungültig zu machen. Die richtige Reaktion hängt von Contract und Implementierung ab.
Falls Token bereits abgeflossen sind, dokumentiere Transaktionshashes, Adressen und Zeitpunkte und ziehe gegebenenfalls fachkundige Hilfe hinzu. Versprich Dir keine automatische Rückbuchung: Blockchain-Transaktionen sind normalerweise nicht durch eine Bank rückgängig zu machen. Wer Dir gegen eine Vorauszahlung eine garantierte Wiederherstellung anbietet, kann selbst ein Betrüger sein. Überweise niemals Seed Phrase oder private Schlüssel an angebliche Supportmitarbeiter.
ERC-2612 ist nicht dasselbe wie Permit2
Der Name Permit führt häufig zu Verwechslungen. ERC-2612 ist eine Token-Erweiterung: Der jeweilige Token-Contract muss die entsprechende Funktion selbst unterstützen. Permit2 bezeichnet dagegen eine andere Architektur, bei der ein separater Contract Berechtigungen und signierte Vorgänge verwalten kann. Die Details und Sicherheitsannahmen sind nicht identisch. Eine Signatur mit dem Namen Permit2 darf deshalb nicht automatisch nach den ERC-2612-Regeln beurteilt werden.
Auch Account Abstraction, Smart Wallets und EIP-7702 verfolgen andere Ziele. Sie betreffen unter anderem die Gestaltung von Konten und die Ausführung von Transaktionen. ERC-2612 konzentriert sich dagegen auf signierte ERC-20-Allowances. Diese technischen Ansätze können innerhalb einer Anwendung kombiniert werden, sollten aber in der Risikoanalyse getrennt bleiben.
Technische Grenzen und Implementierungsrisiken
Nicht jeder ERC-20-Token bietet permit. Manche Token nutzen eigene Signaturformate oder abweichende Domain-Versionen. Andere unterstützen die Funktion, aber eine Anwendung integriert sie nicht. Deshalb lässt sich aus dem blossen Besitz eines ERC-20-Tokens nicht ableiten, dass eine gaslose Freigabe möglich ist. Auch die erfolgreiche Unterschrift garantiert nicht, dass eine spätere Transaktion akzeptiert wird: Deadline, Nonce, Chain-Kontext oder Contract-Zustand können sich ändern.
Ein weiteres Problem ist die Reihenfolge von Transaktionen. Die ERC-2612-Spezifikation weist ausdrücklich darauf hin, dass jeder die gültige Signatur einreichen kann. Wird sie vor einer geplanten Anwendungstransaktion eingelöst, kann deren eigener permit-Aufruf wegen der veränderten Nonce fehlschlagen. Eine robuste Anwendung sollte diesen Fall berücksichtigen und nicht annehmen, dass die Person, die die Signatur erhalten hat, sie als Einzige einreichen darf.
Kosten und ein transparentes Gebührenbeispiel
Angenommen, eine klassische Freigabe benötigt in einem rein hypothetischen Beispiel 50 000 Gas und der effektive Gaspreis beträgt 10 Gwei. Dann kostet diese Transaktion 50 000 × 10 × 10⁻⁹ ETH = 0,0005 ETH. Bei einem angenommenen ETH-Preis von 2 000 CHF entspräche das 1 CHF. Diese Zahlen sind Rechenannahmen, keine aktuellen Gebühren oder Kursangaben. Die tatsächlichen Kosten hängen vom Netzwerk, dem Contract, der Auslastung und der Transaktionsausführung ab.
Ein Permit kann eine separate Freigabetransaktion vermeiden, doch der spätere Contract-Aufruf benötigt ebenfalls Rechenarbeit und Gas. Wenn eine Anwendung einen Relayer bezahlt, können Kosten anders verteilt werden, aber nicht einfach verschwinden. Vergleiche daher stets die gesamten Ausführungskosten einschliesslich möglicher Dienstleistungsgebühren und des wirtschaftlichen Ergebnisses. Ein vermeintlich kostenloser Vorgang kann durch einen schlechten Wechselkurs deutlich teurer sein.
Praktische Prüfung mit einem Blockchain-Explorer
Nach einer ausgeführten Permit-Transaktion kannst Du im passenden Explorer die Tokenadresse, die Transaktion, die Approval-Events und die aktuelle Allowance untersuchen. Achte darauf, ob Du die richtige Blockchain gewählt hast. Bei einem Proxy-Contract kann die technische Implementierung zusätzliche Prüfung erfordern. Die Anzeige eines Explorers ist eine aufbereitete Interpretation von Blockchain-Daten und sollte bei hohen Beträgen nicht Deine einzige Informationsquelle sein.
Vor der Einlösung existiert die Signatur möglicherweise nur bei Dir und der empfangenden Anwendung. Ein Explorer kann dann nicht zuverlässig zeigen, welche unbenutzten Signaturen noch im Umlauf sind. Dieser Unterschied zwischen gespeichertem Blockchain-Zustand und ausserhalb der Blockchain existierenden Autorisierungen ist einer der wichtigsten Punkte beim Sicherheitsverständnis von Permit.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Gutscheincode: AUSWANDERNSCHWEIZ. Relai verkauft hier keine der im Fachartikel besprochenen Altcoins.
FAQ: Häufige Fragen zu ERC-2612
Ist eine Permit-Signatur eine Überweisung?
Nein. ERC-2612 setzt bei erfolgreicher Einlösung eine Token-Allowance. Erst ein zusätzlicher Vorgang wie transferFrom kann auf Grundlage dieser Berechtigung Token bewegen. Eine betrügerische Anwendung kann beide Schritte allerdings sehr schnell kombinieren. Beurteile die Signatur deshalb nicht als ungefährlich, nur weil sie selbst noch keine Token überträgt.
Kann ich Permit ohne ETH verwenden?
Die Signatur selbst benötigt keine Ethereum-Transaktion und damit kein ETH-Guthaben für Gas. Die spätere Einlösung benötigt jedoch eine On-Chain-Transaktion, deren Gebühren jemand bezahlt. Ob die Anwendung diese Kosten übernimmt, hängt vom konkreten Dienst ab und ist keine Eigenschaft, die der Standard zwingend vorgibt.
Läuft die Freigabe automatisch mit der Deadline ab?
Nein. Die Deadline beschränkt die Gültigkeit der noch nicht eingelösten Signatur. Wird sie vorher erfolgreich eingereicht, entsteht eine Allowance nach den Regeln des Token-Contracts. Diese Berechtigung muss nicht automatisch mit der ursprünglichen Deadline enden.
Ist ERC-2612 sicherer als approve?
Der Standard vereinfacht bestimmte Abläufe und verwendet Nonces sowie Domain-Trennung. Er ist aber nicht pauschal sicherer. Eine bösartige Signatur kann eine gefährliche Berechtigung auslösen, und manche Nutzer übersehen Off-Chain-Signaturen leichter als normale Transaktionen. Die Sicherheit hängt von Implementierung, Wallet-Anzeige und Deinem Verhalten ab.
Fazit: Komfort ist keine Sicherheitsgarantie
ERC-2612 ist eine nützliche technische Erweiterung für signierte Token-Freigaben. Sie kann einen zusätzlichen Blockchain-Schritt vermeiden und ermöglicht Anwendungen, Transaktionen flexibler zu gestalten. Gleichzeitig verlagert sie einen Teil der Sicherheitsentscheidung in den Signaturdialog. Wer owner, spender, value, nonce, deadline und die Domain nicht versteht, kann unbemerkt eine weitreichende Autorisierung abgeben. Nutze kleine, zweckgebundene Freigaben und prüfe die Herkunft jeder Anfrage. Dieser Artikel dient der technischen und finanziellen Aufklärung und ist keine individuelle Anlageberatung. Kryptowährungen können stark schwanken und vollständig an Wert verlieren.
Kommentare