Polygon Hard Fork würde 70 Mio. POL an Polymarket und Binance buchen

Ein Vorschlag im Polygon-Forum will rund 70,49 Mio. native POL aus fünf gesperrten Angreiferadressen per Hard Fork an Polymarket und Binance umbuchen. Ein Hard Fork ist eine Regeländerung, die jeder Node übernehmen muss. Für POL-Halter zählt vor allem: Laut Spezifikation bliebe das Gesamtangebot gleich. Auf der Agenda des Polygon Protocol Governance Call stand der Vorschlag am 5. November 2026.

Die Adressen stehen schon auf einer Sperrliste, die Antragsteller halten sie aber für zu schwach. Der Fork wäre der direkte Weg, die POL den Rückholadressen der beiden Firmen gutzuschreiben. Sein Preis ist eine Grundsatzfrage, die über diesen Fall hinausreicht: Wie weit darf eine Blockchain in Guthaben eingreifen?

Der Fork würde fünf Adressen auf null setzen und Polymarket und Binance gutschreiben

Den Plan beschreibt ein Polygon Improvement Proposal (PIP) im Polygon-Forum, Stand 8. November 2026: ein koordinierter Hard Fork des Polygon-PoS-Mainnets. An einem festen Block, dort Block F genannt, würden die nativen POL-Salden der gelisteten Angreiferadressen auf null gesetzt. Denselben Betrag bekämen Rückholadressen, die Polymarket und Binance benannt haben. Maßgeblich wäre der Saldo am Ende des Blocks davor.

Zusammen hielten die fünf Adressen am 29. Oktober 2026 rund 70,49 Mio. POL, gemessen als Mindeststände. Rund 23,86 Mio. lagen in vier Adressen aus dem Polymarket-Vorfall, rund 46,63 Mio. in einer Adresse aus dem Binance-Vorfall. Vor einer Aktivierung würden die Salden neu gelesen.

Allein die Binance-Adresse hielt mindestens 46.626.593,27 POL. Das ist ihr Saldo auf der Chain, die Schadensbilanz von Binance ist eine andere Größe. Den Vorfall aus Kundensicht ordnet Binance-Hack: Wann kommen Kunden wieder an ihr Geld? ein.

Umgebucht würden nur diese fünf Adressen, in der PIP als Class A geführt: Angreiferadressen, deren Guthaben der Fork verschieben soll. Weitere von Binance gemeldete Adressen, darunter das Hot Wallet 34, stehen als Class B nur auf der Sperrliste. Sie bleiben unberührt, ihre Sperren sollen nach Bestätigung durch Binance wieder fallen.

Weil jeder abgezogene POL bei einer Rückholadresse landet, bliebe das Gesamtangebot gleich. Bor-Engineering, das Team hinter Polygons Node-Software Bor, muss dieses Design noch bestätigen.

Die bestehende Sperrliste ist ein Filter, kein vollständiges Einfrieren

Die Sperrliste in Bor wirkt über die Block Producer, also die Rechner, die bei Polygon Blöcke bauen: Sie lassen Transaktionen der gelisteten Absender außen vor. Laut PIP liest jeder von ihnen die Liste nur beim Start, und Einträge bleiben stehen, bis jemand sie entfernt. Der Filter erfasst nur äußere Absender und bestimmte Autorisierungen (EIP-7702).

Dass der Angreifer an die POL will, schließen die Antragsteller aus zwei Beobachtungen. Am 30. Oktober 2026 sei eine ausstehende Transaktion mit rund 219.450 POL Gebühr aufgefallen (10,45 POL je Gas). Zudem habe der Angreifer Validatoren Bargeld dafür angeboten, eine Transaktion freizugeben.

Den Verhandlungsweg hat Polymarket laut PIP schon versucht. Über den Recovery-Safe von SEAL Safe Harbor, einem Rahmen für Rückgaben an Betroffene, bot es dem Angreifer eine Rückgabe an. Eine Antwort blieb aus, deshalb gilt eine verhandelte Rückgabe in der PIP als unzuverlässig.

Bei Polymarket führt die Spur der POL direkt in die gesperrten Adressen

Die Sicherheitsforscher von ohey.ca zeigen anhand von Archivkopien: Am 29. Oktober 2026 wurde das von Polymarket eingebundene Monitoring-Skript des Dienstleisters DebugBear durch einen Wallet-Drainer ersetzt, also Code, der Guthaben aus verbundenen Wallets abzieht. Hudson Rock fand in der abgerufenen Datei Code, der Guthaben und Positionen eingeloggter Nutzer an eine Empfängeradresse leiten soll. Genutzt wurde nach ohey.ca die fest eingetragene Fallback-Adresse.

Am selben Tag sammelte sich die Beute auf Polygon. Nach den On-Chain-Daten von ohey.ca gingen beim Empfängerkonto des Drainers ab 17:10 UTC insgesamt 28.636.284,45 POL ein, um 18:15 UTC lagen sie vollständig vor. Die POL stammen aus Swaps abgezogener Nutzerguthaben. Dazu kamen Positionen aus 33 Deposit-Wallets, die letzte traf um 18:02 UTC ein.

Zwischen 18:28 und 18:38 UTC leitete das Empfängerkonto alle POL an drei Wallets weiter. Gleicht man diese Adressen mit der PIP ab, sind es dieselben wie drei der vier gesperrten Polymarket-Adressen.

Wie viel davon in der Sperre liegt, zeigt eine einfache Rechnung. Beim Drainer gingen 28.636.284,45 POL ein, in den vier gesperrten Adressen lagen am 29. Oktober 2026 (Block 96.399.251) laut Tabelle 2.1 der PIP mindestens 23.862.736,07 POL. Zieht man den zweiten Wert vom ersten ab, bleiben rund 4,77 Mio. POL. So viel lag am Referenzblock außerhalb der gesperrten Polymarket-Adressen.

Die Höhe des Gesamtschadens bleibt offen. Bis zur Veröffentlichung von ohey.ca am 29. Oktober 2026 hatte Polymarket laut den Forschern keine Schadenszahl genannt. Hudson Rock bezeichnet Zahl der Betroffenen und Gesamtverluste als nicht unabhängig festgestellt.

Für Betroffene gibt es eine Zusage: Laut ohey.ca kündigte der X-Account Polymarket Traders am 29. Oktober 2026 an, Betroffene würden entschädigt. Bekannt ist sie bisher nur aus der Wiedergabe der Forscher. Wie es um die Zusagen an Binance-Kunden steht, zeigt Binance-Hack-Update: Was Binance Kunden zusagt und was offen bleibt.

Bevor POL fließen, müssen Polymarket und Binance nachweisen, dass sie ihre Rückholadressen kontrollieren, etwa per signierter Nachricht oder kleiner Testüberweisung, bestätigt durch Polygon Labs. Dazu kommt eine schriftliche Bestätigung, dass die Adressen ihnen gehören. Im Forumsthread steht dieser Nachweis mit Stand 8. November 2026 noch aus.

Wer seine Node nicht rechtzeitig aktualisiert, landet ab Block F auf einer anderen Chain

Technisch ist der Eingriff konsensbrechend: Alte und neue Node-Software würden ab Block F unterschiedliche Blöcke als gültig ansehen. Nodes ohne die neue Bor-Version folgen ab dort einer anderen Chain. Validatoren, RPC-Anbieter, Börsen und Node-Betreiber müssen deshalb vorher aktualisieren.

Polygon Validator Operations erwartet, dass rund 70 bis 80 Prozent des Stakes die neue Version kurz nach dem Release übernehmen. Ein Release-Datum soll erst feststehen, wenn die Stake-Abdeckung bestätigt ist.

Ab einer Zustimmung rechnen die Antragsteller mit rund zwei Wochen für Client-Entwicklung, einen Probelauf und das Deployment auf Amoy, dem Testnetz von Polygon. Eine Woche gilt in der PIP als knapp.

Wer Salden verfolgt, muss eine Besonderheit kennen. Die Umbuchung an Block F erscheint als reine Saldenänderung statt als Transaktion. Explorer, Indexer und Buchhaltungssoftware, die Salden aus Transaktionen ableiten, müssen sie gesondert behandeln.

Vorgesehen war der Vorschlag für den Polygon Protocol Governance Call am 5. November 2026. Laut einem X-Post der Polygon Foundation wurde er dort behandelt (PPGC 47). Ein Ergebnis ist nicht bekannt, Auskunft geben erst Protokoll oder Aufzeichnung des Calls.

Die PIP nennt den Fork eine Ausnahme, ein Kritiker warnt vor Folgen bei Behörden

Bleibt die Grundsatzfrage: Öffnet Polygon damit eine Tür für weitere Eingriffe in Guthaben? Die PIP nennt den Fork eine extreme Maßnahme, die nicht üblicherweise wiederholt werden soll. Künftige Anträge, die ihre Bedingungen verfehlen, sollen sich nicht auf diesen Fall stützen. Einen allgemeinen Einfrier- und Rückholmechanismus im Protokoll lehnt die PIP ab, weil er eine dauerhafte Macht über Nutzergelder wäre.

Gegen diese Selbstbegrenzung steht eine Warnung aus dem Forum. Der Teilnehmer S1W schreibt: Zeige Polygon, dass native POL-Salden umgebucht werden können, könnten Behörden das für künftige Einfrier- oder Herausgabeersuchen nutzen, etwa über Rechtshilfeverfahren oder Gerichtsbeschlüsse. Zugleich äußert S1W Verständnis für die Betroffenen. Es ist eine einzelne Stimme in einem Thread, der bis zum 8. November 2026 vier Beiträge zählt, darunter eine Zustimmung.

Einen Vorläufer gibt es auf Sui. Die Sui Foundation meldete, dass Validatoren mit 90,9 Prozent des Stakes in der ab 27. Mai 2025 laufenden On-Chain-Abstimmung für ein Protokoll-Upgrade stimmten; die Abstimmung endete vorzeitig. Das Upgrade überträgt die nach dem Cetus-Hack eingefrorenen Gelder ohne Signatur der Angreifer in ein treuhänderisch gehaltenes Multisig-Wallet. Sui setzte dafür auf Adress-Aliasing für zwei vorab festgelegte Transaktionen, Polygon würde Salden direkt ändern.

Für dich als POL-Halter läuft die Sache auf zwei Beobachtungsgrößen hinaus. Die erste ist das Protokoll oder die Aufzeichnung des PPGC 47. Die zweite ist eine Release-Ankündigung mit Aktivierungsblock, die erst nach bestätigter Stake-Abdeckung kommen soll.

Offen sind der Verbleib der rund 4,77 Mio. POL außerhalb der Sperre und der Weg, auf dem das DebugBear-Skript kompromittiert wurde. Für Geschädigte von Polymarket zählt vor allem die erste Frage, denn der Fork bucht nur um, was in den fünf gelisteten Adressen liegt.