Wenn ein Rollup den Betrieb einstellt: Die Abschaltung der Polygon zkEVM im Detail

3. Juli 2026

10 Minuten Lesezeit

Andrew Nalichaev working on blockchain technology research in a blue-lit workspace.
Zusammenfassen mit KI

Polygon zkEVM ist nun offiziell in die Auslaufphase eingetreten. Am 1. Juli 2026, Polygon Labs hat den Sequenzer der Polygon zkEVM Mainnet-Beta abgeschaltet, wobei die Guthaben der Wallets im Rahmen eines Antragsverfahrens auf Ethereum L1 übertragen wurden. Fairerweise muss man sagen, dass die Abschaltung reibungslos abgewickelt wurde: Die Nutzer hatten ein ganzes Jahr Zeit, sich darauf vorzubereiten, die Brücke blieb bis zum letzten Tag geöffnet, und Anträge können noch bis Ende 2027 gestellt werden.

Der Haken daran ist, dass Blockchains nicht nur Coins in Wallets verwahren. Wenn ein Netzwerk seinen Betrieb einstellt, ist ein Teil der Liquidität bereits mehrere Ebenen tief vergraben: in Pools, Tresoren, Kreditmärkten, Sicherheitenpositionen und anderen Verträgen, über die Polygon keine Kontrolle hat. Diese wieder zurück auf L1 zu verlagern, ist keine einfache Brückenaufgabe mehr. 

Deshalb haben wir unserem Experten Andrew Nalichaev die Fragen gestellt, die sich derzeit wahrscheinlich viele in der Branche stellen: Wer ist für die gebundene Liquidität verantwortlich, was passiert mit Stablecoins in einem sterbenden Netzwerk, und was sollten andere Rollups daraus lernen, bevor sie mit demselben Problem konfrontiert werden?

Blockchain-Experte und DeFi-Analyst

Andrew übersetzt dezentralisierte Konzepte in sichere, funktionale Finanztools. Er navigiert durch die unbeständige DeFi-Landschaft, um skalierbare Blockchain-Infrastrukturen aufzubauen, die einen realen Nutzen bieten und über die Schlagworte hinausgehen, um technischen Wert zu liefern.

-  Wenn wir Polygon zkEVM als Fallstudie für die Stilllegung eines L2-Netzwerks betrachten: Was wurde gut gehandhabt, und was hätte von Anfang an berücksichtigt werden müssen?

Das Beste, was Polygon hier getan hat, war, den Nutzern Zeit und einen klaren Ablauf zu geben. Die Einstellung von zkEVM wurde etwa ein Jahr im Voraus angekündigt, die Brücke blieb bis zum letzten Tag geöffnet, es gab einen Kontostand-Snapshot, und den Nutzern wurde eine Möglichkeit geboten, ihre Guthaben auf Ethereum L1 einzufordern. Was die Einstellung von Diensten angeht, ist das eine ziemlich saubere Vorgehensweise.

Der Teil, der von Anfang an einkalkuliert worden sein sollte, ist der DeFi-Ausstiegsplan. Das Verschieben von Wallet-Guthaben ist eine Sache, da diese Guthaben sich eindeutig den Vermögenswerten zuordnen lassen, die im Bridge-Treuhandkonto liegen. DeFi ist eine ganz andere Sache. LP-Token, Vault-Anteile, Sicherheitenpositionen und Forderungsansprüche benötigen alle ihre eigenen Notfallausstiegsmöglichkeiten auf Protokollebene. Ohne diese Vorkehrungen kann es, sobald der Sequenzer stoppt, sehr schwierig oder manchmal sogar unmöglich werden, auf die in Verträgen von Drittanbietern gebundene Liquidität zuzugreifen.

-  Wie realistisch ist es, ein L2-Netzwerk “sauber” abzuschalten, wenn darauf bereits DeFi-Protokolle, LP-Positionen, Tresore, Sicherheiten und Derivat-Token laufen?

Ein sauberes Herunterfahren ist möglich, allerdings nur bis zu einem gewissen Grad. Wenn es um einfache Wallet-Guthaben oder Vermögenswerte geht, die direkt mit dem Bridge-Treuhandkonto verknüpft sind, dann ja, dann lässt sich der Vorgang recht sauber gestalten. Sobald jedoch die Kombinierbarkeit von DeFi ins Spiel kommt, wird die Sache deutlich schwieriger.

Nehmen wir einen einfachen AMM-Pool als Beispiel. Theoretisch könnte man prüfen, wer die LP-Token hält, deren Anteil am Pool berechnen und die zugrunde liegenden Vermögenswerte entsprechend verteilen. Es muss sich dabei um den aktuellen Inhaber handeln, nicht um denjenigen, der die Einlage ursprünglich getätigt hat – andernfalls besteht die Gefahr, dass dieselbe Person doppelt bezahlt wird. Aber in der Praxis läuft DeFi selten so übersichtlich ab. LP-Token können in Tresore eingelagert, gestaked, als Sicherheit verwendet oder in ein weiteres Produkt eingebunden werden. Plötzlich hat man es nicht mehr mit einem einzigen Anspruch zu tun, sondern mit einer ganzen Kette von Ansprüchen, und es gibt keine universelle Methode, um über alle möglichen Verträge hinweg festzustellen, wer der “echte” Eigentümer ist.

Die ehrliche Antwort lautet also: Ein L2 kann nur dann ordnungsgemäß heruntergefahren werden, wenn die darauf aufbauenden Protokolle dieses Szenario von Anfang an einkalkuliert haben. Andernfalls mag das Herunterfahren auf Netzwerkebene zwar organisiert aussehen, aber auf der DeFi-Ebene kann es dennoch chaotisch zugehen.

-  Wie würden Sie das Risiko einer doppelten Ausgabe einschätzen, wenn man versucht, DeFi-Positionen nach einem Netzwerkausfall manuell aufzulösen? Handelt es sich dabei hauptsächlich um ein technisches, rechtliches oder wirtschaftliches Problem?

Es ist eine Mischung aus allen dreien, aber im Kern handelt es sich um ein wirtschaftliches Problem.

Das Bridge-Treuhandkonto auf L1 enthält nur die tatsächlichen Vermögenswerte, die in das System eingebracht wurden. DeFi baut dann zusätzliche Ebenen darauf auf: LP-Token, Vault-Anteile, Kreditpositionen, Schuld-Token und andere Forderungen. Auf einem Kreditmarkt kann es beispielsweise schnell dazu kommen, dass mehr Forderungen bestehen als Vermögenswerte im Treuhandkonto vorhanden sind – zumindest wenn man versucht, alle Beteiligten gleichzeitig vollständig zu entschädigen.

Hier kommt das Problem der doppelten Ausgabe ins Spiel. Man kann den Einleger, den Kreditnehmer und jeden Inhaber von Derivaten nicht aus demselben Pool an zugrunde liegenden Vermögenswerten bezahlen, wenn dieser Pool nicht groß genug ist, um all diese Ansprüche zu decken.

Es gibt auch eine zeitliche Falle. Manche Positionen haben zum Zeitpunkt des Einfrierens noch nicht einmal einen feststehenden Wert: Ein “Underwater”-Kredit muss liquidiert werden, Zinsen müssen anfallen, ein Orakel muss aktualisiert werden. Stoppt man die Blockchain mitten im Ablauf, wird der „faire“ Anteil dieser Positionen undefiniert – und nicht nur schwer zu berechnen.

Technisch gesehen kann man versuchen, zu klären, wem was gehört. Rechtlich gesehen muss man möglicherweise entscheiden, wessen Anspruch Vorrang hat. Wirtschaftlich gesehen ist die Grenze jedoch ganz einfach: Man kann nicht mehr Vermögenswerte verteilen, als tatsächlich vorhanden sind.

DeFi image
-  Sollten L2-Teams Protokolle vorsehen, die eine Ausstiegsmöglichkeit bieten, bevor sie diese Teams die Bereitstellung von Liquidität im Netzwerk gestatten?

Ja, vor allem, wenn ein Protokoll das Geld der Nutzer verwahrt. Man kann nicht Einzahlungen annehmen, Liquidität aufbauen und dann erst fragen: “Wie kriegen wir alle wieder raus?”, wenn das Netzwerk bereits abgeschaltet wird.

Die L2 selbst kann nur bei dem übersichtlichen, einfachen Teil helfen: Salden, die mit dem übereinstimmen, was sich im Bridge-Treuhandkonto befindet. Realistisch gesehen kann sie nicht jedes DeFi-Protokoll durchforsten und die Buchhaltung entwirren. An diesem Punkt müsste das L2-Team entscheiden, wem was gehört, wie Positionen bewertet werden sollten und wer zuerst bezahlt wird. Das ist eine große Verantwortung, und es ist eigentlich nicht ihre Aufgabe.

Ja, DeFi-Protokolle benötigen also eigene Notfall-Auszahlungswege, Abwicklungslogik oder Abschaltpläne, bevor Nutzer beginnen, ernsthaft Liquidität in sie zu investieren.

-  Inwiefern verändert eine Abschaltung des Sequenzers das Vertrauensmodell für L2s? Sollten Nutzer nun nicht nur das Brückenrisiko, sondern auch das Abschaltrisiko bewerten?

An dieser Stelle beginnt die ganze Idee des “einfach überbrücken” zu scheitern. Es funktioniert, wenn sich Ihre Mittel einfach in einer Wallet befinden. Es funktioniert nicht ganz so reibungslos, wenn sie in einem Kreditmarkt, einer LP-Position, einem Tresor oder einem Vertrag gebunden sind, bei dem noch eine weitere Transaktion erforderlich ist, um sich daraus zu befreien.

Wenn der Sequenzer stoppt, nimmt die Kette keine Befehle mehr entgegen. Möglicherweise haben Sie zwar noch irgendwo einen gültigen Anspruch, aber keinen funktionierenden Pfad mehr, um diesen geltend zu machen. Das ist das Unangenehme daran: Das Asset ist vielleicht noch da, aber der Weg dorthin kann verschwinden.

Nutzer müssen über die Sicherheit der Bridge hinausdenken. Bei kleineren L2-Netzwerken, insbesondere solchen mit geringer Liquidität oder experimentellen Ökosystemen, sollte die Frage auch lauten: Was passiert, wenn dieses Netzwerk eingestellt wird, und kann ich tatsächlich noch rechtzeitig aussteigen, bevor es soweit ist?

-  Was passiert mit den Stablecoin-Reserven in einem im Niedergang begriffenen Netzwerk, insbesondere wenn man über eine Bridge übertragene USDC.e mit der nativen Emission über ein CCTP-ähnliches Modell vergleicht?

Bei überbrückten Stablecoins wie USDC.e befindet sich der echte USDC in einem Treuhandkonto auf Ethereum L1. Wenn sich Ihr USDC.e einfach in Ihrer Wallet befindet, kann er migriert oder beansprucht werden. Befindet er sich hingegen in einem Vertrag, mit dem niemand mehr interagieren kann, ist der zugrunde liegende USDC zwar weiterhin vorhanden, der Nutzer hat jedoch keine praktische Möglichkeit, darauf zuzugreifen. Der Emittent erhält dadurch kein “zusätzliches” Geld. Die Deckung ist nach wie vor vorhanden, doch der Wert ist im Grunde genommen gebunden.

Native Stablecoins funktionieren anders. In einem CCTP-ähnlichen Setup wird der Token direkt auf der L2 geprägt, und die Fiat-Reserve verbleibt beim Emittenten. Um sauber auszusteigen, muss man den Token vor der Abschaltung auf der L2 verbrennen und ihn an anderer Stelle neu prägen. Wenn der Token in einem inaktiven Vertrag feststeckt, kann man ihn nicht mehr on-chain verbrennen. Der Emittent bleibt also auf den realen Reserven für Token sitzen, die zwar noch existieren, sich aber in einem Netzwerk befinden, das nicht mehr funktioniert.

An diesem Punkt muss der Emittent entscheiden, wie es weitergehen soll: die Reserven behalten, Off-Chain-Forderungen mit Nachweis akzeptieren oder diese Token schließlich als aufgegeben behandeln.

Lassen Sie nicht zu, dass aus einem Infrastrukturrisiko ein Produktrisiko wird

Innowise unterstützt die Entwicklung einer Web3-Infrastruktur mit weniger blinden Flecken

-  Welche Lehren sollten Teams, die neue Rollup-Ökosysteme aufbauen, aus der Abschaltung von Polygon zkEVM ziehen?

Polygon zkEVM macht deutlich, dass jeder Rollup zwei Roadmaps benötigt: eine für das Wachstum und eine für die sichere Abwicklung. Die Einbringung von Liquidität ist nur die halbe Miete. Die Teams benötigen außerdem einen klaren Plan, wie sie diese Liquidität wieder abziehen können, falls das Netzwerk jemals eingestellt wird.

Das bedeutet, die Nutzer frühzeitig zu warnen, die Brücke so lange wie möglich offen zu halten, den Nutzern ein reibungsloses Verfahren zur Abwicklung ihrer Wallet-Guthaben zu bieten und lange vor dem Abschalttermin mit den DeFi-Protokollen in Kontakt zu treten. Es bedeutet außerdem, genau darzulegen, was mit den über die Brücke übertragenen Vermögenswerten, den nativen Vermögenswerten und den Stablecoins geschieht.

Vor allem sollten Teams aufhören, TVL als etwas zu betrachten, das man einfach zusammenpacken und später verlagern kann. Sobald der Sequenzer verstummt, lautet die eigentliche Frage: Wie viel Liquidität muss noch abfließen, damit eine Transaktion zustande kommt?

Hinter all dem verbirgt sich auch eine Lehre für die Entwurfsphase. Wenn die Stilllegung eines Systems so mühsam ist, lohnt es sich, sich vor der Einführung ehrlich zu fragen, ob die Arbeitslast wirklich eine eigene Kette benötigte. Viele Anwendungsfälle, bei denen es um “Manipulationssicherheit” geht, lassen sich besser durch eine überprüfbare Datenbank oder ein Transparenzprotokoll mit einem externen Anker abdecken. Dort gibt es keinen Sequenzer, den man ausschalten könnte.

-  Was sollte das Mindest-Shutdown-Szenario für jedes L2 vor dem Mainnet-Start beinhalten: Kommunikation, Bridge-Anträge, DeFi-Koordination, Stablecoin-Richtlinien oder etwas anderes?

Ein ordnungsgemäßes L2-Abwicklungsszenario sollte den gesamten Prozess von der ersten Warnung bis zum Ablauf der endgültigen Anspruchsfrist abbilden. Die Teams müssen frühzeitig festlegen, wann die Nutzer benachrichtigt werden, wie lange die Brücke offen bleibt, wann die abschließende Bestandsaufnahme erfolgt, wie L1-Ansprüche abgewickelt werden und was mit nicht beanspruchten Geldern geschieht.

DeFi verdient einen eigenen Plan. Die Protokolle sollten darlegen, ob Nutzer im Notfall Auszahlungen vornehmen können, wie Positionen aufgelöst werden können und was mit LP-Token, Vault-Anteilen, Sicherheiten und Schulden geschieht, wenn das Netzwerk keine Transaktionen mehr verarbeitet.

Stablecoins benötigen dieselbe Klarheit. Über Brücken eingebundene Vermögenswerte und nativ ausgegebene Vermögenswerte verhalten sich bei einem Netzwerkausfall sehr unterschiedlich, daher sollten Nutzer genau wissen, welche Regeln für welchen Token gelten.

-  Was ist in solchen Situationen in der Regel am schwierigsten: das Netzwerk technisch stillzulegen, die Verantwortung rechtlich zuzuweisen oder die eingefrorene Liquidität wirtschaftlich aufzulösen?

Das Abschalten des Netzwerks ist wahrscheinlich der unkomplizierteste Teil des gesamten Prozesses. Die wirklichen Probleme beginnen erst, wenn man sich ansieht, wer noch Geld darin gebunden hat, wo sich dieses Geld befindet und wer das Recht hat, darüber zu entscheiden.

In rechtlicher Hinsicht verschwimmen die Verantwortlichkeiten sehr schnell. Das L2-Team betreibt die Infrastruktur, ist jedoch nicht Eigentümer aller darauf aufbauenden DeFi-Protokolle. Aus wirtschaftlicher Sicht wird die Sache noch komplizierter, da DeFi mehrere Ebenen von Ansprüchen auf dieselbe zugrunde liegende Liquidität schaffen kann. Ist diese Liquidität begrenzt, gebunden oder bereits in unterschiedlicher Form zugesagt, können manche Ansprüche schlichtweg nicht vollständig erfüllt werden.

Die größte Herausforderung besteht also darin, einen fairen Weg zu finden, mit eingefrorener Liquidität umzugehen, ohne denselben Basiswert zweimal zu bezahlen, neue Verbindlichkeiten zu schaffen oder das Infrastrukturteam zu zwingen, bei jedem Protokoll im Ökosystem als Richter zu fungieren.

-  Wie wird sich dieser Fall Ihrer Meinung nach auf das Vertrauen in kleinere L2-Lösungen und zk-Rollup-Ökosysteme mit geringer TVL auswirken?

Dieser Fall wird dazu führen, dass sich kleinere L2-Netzwerke weit weniger “von Haus aus sicher” anfühlen. Ein niedriger TVL-Wert sorgt ohnehin schon für Stirnrunzeln. Nun müssen sich die Nutzer eine weitere Frage stellen: Wenn dieses Netzwerk den Betrieb einstellt, kann ich dann tatsächlich aussteigen?

Bei zk-Rollups wird es nicht mehr nur um Technik, Gebühren und Geschwindigkeit gehen. Die Abhängigkeit vom Sequenzer, Ansprüche aus Bridges, DeFi-Fluchtwege und der Umgang mit Stablecoins stehen nun ebenfalls auf der Checkliste. Ein Rollup muss heute beweisen, dass Nutzer genauso reibungslos wieder aussteigen können, wie sie eingestiegen sind.

Mehr zu diesem Thema

    Kontakt aufnehmen

    Anruf vereinbaren oder füllen Sie das Formular aus. Wir kontaktieren Sie, sobald wir Ihre Anfrage bearbeitet haben.

    Sprachnachricht senden
    Datei beifügen
    Datei hochladen

    Sie können 1 Datei mit bis zu 2 MB anhängen. Gültige Dateiformate: pdf, jpg, jpeg, png.

    Mit dem Klicken auf Senden erklären Sie sich damit einverstanden, dass Innowise Ihre personenbezogenen Daten gemäß unserer Datenschutzerklärung verarbeitet, um Ihnen relevante Informationen bereitzustellen. Mit Angabe Ihrer Telefonnummer stimmen Sie zu, dass wir Sie per Sprachanruf, SMS oder Messaging-Apps kontaktieren. Es können Gebühren für Anrufe, Nachrichten und Datenübertragung anfallen.

    Sie können uns auch kontaktieren
    bis hin zu contact@innowise.com
    Wie geht es weiter?
    1

    Sobald wir Ihre Anfrage erhalten und geprüft haben, melden wir uns bei Ihnen, klären erste Fragen und unterzeichnen bei Bedarf ein NDA, um die Vertraulichkeit zu gewährleisten.

    2

    Nach genauer Prüfung Ihrer Anforderungen, Bedürfnisse und Erwartungen wird unser Team einen Projektvorschlag mit Angaben zu Arbeitsumfang, Teamgröße, Zeitaufwand und Kosten erstellen.

    3

    Wir vereinbaren einen Termin, um das Angebot gemeinsam zu besprechen und alle Details festzulegen.

    4

    Abschließend unterzeichnen wir den Vertrag und starten umgehend mit der Umsetzung Ihres Projekts.

    arrow