Tether hat seit 2023 über $3,3 Milliarden in USDT eingefroren. Das ist die Schlagzeile.
Was die meisten übersehen: Jede einzelne dieser Einfrierungen hatte eine Verzögerung. Eine Lücke zwischen dem Moment, in dem ein Einfrierungsantrag (Freeze Proposal) on-chain eingereicht wurde, und dem Moment, in dem er tatsächlich wirksam wurde. Wir haben 8.293 ausgeführte Einfrierungsanträge auf Ethereum und Tron analysiert. Die mediane Verzögerung (Median Delay)? Über 5 Stunden auf Ethereum. Etwa 2,6 Stunden auf Tron.
Das ist kein Bug. So funktionieren Multisig-Wallets (Multisignature Wallets). Aber es ist ein Zeitfenster — und es ist breit genug, damit jeder, der die Blockchain beobachtet, seine Gelder verschieben kann, bevor die Einfrierung greift.
Wir nennen dies die „Einfrierungslücke” (Freeze Gap).
Wie Tether-Einfrierungen funktionieren (und warum sie nie sofort erfolgen)
Tether friert Adressen nicht mit einer einzigen Transaktion ein. Sowohl auf Ethereum als auch auf Tron wird die Blacklist-Funktion (Sperrfunktion) des USDT-Vertrags von einem Multisig-Wallet kontrolliert. Das Einfrieren einer Adresse erfordert die Genehmigung mehrerer Unterzeichner, bevor der Antrag ausgeführt wird.
Auf Ethereum benötigt das Multisig-Wallet 3 Bestätigungen (Confirmations):

Auf Tron sind es 2:

Der Prozess läuft folgendermaßen ab:
- Ein Unterzeichner reicht einen Antrag ein — ein
submitTransaction()-Aufruf an den Multisig-Vertrag. Diese Transaktion ist sofort auf der Blockchain sichtbar. Sie enthält die Zieladresse und den Aktionstyp (addBlackList). - Andere Unterzeichner bestätigen — jeder Unterzeichner ruft
confirmTransaction()mit der Antrags-ID auf. - Sobald die Schwelle erreicht ist, wird der Antrag ausgeführt — die
addBlackList-Funktion des USDT-Vertrags wird ausgelöst, und die Zieladresse wird eingefroren.
Hier ist der entscheidende Punkt: Schritt 1 ist öffentlich. In dem Moment, in dem der submitTransaction()-Aufruf die Blockchain erreicht, kann jeder, der den Multisig-Vertrag überwacht, genau sehen, welche Adresse eingefroren werden soll — und die Einfrierung ist noch nicht erfolgt.
Die Zeit zwischen Schritt 1 und Schritt 3 ist die Einfrierungslücke.
Die Daten: 8.293 offengelegte Einfrierungsanträge
Wir haben jeden ausgeführten addBlackList-Antrag im BlockSec USDT Freeze Dashboard analysiert, das sowohl Ethereum als auch Tron von 2017 bis Februar 2026 abdeckt.
Das Gesamtbild
| Kennzahl | Ethereum | Tron |
|---|---|---|
| Ausgeführte Einfrierungsanträge gesamt | 2.731 | 5.562 |
| Mediane Verzögerung | ~5,1 Stunden | ~2,6 Stunden |
| Erforderliche Multisig-Bestätigungen | 3 | 2 |
| Innerhalb von 1 Stunde ausgeführt | 21,8 % | 33,3 % |
| Nach 1 Tag ausgeführt | 24,6 % | 20,8 % |
Nur etwa 5 % aller Einfrierungen auf beiden Chains werden innerhalb von 5 Minuten ausgeführt. Weniger als 30 % innerhalb einer Stunde.
Das bedeutet: Bei über 70 % aller USDT-Einfrierungen gibt es mindestens ein einstündiges Zeitfenster zwischen dem öffentlichen Antrag und der tatsächlichen Einfrierung.
Verzögerungsverteilung: Wo die meisten Einfrierungen liegen

Das häufigste Verzögerungsintervall auf beiden Chains liegt bei 1 bis 6 Stunden — 35,8 % der Ethereum-Anträge und 32,4 % der Tron-Anträge fallen in diesen Bereich. Ein paar Stunden zwischen Antrag und Ausführung. Das ist die „typische” Einfrierung.
Aber an den Rändern der Verteilung wird es kritisch:
- Auf Ethereum dauern 24,5 % der Einfrierungen mehr als einen Tag. Das sind 671 Anträge, bei denen das Ziel über 24 Stunden Vorwarnung hatte.
- Auf Tron dauern 20,8 % mehr als einen Tag — 1.155 Anträge.
- Auf Ethereum dauern 13,5 % mehr als eine Woche. Einige brauchten Monate.
Am schnellen Ende gibt es auf beiden Chains eine Handvoll nahezu sofortiger Einfrierungen (0 Sekunden Verzögerung). Dies sind Fälle, in denen alle erforderlichen Bestätigungen im selben Block eingereicht wurden — eine koordinierte Stapelverarbeitung (Batch Operation) durch Tethers Unterzeichner.
Die kumulative Ansicht

Die empirische kumulative Verteilungsfunktion (ECDF) zeigt es deutlich:
- Innerhalb von 5 Minuten: nur ~1,9 % der Ethereum-Einfrierungen und ~7,1 % der Tron-Einfrierungen wurden ausgeführt
- Innerhalb von 1 Stunde: 21,8 % auf Ethereum, 33,3 % auf Tron
- Innerhalb von 1 Tag: 75,4 % auf Ethereum, 79,2 % auf Tron
Wenn jemand einen Bot hat, der den Multisig-Vertrag überwacht, hat er bei 70–80 % aller Einfrierungsereignisse mindestens eine Stunde Zeit, um Gelder zu verschieben. Bei einem Viertel der Einfrierungen hat er über einen Tag.
Der Angriff: Front-Running (Vorwegnahme) von Einfrierungen durch Überwachung der Anträge
Das ist keine Theorie. Es passiert bereits.
Wie es funktioniert
- Den Multisig-Vertrag überwachen — Tethers Multisig-Adressen sowohl auf Ethereum als auch auf Tron sind öffentlich bekannt
submitTransaction()-Aufrufe parsen — wenn ein neuer Antrag erscheint, die Calldata dekodieren, um die Zieladresse und den Aktionstyp zu extrahieren- Wenn die Aktion
addBlackListist — sofort den Besitzer der Zieladresse alarmieren - Gelder verschieben — USDT an eine neue Adresse transferieren, bevor der Antrag genügend Bestätigungen für die Ausführung des Antrags (Proposal Execution) erreicht
Ein Bot kann dies in Echtzeit tun. Man überwacht einen öffentlichen Vertrag auf einen bestimmten Funktionsaufruf und dekodiert dann ABI-kodierte Parameter. Jeder Entwickler mit grundlegender Blockchain-Erfahrung kann dies an einem Nachmittag bauen.
Das Ausmaß des Problems
On-Chain-Analysen zeigen, dass seit 2017 etwa $78 Millionen in USDT während der Einfrierungsverzögerungsfenster verschoben wurden — $49,6 Millionen auf Tron und $28,5 Millionen auf Ethereum.
Im Kontext betrachtet:
- 54 % aller auf der Blacklist stehenden Adressen hatten mehr als 90 % ihrer Gelder transferiert, bevor die Einfrierung wirksam wurde
- 10 % der auf der Blacklist stehenden Adressen hatten zum Zeitpunkt der Einfrierung ein Guthaben von genau $0
- Allein auf Tron haben 170 von 3.480 Wallets (4,88 %) die Verzögerung erfolgreich genutzt, um ihre Konten zu leeren
In vielen Fällen ist es im Grunde so, als würde man das Scheunentor schließen, nachdem das Pferd bereits durchgegangen ist.
Reale Beispiele aus den Daten
Dies sind keine hypothetischen Szenarien. Hier sind reale Fälle aus unserer Datenbank, in denen während der Einfrierungslücke Gelder abgezogen wurden.
Fall 1: $37,3 Millionen in unter 4 Minuten abgezogen (Tron)
Am 5. Juni 2025 (UTC) wurde Tron Proposal #3839 eingereicht, um die Adresse TD3bLbnVvcvucnJm8uhvVYGwinUzFUFgud einzufrieren. Die Gesamtverzögerung betrug nur 5 Minuten und 42 Sekunden — historisch gesehen schnell.
Es spielte keine Rolle. Genau 3 Minuten und 42 Sekunden nach Einreichung des Antrags verschob eine einzelne Transaktion $37.300.258 an die Adresse TEVcwpWwS8wYz837TSBPd8fwMYBYrhnTQC. Als die Einfrierung 2 Minuten später ausgeführt wurde, war das Guthaben $0.
Eine Transaktion. Unter 4 Minuten Reaktionszeit. $37,3 Millionen weg.
Fall 2: $27,1 Millionen in 5 Minuten auf Ethereum verschoben
Am 26. Juli 2025 (UTC) wurde Ethereum Proposal #4461 eingereicht (Phalcon Explorer) mit der Zieladresse 0x928b8864151ee6C1E057964460bf5c7ADDbcA97f. Die Einfrierung dauerte 14 Minuten bis zur Ausführung.
Innerhalb von 5 Minuten und 12 Sekunden nach Einreichung des Antrags verschob eine einzelne Transaktion (Phalcon Explorer) $27.121.615 an 0x414Cf116d546185911361782361fA541424c662a. Die Einfrierung wurde ausgeführt (Phalcon Explorer) und erfasste $0. Die Adresse wurde im Januar 2026 wieder freigegeben — aber es gab nichts mehr zum Freigeben.
Fall 3: Das Streuungsmuster (Scatter Pattern) — $5,76 Millionen auf 12 Adressen in 11 Minuten
Dieser Fall ist der ausgefeilteste. Am 9. November 2023 (UTC) wurde Tron Proposal #952 eingereicht mit der Zieladresse TSYYMXK8PLSiMrHBadHAVpRKFfL5veuA7c. Die Einfrierung dauerte 32 Minuten bis zur Ausführung.
Ab 20 Minuten nach Beginn des Verzögerungsfensters verteilte der Betreiber systematisch $5.759.461 auf 12 verschiedene Adressen in schneller Folge — etwa ein Transfer pro Minute. Hier ein Ausschnitt des Streuungsmusters:
- Transfer 1: $199.878 →
TB55S4haj8f8EBHxP7dbMzxUBC3cmxGmRD - Transfer 3: $934.871 →
THvxgQ5Sm9ufSdASUagG2D8WHzGoasujVM - Transfer 12: $1.329.199 →
TJLy2xfasb6Xvky3Zurjk1r6AD39CR3bbG
Als die Einfrierung ausgeführt wurde: $206 verblieben. Die Adresse wurde weniger als 24 Stunden später wieder freigegeben. Nur $206 wurden zurückgegeben.
Fall 4: Das langsame Abfließen über 5 Stunden — $11,9 Millionen in 15 Transaktionen
TBikF4W7t6AFbTiA77GgsfXnR8aoYAVqnF war Ziel von Tron Proposal #1859, eingereicht am 17. September 2024 (UTC). Die Einfrierung dauerte über 5 Stunden bis zur Ausführung.
Der Betreiber tätigte 15 Transfers an 6 Adressen innerhalb dieses Zeitfensters — der erste große Transfer umfasste $1,3 Millionen, und der größte Einzeltransfer verschob $2,7 Millionen. Das Hauptziel TFjBdjNQnX7UxrWjvTvzhPu838h67iTV5J erhielt $8,3 Millionen über 5 Transaktionen. Insgesamt wurden $11.948.840 abgezogen. Doch diesmal leerte der Betreiber das Konto nicht vollständig — $2.903.018 wurden noch erfasst, als die Einfrierung ausgeführt wurde, was dies zu einer teilweisen Flucht macht (80,5 % der Gelder verschoben).
Das Muster ist eindeutig: Allein in diesen vier Fällen wurden $82,1 Millionen während der Einfrierungsfenster verschoben, wobei nur $2,9 Millionen tatsächlich erfasst wurden — eine Fluchtrate von 96,5 %.
Auf der anderen Seite hat Ethereum Einfrierungen im selben Block durchgeführt. Die Proposals #4861 bis #4864, eingereicht und ausgeführt zum selben Zeitstempel am 9. November 2025. Null Verzögerung. Dies beweist, dass es technisch möglich ist, wenn die Unterzeichner eng koordinieren.
Die Kluft zwischen bestem und schlechtestem Fall ist enorm: von 0 Sekunden bis über 5 Stunden, im selben Jahr, auf demselben System.
Wird Tether schneller?

Ja — aber die Verbesserung ist ungleichmäßig.
In den frühen Jahren (2017–2022) schwankten die Verzögerungen stark. Anträge blieben wochen-, manchmal monatelang unerledigt. Die mediane Verzögerung überstieg in manchen Quartalen regelmäßig 25 Tage.
Ende 2023 änderte sich etwas. Die medianen Verzögerungen sanken deutlich:
Ethereum:
| Quartal | Mediane Verzögerung | Anträge |
|---|---|---|
| Q4 2024 | ~1,5 Stunden | 185 |
| Q1 2025 | ~1,9 Stunden | 175 |
| Q3 2025 | ~1,8 Stunden | 191 |
| Q1 2026 | ~1,4 Stunden | 68 |
Tron:
| Quartal | Mediane Verzögerung | Anträge |
|---|---|---|
| Q4 2024 | ~47 Minuten | 494 |
| Q1 2025 | ~2,6 Stunden | 573 |
| Q2 2025 | ~2 Stunden | 767 |
| Q1 2026 | ~55 Minuten | 258 |
Der Trend ist real. Aber er ist volatil — im Q3 2025 auf Tron sprang die mediane Verzögerung auf ~24,5 Stunden, verursacht durch eine Reihe von Anträgen, die über einen längeren Zeitraum unerledigt blieben.
Tether wird schneller, besonders auf Tron, wo der 2-von-N-Schwellenwert niedriger ist. Aber „schneller” bedeutet in den meisten Fällen immer noch Stunden. Nicht Minuten. Nicht Sekunden.
Wachsendes Volumen

Das Einfrierungsvolumen ist explodiert. Im Jahr 2020 gab es auf Ethereum ~250 Einfrierungsanträge für das gesamte Jahr. Im Jahr 2024 über 700. Tron stieg von einigen hundert im Jahr 2022 auf über 4.000 im Jahr 2025 — wobei allein der Juli 2025 1.070 Anträge verzeichnete.
Mehr Anträge. Kürzere Bearbeitungszeiten. Aber die grundlegende Einschränkung bleibt: Solange das Multisig sequenzielle On-Chain-Bestätigungen erfordert, wird es immer eine Lücke geben.
Warum das wichtig ist: Auswirkungen auf die Compliance
Die GENIUS Act-Frage
Der US-amerikanische GENIUS Act, im Juli 2025 unterzeichnet, ist das erste umfassende bundesstaatliche Regulierungsrahmenwerk für Stablecoins. Es verpflichtet Emittenten, Token auf Anweisung von Strafverfolgungsbehörden „beschlagnahmen, einfrieren, vernichten oder deren Übertragung verhindern” zu können.
Tether kann all das. Aber wie schnell?
Wenn eine Strafverfolgungsbehörde eine Notfall-Einfrierung anordnet und das Multisig 5 Stunden braucht, gilt das dann als „Einfrierungsfähigkeit”? Was ist mit 6 Tagen?
Der GENIUS Act spezifiziert keine zeitliche Anforderung. Das ist eine praktische Lücke in der Regulierung. Wenn Tethers typische Einfrierung Stunden dauert, sind die Zielpersonen wahrscheinlich längst verschwunden.
Was Compliance-Teams tun sollten
Wenn Sie in einer Börse oder einem Finanzinstitut für Compliance verantwortlich sind:
- Verlassen Sie sich nicht ausschließlich auf Tethers Blacklist als Echtzeit-Kontrollinstrument. Bis eine Adresse auf der Blacklist erscheint, können die Gelder bereits anderswo sein.
- Überwachen Sie Antragseinreichungen, nicht nur Ausführungen. Der
submitTransaction()-Aufruf ist öffentlich und erfolgt Stunden vor der tatsächlichen Einfrierung. Wenn ein Einfrierungsantrag für eine Adresse erscheint, die auf Ihrer Plattform einzahlt — handeln Sie sofort. - Behandeln Sie den Antrag als Signal, nicht die Ausführung. In Ihren Risikomodellen ist der relevante Zeitstempel die Antragseinreichung, nicht das Blacklist-Ereignis.
Der Bedarf an Echtzeit-Überwachung
Die Einfrierungslücke schafft einen Bedarf an proaktiver Antragsüberwachung — nicht nur an der Beobachtung von AddedBlackList-Ereignissen. Bis dieses Ereignis ausgelöst wird, hat sich das Zeitfenster bereits geschlossen.
BlockSec Phalcon Compliance bietet genau das. Statt auf Einfrierungsereignisse zu reagieren, nachdem sie eingetreten sind, können Compliance-Teams Einfrierungsanträge in dem Moment erkennen, in dem sie eingereicht werden — Einzahlungen von betroffenen Adressen markieren, Auszahlungen stoppen oder Ermittlungsteams alarmieren, solange das Zeitfenster noch offen ist.
Sie können die vollständigen Antragsdaten, einschließlich Echtzeit-Verzögerungsverfolgung und ECDF-Diagrammen, im BlockSec USDT Freeze Dashboard einsehen.
Was könnte das Problem lösen?
Die Einfrierungslücke ist ein Architekturproblem. Mehrere Ansätze könnten sie reduzieren oder beseitigen:
Vorab signierte Stapel-Einfrierungen. Alle erforderlichen Signaturen off-chain koordinieren und in einem einzigen Block einreichen. Unsere Daten zeigen, dass dies bereits gelegentlich geschieht — die Anträge mit 0 Sekunden Verzögerung beweisen, dass es funktioniert. Es sollte zum Standard werden.
Notfall-Einzelunterzeichner-Pfad. Eine dedizierte Einfrierungsfunktion, die nur einen autorisierten Unterzeichner für zeitkritische Sperrungen erfordert. Dies tauscht Dezentralisierung gegen Geschwindigkeit — ein vertretbarer Kompromiss für Compliance-Operationen.
Commit-Reveal-Verfahren (Commit-Reveal Scheme). Zuerst einen Commitment-Hash einreichen, die Zieladresse erst zum Zeitpunkt der Ausführung enthüllen. Die Multisig-Governance-Struktur bleibt intakt, aber Front-Running-Bots können nicht sehen, wer ins Visier genommen wird.
Off-Chain-Signierung (Off-Chain Signing), On-Chain-Ausführung. Den Genehmigungsprozess off-chain verlagern (EIP-712 Typed Signatures oder ähnlich) und dann alle Signaturen in einer einzigen On-Chain-Transaktion bündeln. Kein sichtbarer „ausstehender Antrag”-Zustand mehr.
Jeder Ansatz erfordert einen Kompromiss — Geschwindigkeit gegen Dezentralisierung, Transparenz gegen Sicherheit. Aber der Status quo, bei dem illegale Akteure stundenlange Vorwarnung erhalten, dass eine Einfrierung bevorsteht, ist das schlechteste Ergebnis für alle außer den Personen, die eingefroren werden sollen.
Fazit
Tethers Einfrierungsfähigkeit ist real und wächst. Die seit 2023 eingefrorenen $3,3 Milliarden zeigen ein echtes Engagement für Compliance. Aber die Daten sind eindeutig: Der Multisig-Prozess erzeugt eine vorhersehbare, ausnutzbare Verzögerung, die die Wirksamkeit jeder Einfrierung untergräbt.
8.293 Anträge. Die Zahlen:
- Mediane Verzögerung: 2,6–5,1 Stunden je nach Chain
- ~70 % der Einfrierungen dauern mehr als 1 Stunde
- ~22 % dauern mehr als 1 Tag
- Die Verzögerung ist öffentlich sichtbar für jeden, der den Multisig-Vertrag beobachtet
Die Kernaussage: Überwachen Sie Anträge, nicht nur Ausführungen. Die Einfrierungslücke ist der Punkt, an dem Compliance-Durchsetzung auf illegale Geldbewegungen trifft — und derzeit steht diese Lücke weit offen.
Erkunden Sie den vollständigen Datensatz im BlockSec USDT Freeze Dashboard. Filtern Sie nach Chain, Zeitraum, Status und sehen Sie die Ausführungsverzögerung für jeden einzelnen Antrag.
Diese Analyse verwendet Daten aus dem BlockSec USDT Freeze Dashboard. Verzögerung = Differenz zwischen submit_time (Block-Zeitstempel des Multisig-submitTransaction()) und execute_time (Block-Zeitstempel der addBlackList-Ausführung). Datenstand: 18. Februar 2026.
Für Echtzeit-Compliance-Überwachung, die Einfrierungsanträge in dem Moment erkennt, in dem sie eingereicht werden — nicht erst nach ihrer Ausführung — siehe BlockSec Phalcon Compliance.