Ökosystem
Wallet

Die unbequeme Wahrheit über Krypto: 16 große Blockchains können Nutzervermögen einfrieren – ist die Dezentralisierung in Gefahr?

Die unbequeme Wahrheit über Krypto: 16 große Blockchains können Nutzervermögen einfrieren – ist die Dezentralisierung in Gefahr?

Ein neuer Bericht des Lazarus Security Lab von Bybit legt nahe, dass viele große Blockchains nicht so vertrauenslos sind, wie sie scheinen. In einer Branche, die auf Dezentralisierung aufgebaut ist, wirkt das verdächtig.

Die Forscher von Bybit untersuchten die Codebasen von 166 Blockchains mithilfe KI-gestützter Analysen und manueller Reviews. Sie stellten fest, dass 16 Netzwerke bereits eingebaute Funktionen zum Einfrieren von Geldern besitzen und weitere 19 diese mit nur geringfügigen Protokollanpassungen aktivieren könnten.

Diese Mechanismen sind zwar als Schutzmaßnahme gegen Hacks und illegale Transfers gedacht, haben aber eine alte Frage neu entfacht: Wie dezentral sind die Systeme, die die Kryptoindustrie tragen, tatsächlich?

Ausgangspunkt der Untersuchung war ein prominenter Vorfall: Anfang dieses Jahres fror die Sui Foundation nach dem Cetus‑DEX‑Hack gestohlene Vermögenswerte im Wert von über 160 Millionen US‑Dollar ein – ein rasches Eingreifen, das heftige Debatten auslöste.

Wenn eine Foundation das Wallet eines Hackers zum Schutz der Nutzer sperren kann, was hindert sie daran, auch andere zu blockieren?

Der Bericht erscheint kurz nach Bybits eigener Sicherheitskrise.

Vor nur wenigen Monaten erlitt die Börse einen massiven Hack in Höhe von 1,5 Milliarden US‑Dollar – einer der größten in der Kryptogeschichte. In diesem Fall griffen zentralisierte Akteure ein: Partner wie Circle und Tether froren rund 42,9 Millionen US‑Dollar an gestohlenen Stablecoins ein, und andere Protokolle halfen bei der Rückgewinnung weiterer Gelder.

Die Möglichkeit, im Notfall auf Pause zu drücken, hat offensichtlich Vorteile. Gleichzeitig macht sie aber ein Paradox deutlich: Je mehr Kryptonetzwerke sich auf solche „Kill‑Switches“ verlassen, um Bedrohungen einzudämmen, desto stärker ähneln sie den traditionellen, zentralisierten Systemen, die sie eigentlich ersetzen wollten.

Ethereum developers set december launch date for major fusaka network upgrade / Shutterstock

Krypto‑Vermögen einfrieren: Hack‑Abwehr vs. Dezentralisierungsrisiko

Auf einer Blockchain bedeutet das „Einfrieren“ eines Kontos, dass die Bewegung der darin gehaltenen Gelder gestoppt wird – sie werden faktisch unbeweglich gemacht.

In der Praxis geschieht dies typischerweise durch Blockproduzenten (Validatoren) oder Änderungen an den Protokollregeln, die verhindern, dass eine blockierte Adresse Transaktionen ausführen kann. Solche Notfallbefugnisse haben sich als Reaktion auf die grassierenden Hacks und Betrugsfälle im DeFi‑Bereich herausgebildet.

Die Logik dahinter ist einfach: Wenn Diebe Millionen in Krypto stehlen, stoppt man sie on‑chain, bevor sie die Mittel waschen können.

So setzte die Foundation nach dem 160‑Millionen‑US‑Dollar‑Exploit bei Sui auf Protokollebene zügig eine Deny‑List ein, um die Wallets des Hackers einzufrieren.

Ebenso kodierten die Entwickler der BNB Chain eine Blacklist fest in den Code, um die Bewegung von 570 Millionen US‑Dollar zu stoppen, die 2022 aus einer Cross‑Chain‑Bridge abgezogen worden waren. Schon 2019 führte VeChain ein ähnliches Blacklist‑System ein, nachdem 6,6 Millionen US‑Dollar in Token aus dem Wallet der Foundation gestohlen worden waren.

Diese Eingriffe haben sich in der Praxis als wirksam bei der Eindämmung von Verlusten erwiesen.

„Niemand will sehen, wie Hunderte Millionen einfach verschwinden“, wie ein Branchenanalyst anmerkte.

Durch das Einfrieren gestohlener Vermögenswerte verschaffen sich Projekte Zeit, um zu ermitteln, Gelder zurückzuholen oder mit Angreifern zu verhandeln. Im Fall von Sui sanktionierte eine Community‑Abstimmung letztlich die Rückführung der eingefrorenen Cetus‑Hack‑Mittel und stellte den Opfern einen Teil des Werts wieder her.

Aus rein sicherheitstechnischer Sicht ist die Fähigkeit, Transaktionen zu pausieren, ein mächtiges Instrument im Notfall‑Werkzeugkasten von Blockchain‑Betreibern.

Doch dieselbe Macht, die einen Raubzug stoppen kann, kann auch das Kernethos der Dezentralisierung untergraben. Unveränderliche, zensurresistente Transaktionen sollen ein grundlegendes Merkmal öffentlicher Blockchains sein – „Code ist Gesetz“. Die Vorstellung, dass eine zentrale Gruppe Transaktionen nachträglich stoppen oder rückgängig machen kann, steht diesem Prinzip entgegen.

Kritiker argumentieren, dass die Neutralität eines Netzwerks infrage steht, sobald irgendeine Autorität Vermögenswerte auf einem Ledger einseitig einfrieren kann.

Nach Sui’s Notfalleinfrierung sahen einige in der Community darin einen „Verrat an den dezentralen Idealen“ und wiesen darauf hin, dass ein scheinbar erlaubnisfreies Netzwerk einen sehr erlaubnispflichtigen Kontrollpunkt offenbart habe. Das wirft unangenehme Fragen auf: Wer genau besitzt die Befugnis, den Kill‑Switch in einer „dezentralen“ Chain umzulegen? Unter welchen Umständen? Und könnten solche Befugnisse in Zukunft missbraucht oder ausgeweitet werden?

Der neue Bybit‑Bericht beleuchtet diesen wachsenden Zielkonflikt zwischen Sicherheit und Souveränität. Die zentrale Erkenntnis: Diese Freeze‑Funktionen sind keine seltenen Ausnahmen – sie sind weiter verbreitet (und stillschweigend implementiert), als den meisten Nutzern bewusst ist. Von 166 analysierten Blockchains hatten 16 (knapp 10 %) native Freeze‑Mechanismen im Code. Entscheidend ist, dass diese 16 viele der größten Netzwerke der Welt umfassen, die zusammen über 80 % des gesamten in DeFi gebundenen Werts stellen. Anders ausgedrückt: Der Großteil der heutigen Kryptoaktivität läuft über Systeme, die unter bestimmten Bedingungen von jemandem angehalten, gefiltert oder eingefroren werden können. Diese Realität steht im Widerspruch zur populären Vorstellung, Blockchains seien der Kontrolle durch Dritte entzogen.

Aus Governance‑Perspektive sind die Zentralisierungsrisiken offensichtlich.

Die Forscher des Lazarus Labs stellten fest, dass fast 70 % der dokumentierten Freeze‑Ereignisse auf der Validator‑ oder Konsensschicht stattfanden – also auf einer tiefen Protokollebene, die für Alltagsnutzer nicht unmittelbar sichtbar ist. In vielen Fällen wurden diese „Notfallkontrollen“ von einer kleinen Gruppe von Insidern ausgeübt: den Kernentwicklern eines Projekts, einem Foundation‑Rat oder einer Gruppe führender Validatoren. Solche Instanzen sind in ihren Entscheidungsprozessen nicht immer transparent. Anders als der offene Blockchain‑Code laufen diese menschlichen Governance‑Abläufe häufig hinter verschlossenen Türen oder sehr kurzfristig ab.

Dieser Mangel an Sichtbarkeit schürt die Sorge, dass Vertrauen in angeblich vertrauenslose Systeme zurückkehrt. Wie ein Beobachter formulierte: Dezentralisierung endet oft dort, wo der Zugang der Validatoren beginnt.

Gradient network raises $10M to launch decentralized AI on Solana blockchain infrastructure, Shutterstock

Wie die Freeze‑Mechanismen funktionieren

Der Bybit‑Bericht identifiziert drei Hauptkategorien von On‑Chain‑Funktionen zum Einfrieren.

Hartkodierte Blacklists

Freeze‑Logik, die direkt in den Quellcode der Blockchain geschrieben ist. Bestimmte Adressen können auf Protokollebene per Code‑Update blockiert werden. Diese Methode – eingesetzt von BNB Chain, VeChain und anderen – erfordert die Veröffentlichung neuer Software (oder eines Hard Forks), um gesperrte Adressen hinzuzufügen oder zu entfernen. Die Blacklist ist im Code öffentlich sichtbar, aber nur Protokollentwickler oder autorisierte Parteien können sie über ein Update verändern.

Einfrieren über Konfigurationsdateien

Ein eher im Hintergrund stattfindender Ansatz, bei dem Validatoren oder Node‑Betreiber eine private Blacklist über Konfigurationsdateien (z. B. YAML, TOML) laden, die die Software während der Blockproduktion prüft.

Dieses „konfigurationsbasierte“ Einfrieren erfordert keine Änderung der öffentlichen Codebasis; stattdessen einigen sich Netzbetreiber stillschweigend darauf, eine Einstellungsdatei mit den zu blockierenden Adressen zu aktualisieren und ihre Nodes anschließend neu zu starten. Aptos, Sui und Linea sind Beispiele für Layer‑1‑Chains mit dieser Fähigkeit, die im Wesentlichen durch Off‑Chain‑Konsens der Validatoren gesteuert wird. Da diese Blacklists in Node‑Konfigurationen liegen, sind sie für die Öffentlichkeit in der Regel nicht sichtbar, was zusätzliche Transparenzprobleme mit sich bringt.

On‑Chain‑Contract‑Freezes

Ein System‑Smart‑Contract, der per On‑Chain‑Befehlen sofort Konten auf eine Blacklist setzen oder auftauen kann. Er fungiert als administrativer Vertrag mit Autorität über die Transaktionsverarbeitung.

Die Heco (Huobi Eco) Chain ist ein bemerkenswertes Beispiel – sie implementiert einen Vertrag, den Validatoren konsultieren, um festzustellen, ob eine Adresse von Transaktionen ausgeschlossen ist. Dieses Modell kann dynamischer sein (kein Node‑Neustart nötig, um die Liste zu aktualisieren), doch letztlich steuert ein Admin‑Key oder eine privilegierte Governance die Einträge in diesem Vertrag.

Praktische Implementierungen

Letztlich verleiht jeder dieser Ansätze einer kleinen Gruppe die Befugnis, Transaktionen im Netzwerk zu stoppen – eine Rolle, die traditionell Banken oder Aufsichtsbehörden im alten Finanzsystem vorbehalten war.

Bemerkenswert ist, wie stillschweigend diese Kontrollen in die Architekturen verschiedener Blockchains integriert wurden. In vielen Projekten gab es kaum öffentliche Ankündigungen oder klare Dokumentation, die Nutzer darüber informiert hätten, dass ein solcher „Pause‑Knopf“ existiert.

Häufig ist die Funktionalität in Code‑Repos oder Konfigurationsanleitungen versteckt und wird weder in Whitepapers noch in Onboarding‑Dokumentationen hervorgehoben.

Das bedeutet, dass Nutzer und selbst viele Entwickler von einem Freeze‑Mechanismus einer Chain erst erfahren, wenn er in einer Krise aktiviert wird.

Laut Bericht setzen 10 der 16 Blockchains mit Freeze‑Fähigkeiten auf die Methode über Konfigurationsdateien und geben damit Validatoren die Möglichkeit, private Blacklists durch das Aktualisieren von Node‑Einstellungen zu erzwingen. Aptos, Sui, EOS und mehrere andere fallen in diese Kategorie.

Da sich die Blacklist‑Einträge in lokalen Konfigurationen befinden, wirkt das Netzwerk für Außenstehende normal – nichts im öffentlichen Ledger markiert die eingefrorenen Adressen explizit. Nur die Insider, die den Freeze koordinieren (und eventuell Block‑Explorer, die später das Ausbleiben von Transaktionen dieser Adressen vermerken), machen sichtbar, dass ein Eingriff stattgefunden hat.

Weitere fünf der 16 Chains verfügen über hartkodierte Freeze‑Funktionen in ihrem Quellcode.

Die Analysten von Bybit nannten die BNB Chain von Binance, VeChain, Chiliz, „VIC“ (ein kleineres Netzwerk, das im Bericht identifiziert wird) und XinFins XDC Network als Beispiele. In diesen Systemen haben die Entwickler Blacklist‑Logik direkt in die Konsensregeln eingebaut – ein deutlich zentralisierter Sicherheitsmechanismus. So enthält die Codebasis der BNB Chain eine explizite Liste blockierter Adressen, die Validatoren nicht in Blöcke aufnehmen. Eine Änderung dieser Liste erfordert ein Code‑Update (in der Regel orchestriert vom Kernteam von Binance). VeChain fügte nach dem Hack 2019 ebenfalls ein hartkodiertes „Blacklist‑Modul“ hinzu, betont jedoch, dass es per Community‑Abstimmung aktiviert und nicht als dauerhafte Hintertür gedacht sei (dazu später mehr).

Die verbleibende eine der 16 Chains (Heco) nutzt ausschließlich den Ansatz über einen On‑Chain‑Smart‑Contract.

Auffällig ist, dass Tron – das als … auch im Bericht hervorgehoben – verfügt ebenfalls über ein integriertes, berechtigungsbasiertes Blacklist‑Modul, das in etwa wie ein vom Tron‑Foundation initiierten Vertragsaufruf funktioniert, um Konten einzufrieren (Trons Mechanismus wurde in der Bybit‑Zusammenfassung nicht im Detail beschrieben, aber aus früheren Fällen ist bekannt, dass Tron‑Nodes angewiesen werden können, Transaktionen von bestimmten Adressen abzulehnen).

In allen Fällen – ob der Freeze codebasiert, konfigurationsbasiert oder vertragsbasiert ist – ist das Ergebnis dasselbe: Bestimmte Adressen können, nach Ermessen derjenigen, die diese Funktion kontrollieren, an Transaktionen gehindert werden.

Still und leise hat sich eine Art Vorlage für Freeze‑Kontrollen über verschiedene Blockchain‑Ökosysteme hinweg ausgebreitet.

Durch das Durchforsten von GitHub‑Repos fand das Bybit‑Team wiederkehrende Muster – Hooks im Transaktionsverarbeitungscode, Verweise auf „Blacklist“-Variablen oder Prüfungen gegen bestimmte Kontolisten. Diese fanden sich in unterschiedlichen Projekten und Programmiersprachen (zum Beispiel EVM‑basierte Chains wie BNB und Chiliz vs. Rust‑basierte Chains wie Sui und Aptos), was darauf hindeutet, dass Entwickler unabhängig voneinander zu der Idee gelangt sind, dass eine Blockchain eine Art Notbremse haben sollte. Was als ad‑hoc‑Reaktion auf Krisen begann, scheint sich zu einer standardmäßigen Design‑Überlegung zu entwickeln. Und wichtig ist dabei, dass diese Kontrollen die Macht oft in den Händen derjenigen bündeln, die den Code pflegen oder die wichtigsten Validator‑Nodes betreiben. Wie der Bericht trocken anmerkt, endet Dezentralisierung „oft dort, wo der Zugang zu Validatoren beginnt“.

Image: Shutterstock.com

16 große Blockchains mit Freeze‑Funktionen

Bybits Forschung identifizierte sechzehn öffentliche Blockchains, die derzeit über eine native Funktionalität verfügen, um Konten oder Transaktionen einzufrieren. Nachfolgend die Liste dieser Netzwerke und der bekannte Mechanismus, mit dem sie Gelder sperren können:

  • Ethereum (ETH) – Kann über Governance‑Eingriffe einen Notstopp („emergency pause“) durchführen (z. B. durch ein Netzwerk‑Upgrade oder EIP‑Hooks ähnlich dem vorgeschlagenen EIP‑3074). Während Ethereum keine einfache, fest eingebaute „Blacklist“-Funktion hat, könnten Entwickler in Ausnahmesituationen einen speziellen Fork durchsetzen oder Vertragslogik einsetzen, um einen Freeze zu erreichen, wie der DAO‑Rollback 2016 gezeigt hat.
  • BNB Chain (BNB) – Nutzt einen validatorgetriebenen Konsens über Blacklists. Die börsengestützte Chain von Binance verfügt über hartkodierte Freeze‑Funktionen; ihre Validatoren, koordiniert durch das Kernteam von Binance, können sich weigern, Transaktionen von Adressen auf einer internen Blacklist zu verarbeiten.
  • Polygon (POL) – Verwendet dynamisches Adress‑Filtering in Transaktionspools. Die Nodes von Polygon können (über Forks oder Updates) so konfiguriert werden, dass sie Transaktionen mit bestimmten Adressen herausfiltern und so faktisch verhindern, dass blackgelistete Konten in neue Blöcke aufgenommen werden.
  • Solana (SOL) – Unterstützt Laufzeit‑Konfigurationsupdates für Blacklisting. Das Design von Solana ermöglicht es dem Kernteam oder einer Aufsichtsinstanz, netzwerkweite Konfigurationsänderungen schnell einzuspielen. Theoretisch könnte dies genutzt werden, um auf Ebene der Validator‑Software eine Blacklist zu implementieren oder bestimmte Konten zu stoppen.
  • Avalanche (AVAX) – Bietet Governance‑gesteuerte Transaktionsstopps. Avalanche kann seine On‑Chain‑Governance (per Validator‑Abstimmung) nutzen, um Notstopps oder adressspezifische Beschränkungen auf seiner C‑Chain und in Subnetzen umzusetzen, sofern eine Supermehrheit der Validatoren zustimmt.
  • Tron (TRX) – Eingebautes Blacklist‑Modul im Protokoll. Das von der Tron Foundation beaufsichtigte Tron‑Netzwerk verfügt über Funktionen, die es Behörden ermöglichen, Konten einzufrieren (etwa zur Erfüllung von Rechtsdurchsetzungsanforderungen oder zum Schutz vor Hacks, wie in früheren Vorfällen mit TRON‑basierten Assets zu sehen war).
  • Cosmos (ATOM‑Ökosystem) – IBC‑Modul‑Pause und Adressverbote. Cosmos und seine SDK‑basierten Blockchains haben bislang keine globalen Freezes eingesetzt, aber das Inter‑Blockchain‑Communication‑System (IBC) und Modul‑Konten könnten genutzt werden, um Transfers zu stoppen oder Adressen über mehrere Zonen hinweg zu blacklisten, sofern ein koordinierter Upgrade erfolgt.
  • Polkadot (DOT) – Parachain‑spezifische Freezes über die Relay Chain. Die Governance von Polkadot kann Laufzeit‑Upgrades für Parachains durchführen. In einem Notfall könnte die Relay Chain einen Freeze oder eine Rückabwicklung für eine problematische Parachain oder Adresse durchsetzen, vorbehaltlich der On‑Chain‑Abstimmung von Polkadot.
  • Cardano (ADA) – Hard Forks mit Adress‑Ausschlüssen. Cardano verfügt nicht über einen einfachen Freeze‑Opcode, aber durch seine Hard‑Fork‑Combinator‑Upgrades könnte die Community Regeln einführen, die bestimmte UTXOs oder Adressen ausschließen (zum Beispiel indem Outputs, die von einem blackgelisteten Schlüssel kontrolliert werden, in einer neuen Epoche nicht mehr anerkannt werden).
  • Tezos (XTZ) – Governance‑Abstimmungen, die Freezes ermöglichen. Das sich selbst ändernde Ledger von Tezos könnte durch eine Protokoll‑Änderung einen Freeze‑Mechanismus aufnehmen. Würden die Stakeholder in einem Upgrade (für den Notfallgebrauch) für eine Blacklist‑ oder Pausen‑Funktion stimmen, würde diese Teil des Tezos‑Protokolls.
  • Near Protocol (NEAR) – Transaktionsfilter auf Shard‑Ebene. Das geshardete Design von NEAR könnte es den koordinierenden Nodes erlauben, Transaktionen zu bestimmten Adressen in einem Shard zu filtern oder abzulehnen – eine Fähigkeit, die über die Protokoll‑Governance in Extremsituationen eingeführt werden könnte.
  • Algorand (ALGO) – Atomare Transfers mit Revocation‑Keys. Das Standard‑Asset‑Framework (ASA) von Algorand enthält eine Opt‑in‑Funktion für Asset‑Freeze und Clawback durch den Emittenten. Während ALGO selbst nicht eingefroren werden kann, verfügen viele Algorand‑Tokens über Freeze‑Kontrollen. Algorand unterstützt außerdem erzwungene Transfer‑Transaktionen (falls autorisiert), die einen Freeze nachahmen, indem sie Gelder von einer blackgelisteten Adresse wegbewegen.
  • Hedera Hashgraph (HBAR) – Administrative Token‑Freeze‑Kontrollen. Hedera, das von einem Unternehmensrat („council“) regiert wird, bietet eingebaute Admin‑Funktionen für Tokens. Zugelassene Administratoren können Token‑Übertragungen einfrieren oder Guthaben sogar vollständig löschen. Das permissioned Modell des Netzwerks bedeutet, dass der Rat bei Bedarf wahrscheinlich auch Konten auf Ledger‑Ebene stoppen könnte.
  • Stellar (XLM) – Clawback‑ und Freeze‑Klauseln bei der Asset‑Emmission. Stellar ermöglicht es Asset‑Emittenten (Tokens), eine „Clawback“-Funktion zu aktivieren, mit der sie Tokens unter bestimmten Bedingungen in Nutzer‑Wallets einfrieren oder zurückfordern können. Dies wurde von regulierten Stablecoin‑Emittenten auf Stellar genutzt und läuft auf einen teilweisen Freeze‑Mechanismus im Ökosystem hinaus.
  • Ripple XRP Ledger (XRP) – Escrow‑ und Line‑Freeze‑Funktionalität. Das XRP‑Ledger erlaubt kein Einfrieren der nativen XRP‑Währung, aber Emittenten von IOU‑Tokens (wie Stablecoins oder Wertpapiere auf dem Ledger) können Assets global oder bestimmte Trust Lines einfrieren. Ripples Netzwerk unterstützt außerdem das Sperren von XRP in Escrow‑Verträgen (zeitverriegelte Holds), was mit einer Einschränkung der Beweglichkeit von Geldern verwandt ist.
  • VeChain (VET) – Autoritätsbasierte Transaktionskontrollen. Das Authority‑Masternode‑System von VeChain ermöglichte 2019 nach einem Hack die Einführung einer Blacklist. Die Foundation aktivierte mit Zustimmung der Community Konsens‑Prüfungen, die Validatoren veranlassten, Transaktionen von den Adressen des Hackers abzulehnen – was diese Gelder faktisch einfrohr.

Es ist wichtig zu beachten, dass nicht alle Projekte mit der Charakterisierung ihrer Freeze‑Fähigkeiten einverstanden sind.

So hat etwa das VeChain‑Team nach Veröffentlichung des Bybit‑Berichts öffentlich zurückgewiesen, dass sein Protokoll im eigentlichen Sinne einen dauerhaft hartkodierten Freeze habe.

Die VeChain Foundation erklärte, dass in dem Vorfall von 2019 die Community dafür stimmte, einen einmaligen Patch – eine Änderung der Konsensregeln – einzuspielen, der die Adressen des Hackers auf Validator‑Ebene blockierte.

„Die Software von VeChainThor beinhaltet Konsens‑Prüfungen, die – sobald sie durch Community‑Governance aktiviert wurden – die Assets unbeweglich machten“, schrieb das Team und betonte, dass die Maßnahme governance‑genehmigt und keine ständig aktive Funktion sei. Mit anderen Worten: VeChain argumentiert, es gebe im Normalbetrieb keinen geheimen Kill‑Switch; man habe den Code lediglich über das vorgesehene Verfahren geändert, um die gestohlenen Gelder einzufrieren. Diese Reaktion unterstreicht, wie sensibel das Thema ist – keine Blockchain möchte als zentral gesteuert wahrgenommen werden, selbst wenn sie in Notfällen entsprechend handelt.

Nächste Kandidaten: 19 Netzwerke nur wenige Klicks von Freeze‑Macht entfernt

Vielleicht noch erschreckender als die 16 Blockchains mit Freeze‑Funktionen ist die Warnung des Berichts, dass 19 weitere Netzwerke mit minimalem Aufwand ähnliche Kontrollen übernehmen könnten. In vielen Fällen ist das Code‑Gerüst für Blacklists oder Transaktionspausen bereits vorhanden oder leicht hinzuzufügen. Es könnte nur wenige Codezeilen oder das Umlegen eines Konfigurations‑Flags brauchen, um die Funktion zu aktivieren.

Wie weit könnte sich das verbreiten? Potenziell sehr weit – wenn Entwickler entscheiden, dass sich der Trade‑off lohnt.

Bybits Team nannte mehrere konkrete Projekte in dieser Kategorie „könnte leicht Freezes einführen“.

Sie stellten fest, dass beliebte Chains wie Arbitrum, Cosmos, Axelar, Babylon, Celestia und Kava zu den Netzwerken gehören, die das Einfrieren von Geldern mit relativ geringen Protokolländerungen ermöglichen könnten. Diese Netzwerke werben derzeit nicht mit einer Freeze‑Funktion, doch ihre Architekturen sind so beschaffen, dass die Einführung einer solchen nicht schwierig wäre.

Viele Cosmos‑basierte Chains nutzen beispielsweise ein Modul‑Account‑System (etwa für Governance‑ oder Gebührenkonten).

Wie die Forscher feststellten, könnten diese Modul‑Konten so angepasst werden, dass sie ausgehende Transaktionen von bestimmten Adressen verweigern. Bislang hat keine Blockchain im Cosmos‑Ökosystem dies genutzt, um einen Nutzer zu blacklisten – dies würde einen Governance‑gestützten Hard Fork mit einer kleinen Codeänderung in der Transaktionslogik erfordern. Doch die Tatsache, dass es mit einem unkomplizierten Update machbar ist, bedeutet, dass der Bauplan bereits existiert und nur auf eine Entscheidung wartet.

In der Praxis würde das Aktivieren einer Freeze‑Funktion auf diesen zusätzlichen Chains wahrscheinlich einem vertrauten Muster folgen: ein größerer Hack oderregulatorischer Druck Entwickler dazu veranlassen könnte zu sagen: „Wir brauchen dieses Tool.“ Tatsächlich fügte das Aptos-Netzwerk (eine weitere Move-Chain) nach Sui’s 162-Millionen-Dollar-Hack und -Freeze in den darauffolgenden Wochen stillschweigend eine Blacklisting-Funktion in seinen Code ein. Sie erkannten, was sich abzeichnete: Ohne einen Freeze-Mechanismus hätten sie kaum Möglichkeiten, wenn ein ähnlicher Exploit ihr Ökosystem träfe.

Das zeigt, wie der Präzedenzfall eines Projekts andere beeinflussen kann. Sollten nur ein paar weitere prominente Vorfälle auftreten, ist es leicht vorstellbar, dass eine Kaskade von Chains rasch latente Freeze-Schalter implementiert – „nur für den Fall“.

Die Verbreitung ähnlicher Code-Muster deutet auf einen gewissen Branchenkonsens in dieser Frage hin. „Es ist keine Anomalie – es wird zu einer Branchenvorlage“, heißt es im Bericht über On-Chain-Freeze-Logik. Viele neuere Blockchains scheinen Lehren (im Guten wie im Schlechten) aus früheren Hacks auf älteren Netzwerken gezogen zu haben.

Sie könnten Hooks in ihr Design einbauen, die optionale zentralisierte Aktionen ermöglichen, auch wenn sie diese nicht bewerben.

In einigen Fällen wurden diese Hooks von Bybits KI-Scanning-Tool entdeckt: Das Team nutzte ein KI-Modell (Claude 4.1 von Anthropic), um Hunderte von Repositories nach Schlüsselwörtern und Codestrukturen im Zusammenhang mit Blacklisting und Transaktionsfilterung zu durchsuchen.

Diese KI-Hilfe markierte Dutzende potenzieller Fälle in verschiedenen Projekten.

Nicht alle waren echte Freeze-Funktionen – einige False Positives umfassten Nutzerfunktionen, die in Wirklichkeit keine Protokoll-Kontrollen darstellten. Aber die Tatsache, dass Automatisierung nötig war, um zu erfassen, wie weitverbreitet dies sein könnte, unterstreicht, wie unscharf die Grenzen von „dezentraler Kontrolle“ geworden sind.

Die Forscher mussten letztlich jeden Fall manuell verifizieren – ein Beleg dafür, dass selbst Experten Schwierigkeiten haben können zu erkennen, wo eine Blockchain versteckte Kontrollhebel eingebaut hat.

Bybits Bericht betont, dass die Existenz von Freeze-Funktionen in immer mehr Netzwerken kein hypothetisches Szenario ist. Sie ist bereits de facto Norm, wenn auch nicht immer de jure. Der Unterschied besteht lediglich darin, ob ein Projekt den Schalter bereits umgelegt hat. Viele könnten dies per Hard Fork oder sogar über eine Runtime-Konfigurationsänderung tun, was bedeutet, dass das Ethos absoluter Unveränderlichkeit in der Praxis kompromittiert ist. Wir bewegen uns auf eine Landschaft zu, in der die Mehrheit der Chains irgendeine Form von „Stoppknopf“ besitzt – entweder aktiv oder in Bereitschaft. Das erhöht die Anforderungen an Transparenz: Wenn diese Schalter allgegenwärtig sind, wollen Nutzer und Investoren genau wissen, wer sie betätigen kann und wie.

What Is Intent-Centric Blockchain Architecture?

Pragmatische Sicherheit oder versteckte Zentralisierung?

Die Debatte über diese Erkenntnisse läuft im Kern auf ein klassisches Dilemma hinaus: Überwiegen die Vorteile eines Notfalleingriffs die Kosten für die Dezentralisierung?

Befürworter von Freeze-Funktionen argumentieren, sie seien eine pragmatische Sicherheitsmaßnahme – eine notwendige Option in einer Welt, in der Hacks, Exploits und Diebstähle allgegenwärtig sind. Der Bericht dokumentiert tatsächlich Fälle, in denen Freezes beträchtliche Werte gerettet haben. Sui’s schnelles Eingreifen nach dem Cetus-DEX-Hack rettete möglicherweise 162 Millionen Dollar davor, für immer abgezogen zu werden.

Die Blacklist der BNB Chain während ihres Exploits 2022 half, einen Einbruch von 570 Millionen Dollar einzudämmen und weitere Ansteckung im Binance-Ökosystem zu verhindern. VeChains Freeze von 6,6 Millionen Dollar an gestohlenen Token im Jahr 2019 schützte die Treasury des Projekts und Community-Gelder vor unwiederbringlichen Verlusten. Jeder dieser Vorfälle hätte verheerend sein können; die Fähigkeit einzugreifen machte sie tödlichstenfalls schmerzhaft statt endgültig fatal.

„Ohne sie hätten Hacks wie Cetus oder der BNB-Bridge-Exploit die Investoren ausgelöscht“, wie der Bericht zur Verteidigung dieser Mechanismen anmerkt.

Doch jedes Mal, wenn eine Blockchain diese Art von Override ausübt, nagt sie am grundlegenden „trustless“ Ethos der Blockchain-Technologie. Zensurresistenz – die Garantie, dass niemand gültige Transaktionen verhindern kann – ist ein wesentlicher Grund, warum Menschen Vertrauen in dezentrale Netzwerke setzen. Wenn Nutzer das Gefühl bekommen, dass eine Foundation oder ein Komitee nach Belieben Gelder einfrieren kann, beginnt sich der psychologische (und rechtliche) Unterschied zu traditionellen Banken zu verwischen. Die Bybit-Forscher warnen, dass selbst gut gemeinte Freezes einen Präzedenzfall schaffen:

„Sobald eine Chain einmal Gelder einfriert, ist es schwer vorstellbar, dass sie es nicht noch einmal tun wird“, schreiben sie. Die Sorge ist, dass das, was als Ausnahmemaßnahme beginnt, sich zu einem routinemäßigen Kontrollinstrument entwickeln könnte.

Es gibt Hinweise darauf, dass sich diese Grenze bereits verschiebt.

Laut den Daten des Berichts fanden fast 70 % der dokumentierten Freeze-Ereignisse über Maßnahmen auf der Konsens-Ebene durch Validatoren oder Blockproduzenten statt. Das ist bedeutsam, weil es die tiefste Ebene des Systems ist – die Zensur war also direkt in die Blockproduktion eingebettet, nicht nur in einer oberflächlichen Anwendungsschicht. Durchschnittliche Nutzer würden nicht einmal merken, dass es passiert; die Chain verarbeitet schlicht keine Transaktionen mehr von bestimmten Adressen, ohne dass es eine Erklärung on-chain gibt.

In der Mehrzahl der Fälle wurden die Freeze-Entscheidungen von kleinen Governance-Räten, Foundation-Teams oder Core-Dev-Gruppen getroffen.

Dabei handelt es sich häufig um nicht gewählte Gremien oder, falls gewählt (wie manche Validator-Sets), doch eher insiderlastige Gruppen, die gegenüber Millionen globaler Nutzer nicht direkt rechenschaftspflichtig sind. Solche Freezes können daher dem Handeln einer Zentralbank oder eines Regierungsdekrets ähneln, umgesetzt ohne die Checks and Balances, die Dezentralisierung eigentlich gewährleisten sollte.

Die Intransparenz rund um diese Notfallmaßnahmen ist ein wesentlicher Teil der Sorge.

Im Fall von Sui wurde die Koordination zum Einfrieren von Geldern durch Absprachen hinter den Kulissen zwischen Validatoren organisiert, angeleitet von der Sui Foundation. Es gab keinen On-Chain-Vorschlag und keine vorherige Nutzerabstimmung; es war eine eilige Reaktion.

Ähnlich wird berichtet, dass Aptos’ neu hinzugefügte Freeze-Funktion über private Konfigurationsdateien der Validatoren verwaltet wird und „nur eine Handvoll Leute weiß“, wer die Blacklist pflegt oder wie diese Entscheidungen getroffen werden. Dieser verdeckte Ansatz mag in der Krise effizient sein, drängt aber die Community an den Rand und entbehrt der Transparenz.

Selbst auf der BNB Chain, die vergleichsweise offen mit ihrer hardcodierten Blacklist umgeht, liegt die Kontrolle „fest in den Händen des Entwicklerkerns von Binance“, wie die Analyse feststellt. Das heißt, die letztendliche Entscheidung darüber, wer auf BNB geblacklistet wird, liegt faktisch bei der Führung von Binance – eine Autoritätsstruktur, die eher einem Unternehmen als einem dezentralen Community-Projekt gleicht. Und im Fall von Huecos vertragsbasiertem Freeze kann ein Admin-Key in den Händen der Protokollbetreiber entscheiden, welche Adressen im Netzwerk leben oder sterben.

Für Kritiker bestätigen diese Realitäten lang gehegte Vermutungen, dass viele sogenannte dezentrale Blockchains nur dem Namen nach dezentralisiert sind. „Die Grenzen zwischen Foundation, Validator und Regulator verschwimmen rasant“, wie ein Kommentar feststellte. Wenn es hart auf hart kommt, können sich die meisten großen Netzwerke sehr wohl wie zentralisierte Intermediäre verhalten: Sie können Gelder einfrieren, Transaktionen rückgängig machen oder sonst wie Nutzeraktivitäten steuern – auf Arten, die Nutzern gar nicht bewusst sind.

Die Krypto-Community hat bereits analoge Debatten erlebt, etwa im Zusammenhang mit der Einhaltung von OFAC-Sanktionen, als Ethereum-Validatoren 2022 begannen, sanktionierte Adressen in Blöcken zu zensieren. Auch dies wurde als gefährlicher Präzedenzfall betrachtet, bei dem äußerer Druck zu de facto zentralisiertem Verhalten in einem dezentralen System führte.

Befürworter von Notfallbefugnissen halten dagegen, dass eine gewisse Eingriffsfähigkeit schlicht Teil des „Erwachsenwerdens“ von Krypto sei. Wenn Blockchain-Plattformen in den Mainstream vordringen und Milliardenwerte tragen, können die Realitäten von Hacks und Kriminalität nicht ignoriert werden.

Selbst strikte Dezentralisierungs-Befürworter würden womöglich einräumen, dass sie bei einem Diebstahl ihrer eigenen Gelder einen gut getimten Freeze begrüßen würden, um diese zurückzubekommen. Der Schlüssel liegt vielleicht darin, eine angemessene Governance und Transparenz rund um diese Fähigkeiten sicherzustellen.

David Zong, Bybits Sicherheitschef, der die Recherche leitete, formulierte es so: Blockchain sei zwar auf Dezentralisierung aufgebaut worden, „doch unsere Forschung zeigt, dass viele Netzwerke pragmatische Sicherheitsmechanismen entwickeln, um schnell auf Bedrohungen zu reagieren.“

Entscheidend sei, so sagt er, dass „Transparenz Vertrauen schafft“ – sprich: Wenn solche Mechanismen existieren, sollten sie offen offengelegt und einer Aufsicht unterstellt werden, nicht heimlich im Code versteckt sein.

Das schlimmste Ergebnis wären geheime Hintertüren oder Freeze-Buttons, von denen die Nutzer erst erfahren, wenn es zu spät ist.

Im Gegensatz dazu gilt: Wenn ein Projekt offen erklärt, dass es eine Notbremse vorbehält, und eine klare Richtlinie vorgibt, wie und wann diese genutzt wird (z. B. nur bei Hacks über einem Betrag X, mit Multisig-Genehmigung usw.), können Nutzer und Investoren den Trade-off selbst beurteilen.

VeChains zuvor erwähnte Reaktion ist dabei aufschlussreich. Sie bestritten nicht, Gelder eingefroren zu haben – sie verteidigten, wie es geschah, und stellten es als gemeinschaftlich gesteuerte Aktion statt als einseitigen Schritt dar. Das deutet auf einen möglichen Mittelweg hin: Jeder Freeze sollte durch irgendeine Form dezentralen Entscheidungsprozesses umgesetzt werden. Im Fall von VeChain, so heißt es, hätten Token-Inhaber die Blacklist genehmigt. Im Fall von Sui ratifizierte die Community im Nachhinein den Wiederherstellungsplan per Abstimmung. Auch wenn diese Governance-Schritte unvollkommen sein mögen (Kritiker werden anmerken, dass Foundation-Einfluss Abstimmungen oft lenken kann oder dass Notfallsituationen keine lange Debatte zulassen), versuchen sie zumindest, sich an dezentralen Prinzipien zu orientieren. Die Alternative – eine Handvoll Core-Devs, die die Entscheidungen trifft – rückt unangenehm nahe an die zentralisierten Systeme heran, vor denen Krypto ursprünglich fliehen wollte.

Fast ein Jahrzehnt nach Ethereums historischem „DAO-Fork“ im Jahr 2016 – wohl der ersten On-Chain-Fondsintervention – ringt die Branche noch immer mit derselben Kernfrage: Sollten Blockchains jemals in On-Chain-Aktivitäten eingreifen, selbst um ein Unrecht zu korrigieren?

Eine Einheitslösung wird es möglicherweise nie geben. Verschiedene Netzwerke verfolgen unterschiedliche Ansätze, von Bitcoins absolutistischer Unveränderlichkeit (selbst Diebstähle aus der Satoshi-Ära können nicht rückgängig gemacht werden) bis hin zu flexibleren, governance-starken Chains wie Tezos oder Polkadot, die explizit gemeinschaftsgetragene Änderungen zulassen. Klar ist jedoch, dass die Präsenz vondiese Freeze-Mechanismen verwischen die Dichotomie zwischen zentralisiert und dezentralisiert.

Viele Netzwerke nehmen eine Grauzone dazwischen ein – dezentralisiert im täglichen Betrieb, aber mit zentralisierten Override-Fähigkeiten in Extremszenarien. Ob man das als umsichtiges Risikomanagement oder als fatalen Kompromiss betrachtet, hängt wahrscheinlich von der eigenen Philosophie ab – und vielleicht davon, ob man schon einmal auf der Verliererseite eines Hacks stand.

Closing Thoughts

Der Bericht von Bybit hat den Vorhang vor einer unbequemen Wahrheit zurückgezogen: Die Fähigkeit, Gelder einzufrieren, ist inzwischen Teil der Blockchain-Landschaft, insbesondere bei den führenden Netzwerken.

Die Wahl, vor der die Branche steht, lautet nicht mehr einfach „Zentralisierung vs. Dezentralisierung“. Es geht um ehrliche Governance vs. versteckte Kontrolle.

Projekte, die offen mit ihren Befugnissen umgehen und diese demokratischen Kontrollen unterwerfen, können ihre Glaubwürdigkeit bewahren – sie sagen damit: Wir sind größtenteils dezentralisiert, außer in äußersten Notfällen, und genau so funktioniert das.

Wenn solche Befugnisse dagegen intransparent und unkontrolliert bleiben, ist es nur eine Frage der Zeit, bis sie Misstrauen säen oder missbraucht werden. Mit wachsender Regulierung könnten einige Jurisdiktionen sogar On-Chain-Freeze-Funktionen vorschreiben (die EU und Singapur haben bereits Ideen für „Notbremse“-Bestimmungen im Gesetz angedeutet). Auch institutionelle Investoren könnten Netzwerke bevorzugen, die Risiken kontrollieren können – selbst wenn das bedeutet, ein Stück Dezentralisierung aufzugeben.

Dies könnte zu einer Spaltung zwischen „konformen“ Chains, die eingreifen können, und „puristischen“ Chains, die das ablehnen, führen – und so die Identität des Krypto-Ökosystems grundlegend neu formen.

Am Ende stirbt die Dezentralisierung im Krypto-Bereich nicht – aber sie reift und sieht sich harten Realitätsprüfungen gegenüber.

Haftungsausschluss und Risikowarnung: Die in diesem Artikel bereitgestellten Informationen dienen nur Bildungs- und Informationszwecken und basieren auf der Meinung des Autors. Sie stellen keine Finanz-, Anlage-, Rechts- oder Steuerberatung dar. Kryptowährungsassets sind hochvolatil und unterliegen hohen Risiken, einschließlich des Risikos, Ihre gesamte oder einen erheblichen Teil Ihrer Investition zu verlieren. Der Handel oder das Halten von Krypto-Assets ist möglicherweise nicht für alle Anleger geeignet. Die in diesem Artikel geäußerten Ansichten sind ausschließlich die des Autors/der Autoren und repräsentieren nicht die offizielle Politik oder Position von Yellow, seinen Gründern oder seinen Führungskräften. Führen Sie immer Ihre eigenen gründlichen Recherchen (D.Y.O.R.) durch und konsultieren Sie einen lizenzierten Finanzprofi, bevor Sie eine Anlageentscheidung treffen.
Neueste Forschungsartikel
Alle Forschungsartikel anzeigen