Ein Projekt zieht auf einen neuen Contract um, du öffnest die Migrationsseite, und bevor sich ein einziger Token bewegt hat, verlangt deine Wallet eine Genehmigung für den alten. Die Abfrage sieht aus wie ein zusätzlicher Schritt, den jemand eingebaut hat. Ist sie nicht. In ERC-20 ist sie der einzige Weg, ein Guthaben an jemanden außer dich selbst zu übergeben, und sie richtig zu lesen trennt eine Migration von einer geleerten Wallet.
Was die Genehmigung tatsächlich gewährt
Eine Genehmigung ist ein Eintrag in ein Register, das im Contract des alten Tokens liegt. Sie hält eine einzige Zahl für ein Adresspaar fest: wie viel dieses Tokens ein benannter Spender aus deinem Konto bewegen darf. Das Signieren bewegt nichts, sendet nichts an das Projekt und verpflichtet dich zu keinem Tausch.
Im Standard ERC-20-Token wird dieses Register über zwei Funktionen erreicht. `approve` erlaubt einem Spender, wiederholt bis zu einem festgelegten Betrag von deinem Konto abzuheben, und `transferFrom` ist der Aufruf, der die Token tatsächlich von einer Adresse zur anderen bewegt. Die Spezifikation stellt das Paar als Abhebe-Ablauf dar, mit dem Contracts Token in deinem Namen übertragen können, und ein Migrations-Contract ist einer dieser Contracts, ohne jede Sonderstellung.
Wo der Eintrag liegt, wiegt schwerer, als es klingt. Die Erlaubnis steht im alten Token, nicht im Migrations-Contract, also überlebt sie die Migrationsseite, den Tausch selbst und das Projekt. Den Tab zu schließen löscht sie nicht.
Warum der Tausch-Contract fragen muss
Ein Tausch muss die alten Einheiten erst übernehmen, bevor er die neuen gutschreiben kann. Der Contract kann nicht von sich aus in dein Konto greifen, und über dein Guthaben hört der Token-Contract nur auf das Konto, das es hält.
Die scheinbare Alternative ist, die alten Token mit einer gewöhnlichen Überweisung selbst an den Contract zu schicken. Das bewegt die Token tatsächlich, und es scheitert ebenfalls: eine einfache Überweisung kommt als Guthaben ohne begleitenden Aufruf an, der Contract erfährt also nie von der Überweisung und hat nichts, wogegen er gutschreiben könnte. Der Standard ERC-223 wurde genau um dieses Versagen herum geschrieben. Das Ziehen per `transferFrom` gibt dem Contract einen einzigen Aufruf, in dem er die alten Einheiten annimmt und die neuen auszahlt, und dieser Aufruf braucht vorher eine Erlaubnis.
Zwei Transaktionen, und nur die zweite tauscht
Genehmigung und Tausch sind getrennte Transaktionen mit jeweils eigenem Gas. ERC-2612 beschreibt die Form direkt: wenn ein Nutzer mit einem Smart Contract interagieren muss, dann braucht er 2 Transaktionen, `approve` und den Contract-Aufruf, der intern `transferFrom` aufruft.
Weil sie getrennt sind, kann die erste gelingen und die zweite trotzdem scheitern. Ein geschlossenes Tauschfenster, eine geleerte Auszahlungsreserve, ein pausierter Contract: nichts davon sieht die Genehmigung, die nur eine Zahl schreibt und zurückkehrt. Eine bestätigte Genehmigung ist kein Beleg dafür, dass die Migration dahinter funktioniert.
Die umgekehrte Falle steht einen Schritt später. Ein Tausch nach einer erfolgreichen Simulation kann on chain trotzdem zurückgerollt werden, denn die Simulation beantwortet eine Frage über den Zustand in einem Moment, nicht über den Zustand, in dem deine Transaktion landet. Wenn der Tausch zurückrollt, bleibt die erteilte Erlaubnis unberührt und weiter gültig.
Migrationen, die keinen Grund zu fragen haben
Nicht jede Migration läuft über eine Erlaubnis. Die Form, die dir angekündigt wurde, sollte zu der Abfrage passen, die du bekommen hast.
| Wie die Migration läuft | Was du sendest | Gehört hier eine Genehmigung hin |
|---|---|---|
| Ein Tausch-Contract zieht deine alten Einheiten | Eine Genehmigung, dann den Tausch-Aufruf | Ja |
| Du überweist alte Token an eine veröffentlichte Adresse | Eine gewöhnliche Überweisung | Nein |
| Halter laut Snapshot werden gutgeschrieben | Nichts | Nein |
| Eine Plattform wandelt ihr eigenes gepooltes Guthaben um | Nichts | Nein |
Die Zeile, die dich stoppen sollte, ist die dritte. Eine als automatisch angekündigte Verteilung hat keinen Mechanismus, der deine Erlaubnis braucht, also verlangt eine Seite, die danach fragt, etwas, das die beschriebene Migration nicht benutzt. Diesen Widerspruch zu bemerken kostet nichts und hängt von niemandes Urteil über die Seite ab.
Die drei Felder in der Abfrage, die alles entscheiden
Jede Genehmigungsabfrage trägt dieselben drei Felder, wie deine Wallet sie auch nennt.
| Feld | Was es gewährt | Womit abgleichen |
|---|---|---|
| Token | In das Register welches Contracts der Eintrag geschrieben wird | Die alte Contract-Adresse aus der eigenen Ankündigung des Projekts |
| Spender | Welche Adresse von deinem Konto ziehen darf | Die Adresse des Migrations-Contracts aus derselben Ankündigung |
| Betrag | Die Obergrenze dessen, was diese Adresse nehmen kann | Die Tranche, die du jetzt tauschen willst |
Vergleiche Adressen vollständig. Eine täuschend ähnliche Adresse kann die ersten und letzten Zeichen mit der echten teilen, und der Unterschied sitzt in der Mitte.
Das Spender-Feld ist das, welches den Verlust trägt, und deshalb muss ein Wallet-Drainer nichts brechen. Er setzt seine eigene Adresse in dieses Feld und lässt dich eine Genehmigung signieren, die gültig und korrekt aufgebaut ist. Die Transaktion gelingt genau so, wie sie geschrieben wurde, und das Guthaben geht später, nach dem Zeitplan des Angreifers statt nach deinem.
Wenn eine Signatur statt einer Transaktion verlangt wird
Eine Erlaubnis kommt nicht immer als Transaktion. ERC-2612 erweitert den ERC-20-Standard um eine Funktion `permit`, die es Nutzern erlaubt, das allowance-Mapping mit einer signierten Nachricht statt über `msg.sender` zu ändern; ein gültiger Permit setzt die Erlaubnis für den genannten Spender auf den angegebenen Wert, erhöht eine Nonce und löst ein Genehmigungs-Event aus.
Die Folge: ein Bildschirm mit einer bloßen Nachricht zum Signieren, ohne Gas und ohne ausstehende Transaktion, kann genau das gewähren, was eine Genehmigungstransaktion gewährt. Er hinterlässt im Moment des Signierens außerdem nichts in deiner eigenen Transaktionshistorie, weil die signierte Nachricht von jemand anderem eingereicht wird.
Lies eine Signaturanfrage also nach denselben drei Feldern. Ein Permit nennt den Spender und den Wert, den er setzt, dazu eine Deadline, unter oder auf der die Spezifikation die aktuelle Blockzeit verlangt. Wenn eine Seite die Signatur als Login oder Bestätigung ausgibt, während die typisierten Daten einen Spender und einen Betrag nennen, sind die typisierten Daten das, was ausgeführt wird.
Exakter Betrag oder unbegrenzt, und die Erlaubnis, die bleibt
Ein Beispiel. Eine Wallet hält 10.000 alte Einheiten, und das Projekt hat einen Tausch geöffnet. 2.500 zu genehmigen, diese Tranche zu tauschen und das Angekommene gegen das angekündigte Verhältnis zu prüfen, macht die Migration zu etwas Beobachtetem statt Angenommenem. Die restlichen 7.500 brauchen danach eine zweite Genehmigung, also eine weitere Gaszahlung, und das ist der ganze Preis dieser Methode.
Eine unbegrenzte Genehmigung entfernt diese zweite Zahlung und ersetzt sie durch eine stehende Erlaubnis über diesen Token, solange der Eintrag besteht. Der Migrations-Contract behält das Recht, alle alten Einheiten zu ziehen, die später auf dein Konto gelangen, einschließlich eines Alt-Token-Bestands, den du Jahre später aus einer alten Wallet zurückholst.
Räume am Ende auf, was übrig ist. Eine Genehmigung über den exakten Betrag wird von dem Tausch verbraucht, für den sie erteilt wurde, alles Darüberliegende lässt einen lebenden Eintrag zurück, und eine Token-Genehmigung, die ihren Zweck überlebt, ist eine Erlaubnis, auf die niemand mehr schaut. Die Erlaubnis auf null zu setzen ist selbst eine Transaktion mit eigenem Gas, also tu es bewusst, sobald die Migration abgeschlossen ist.
Fazit
Eine Migration verlangt eine Genehmigung, weil ERC-20 ihr keinen anderen Weg lässt, deine alten Token zu nehmen. Die Genehmigung selbst ist eine Zahl im Contract des alten Tokens, die eine Adresse und eine Obergrenze nennt: sie bewegt nichts, beweist nichts über die Migration dahinter, und sie verfällt nicht, wenn die Seite geschlossen wird.
Damit schrumpft die ganze Arbeit auf drei Prüfungen. Braucht diese Form der Migration überhaupt eine Erlaubnis, ist der Spender die vom Projekt veröffentlichte Adresse, und ist der Betrag die Tranche, die du tauschen wolltest. Eine Signaturanfrage beantwortet dieselben drei, und eine erteilte Erlaubnis überlebt alles um sie herum, also räume sie weg, wenn der Tausch erledigt ist. Um die Grundlagen weiter zu lernen, folge weiteren Beiträgen der Bitbase Academy.
Weiterführende Artikel
Weitere Bitbase-Artikel zu diesem Thema:
- Eine Governance-Delegation widerrufen
- Den Treasury-Runway eines Token-Projekts berechnen
- ATR und die Messung der Volatilität
Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand September 2026; maßgeblich sind die aktuellen offiziellen Informationen.
Quellen
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, die Methoden approve und transferFrom (Status: Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-2612: Permit Extension for EIP-20 Signed Approvals, Abschnitte Abstract und Specification (Status: Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, Abschnitt Motivation (Status: Final) eips.ethereum.org
