Ein Projekt wechselt auf einen neuen Token-Vertrag, kündigt ein Tauschfenster an, und das Fenster schließt. Monate später öffnest du ein altes Wallet, und der Bestand des alten Tokens liegt immer noch darin. Ob er noch getauscht werden kann, ist nicht eine Frage mit einer Antwort. In einer Migration laufen drei verschiedene Dinge ab, jedes wird an einer anderen Stelle durchgesetzt, und nur eines davon wird von Code durchgesetzt.
Was eine Token-Migration tatsächlich bewegt
Eine Migration bewegt deine Token nirgendwohin. Der alte Vertrag läuft weiter unter seiner eigenen Adresse, und dein Bestand bleibt in seinem Register, solange die Chain läuft. Was eine Migration anbietet, ist ein Tausch: Du gibst alte Einheiten an einen Tauschvertrag oder an eine Plattform, und sie schreibt dir den gleichwertigen Anspruch in einem neuen Register gut.
Dieser Tausch läuft über die gewöhnliche Token-Mechanik. Im ERC-20-Standard erlaubt `approve` einem Ausgebenden, bis zu einem festgelegten Betrag von deinem Konto abzuheben, und `transferFrom` bewegt Token von einer Adresse zur anderen; der Standard beschreibt das Paar als Abhebe-Ablauf, der Verträgen erlaubt, Token in deinem Namen zu bewegen. Ein Tauschvertrag ist einer dieser Ausgebenden, und die Chain gibt ihm keinen Sonderstatus.
Daraus folgen zwei Dinge. Dein alter Bestand verfällt nicht von selbst, und die Frist ist nie eine Eigenschaft der Token, die du hältst. Die Frist gehört dem, der auf der anderen Seite des Tauschs steht und bereit ist zu zahlen. Die Frage lautet also nicht, ob deine Token abgelaufen sind. Sie lautet, was mit der Gegenpartei passiert ist.
Drei Dinge können ablaufen, und sie sind nicht dasselbe
In einer üblichen Migrationsankündigung leistet das Wort Frist zu viel Arbeit. Zerlegt man es, stehen dort mehrere getrennte Uhren, jede an anderer Stelle durchgesetzt.
Die erste ist das angekündigte Datum selbst, eine Zeile in einem Blogbeitrag oder ein Banner in einer App. Auf der Chain liest das niemand. Die zweite ist eine Prüfung, die in den Tauschvertrag geschrieben wurde und die Ausführung verweigert, sobald der aktuelle Block-Zeitstempel einen im Code festgelegten Wert überschreitet. Die dritte ist die Reserve neuer Token, aus der der Vertrag auszahlt und die derjenige, der sie eingezahlt hat, abziehen kann, sobald das Projekt die Migration für beendet hält.
| Was abgelaufen ist | Wo es durchgesetzt wird | Was eine Wiedereröffnung bräuchte |
|---|---|---|
| Das angekündigte Datum | Nirgendwo auf der Chain | Nichts, der Vertrag hat es nie geprüft |
| Eine Zeitstempel-Prüfung im Tauschvertrag | Der Vertragscode | Einen Upgrade-Pfad, falls einer eingebaut wurde |
| Die Reserve neuer Token | Ein Bestand auf der Chain | Dass jemand den Vertrag erneut auffüllt |
| Eine Migrationsstelle bei einer Plattform | Die interne Richtlinie dieser Plattform | Eine Entscheidung dieser Plattform |
Alles Weitere zeigt, wie du herausfindest, in welcher Zeile du stehst.
Lies den Vertrag, bevor du ihn für geschlossen hältst
Die ersten beiden Zeilen kannst du selbst klären, kostenlos. Öffne den Tauschvertrag in einem Blockchain-Explorer und lies seinen verifizierten Quellcode. Enthält die Tauschfunktion keinen Vergleich mit einem Block-Zeitstempel, dann steht im Code keine Frist, und das angekündigte Datum war immer nur eine Mitteilung. In dem Fall läuft ein ein Jahr später gesendeter Tausch genau so wie einer am ersten Tag.
Gibt es eine Zeitstempel-Prüfung, ist das ein anderer Befund, und ein harter. Vertragscode tut, was in ihn geschrieben wurde, und eine Bedingung, die nach einem festgelegten Zeitpunkt zurücksetzt, wird das weiter tun. Kein Support-Ticket ändert daran etwas, denn es gibt niemanden zu überzeugen: die Ablehnung ist eine Zeile Code, die wie vorgesehen ausgeführt wird.
Die einzige Einschränkung ist die Aktualisierbarkeit. Sitzt der Tausch hinter einem Proxy, dessen Logik ersetzt werden kann, lässt sich die Frist grundsätzlich von dem aufheben, der diese Befugnis hält. Das ist eine Entscheidung des Projekts und kein Recht, das du hältst, aber es ist der Unterschied zwischen einer geschlossenen und einer verschweißten Tür, und den Vertrag zu lesen ist die Art, beides auseinanderzuhalten.
Wenn der Vertrag offen ist, die Reserve aber leer
Ein Vertrag ohne Frist kann trotzdem nicht aus einem leeren Konto zahlen. Die neuen Token müssen aus einer Reserve kommen, die an der Tauschadresse liegt, und wenn das Projekt eine Funktion geschrieben hat, die den Rest nach Fensterende ausräumt, kann es diese Reserve leeren. Nach dem Ausräumen nimmt die Tauschfunktion deine alten Token vielleicht weiter an und scheitert trotzdem, weil hinter dem Zahlungsbein nichts mehr steht.
Ein Rechenbeispiel. Ein Projekt konsolidiert im Verhältnis von einer neuen Einheit je zehn alter Einheiten, und ein Wallet hält 25.000 alte Einheiten, der Anspruch beträgt also 2.500 neue. Angenommen, 96% des alten Angebots kamen im Fenster durch; die übrigen 4% sind genau der Teil, auf den Nachzügler Anspruch erheben, und ob der Vertrag diese Ansprüche noch bedienen kann, ist schlicht der Bestand neuer Token an der Tauschadresse. Dieser Bestand ist öffentlich. Prüfe ihn, bevor du irgendetwas sendest.
Das ist der Fall, der Optimismus bestraft. Alte Token in einen Vertrag zu senden, der dich nicht auszahlen kann, lässt dich nicht dort zurück, wo du warst: die alten Einheiten sind an einer Adresse, die nie dafür geschrieben wurde, sie wieder herauszugeben, und Neues hältst du nicht. Lies zuerst die Reserve, und wenn sie leer ist, sende nicht.
Migrationen, die eine Plattform für dich erledigt hat
Manche Migrationen haben dein Wallet nie berührt. Hieltest du den alten Token während des Tauschs auf einer zentralisierten Plattform, hat die Plattform ihren eigenen gebündelten Bestand umgestellt und deinen Kontoeintrag neu geschrieben, sodass die Migration in deinem Konto als Tickerwechsel auftauchte und sonst nichts.
Dieser Weg hat seine eigene Uhr, und sie ist eine Richtlinie, keine Regel der Chain. Eine Plattform kündigt ein Umtauschfenster an, schreibt Bestände gut, die darin eintreffen, und hört irgendwann auf. Die Form ist vom Token-Delisting bekannt: eine Mitteilung, ein Fenster, dann geschlossener Zugang, wobei die spätere Rettung davon abhängt, ob dieses Haus noch einen manuellen Prozess für Nachzügler betreibt.
Hier stehen also zwei Fragen und nicht eine, und sie haben verschiedene Antworten. Ob die Plattform eine späte Einzahlung alter Token noch gutschreibt, ist eine Support-Frage. Ob der Tauschvertrag auf der Chain noch zahlt, ist eine Code-Frage. Beantworte sie getrennt, denn ein Nein aus der einen sagt nichts über die andere.
Was bleibt, wenn der Weg auf der Chain endgültig zu ist
Angenommen, der Code ist zu, die Reserve ausgeräumt, und keine Stelle bearbeitet einen späten Anspruch. Der alte Token hat nicht aufgehört zu existieren. Er ist ein Bestand in einem Vertrag, der weiterläuft, er lässt sich weiterhin übertragen und damit auch an jeden verkaufen, der kaufen will, zu dem Preis, den der Markt für ein aufgegebenes Register hergibt.
Suche keinen Umweg, indem du die alten Einheiten irgendwohin sendest, das hoffnungsvoll aussieht. Sie an den neuen Token-Vertrag oder an den alten Vertrag selbst zu senden, ist derselbe Fehlertyp wie Krypto an die falsche Adresse zu senden: ein Vertrag hat keinen privaten Schlüssel, und wenn niemand eine Funktion geschrieben hat, die verirrte Token wieder herausbewegt, kann es niemand. Der ERC-223-Standard wurde genau um dieses Versagen herum geschrieben und hält fest, dass Token, die mit einer einfachen Überweisung an einen Vertrag gehen, als Bestand ankommen, von dem der Vertrag nie erfährt.
Die ehrliche Zusammenfassung dieses Falls lautet: die Größe des Verlusts steht bereits fest, und jede weitere Transaktion kann sie nur erhöhen. Die Position zu halten kostet nichts. Eine Rettung zu raten kann den Rest kosten.
Die Migrationsfrist ist ein Köder für Betrüger
Ein ablaufendes Fenster erzeugt Zeitdruck, einen Zustrom verunsicherter Halter und einen legitimen Grund für ein Projekt, Leute um das Verbinden einer Wallet zu bitten. Angreifer müssen davon nichts erfinden. Sie brauchen nur eine täuschend ähnliche Seite. Das ist die Form von Identitätsbetrug, und deshalb ist ein Suchergebnis der falsche Weg zu einem Migrationsportal.
Der Mechanismus, auf den ein gefälschtes Portal zielt, ist derselbe, den ein echter Tausch nutzt. Eine echte Migration verlangt eine Erlaubnis, damit der Vertrag deine alten Token einziehen kann, und Token-Genehmigungen, die einem Angreifer erteilt werden, tun genau das, was sie sagen: sie lassen diese Adresse den genehmigten Bestand nehmen. Erteile eine begrenzte statt einer unbegrenzten Erlaubnis, gleiche die Vertragsadresse mit der eigenen veröffentlichten Ankündigung des Projekts ab und erreiche die Seite über dein eigenes Lesezeichen.
Eine Regel schneidet durch die ganze Kategorie. Jede Tatsache, die du bei einer späten Migration brauchst, ist in einem öffentlichen Explorer kostenlos lesbar: der Vertragsquellcode, die Zeitstempel-Prüfung, der Reservebestand. Wer eine Gebühr dafür verlangt, eine geschlossene Migration wieder zu öffnen, oder dafür eine Wiederherstellungsphrase erbittet, verkauft dir den zweiten Verlust und nicht die Behebung des ersten.
Fazit
Alt-Token laufen nicht ab. Gegenparteien tun es. Ein angekündigtes Datum bindet auf der Chain niemanden; eine Zeitstempel-Prüfung im Tauschvertrag bindet alle, das Projekt eingeschlossen; und eine ausgeräumte Reserve schließt die Tür genauso fest und lässt die Klinke daran. Diese drei Fälle sehen auf einem Wallet-Bildschirm gleich aus und sind darunter völlig verschieden.
Die Reihenfolge der Arbeit steht fest. Lies den Tauschvertrag in einem Explorer, suche die Zeitstempel-Prüfung, lies dann den Reservebestand an dieser Adresse, und frage die Plattform gesondert, falls eine beteiligt war. Kommt all das als geschlossen zurück, gehört der alte Bestand weiter dir und bleibt übertragbar, und kein Zeitdruck sollte dich dazu bringen, ihn dorthin zu senden, von wo nichts zurückkommt. 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
- Warum eine Token-Migration eine Wallet-Genehmigung verlangt
- Token-Migration abgeschlossen, aber neue Token nicht im Wallet
- Den Treasury-Runway eines Token-Projekts berechnen
- Coin-Margined vs USDT-Margined Futures: Welchen Kontrakt handeln
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-223: Token with transaction handling model, Abschnitt Motivation (Status: Final) eips.ethereum.org
