---
title: "Erzwungene L2-Auszahlung"
description: "Protokollspezifischer Leitfaden zu erzwungener Aufnahme, Auszahlung und Notausstieg: Garantien, Abhängigkeiten und Prüfung des Ausstiegspfads."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Erzwungene L2-Auszahlung
> Nur zu Bildungszwecken; keine Finanz- oder Sicherheitsberatung. Ausstiegsmechanismen, Fristen, Gebühren, Vertragsrechte und Annahmen zur Datenverfügbarkeit unterscheiden sich je L2 und können sich durch Upgrades ändern.
## Direkte Antwort
Eine erzwungene L2-Auszahlung ist ein Protokollpfad, über den Nutzer einen Ausstieg ohne Zustimmung des L2-Betreibers beginnen oder abschließen können. Der Begriff ist nicht standardisiert. In manchen Systemen wird ein Auszahlungsantrag direkt an einen L1-Vertrag gesendet; in anderen ist nur die erzwungene Aufnahme verfügbar. Diese garantiert lediglich, dass eine von L1 stammende Transaktion in die L2-Ausführungswarteschlange gelangt. Danach bleibt der normale Auszahlungs- und Finalisierungsablauf der kanonischen Bridge erforderlich.
Ein Notausstieg ist ein stärkerer Notfallpfad, wenn normale Zustandsaktualisierungen ausfallen. Er kann die Anwendung einfrieren und Nutzern erlauben, Guthaben gegen eine festgeschriebene Zustandswurzel nachzuweisen. Keiner dieser Mechanismen garantiert einen sofortigen Ausstieg, einen bestimmten Vermögenswert oder Schutz vor Vertragsfehlern und Governance-Rechten. Die tatsächliche Garantie ergibt sich aus dem bereitgestellten Code, der aktuellen Konfiguration, verfügbaren Zustandsdaten und der Fähigkeit, die nötigen Transaktionen oder Nachweise zu erstellen und einzureichen.
## Funktionsweise
- **Primitive bestimmen.** Erzwungene Aufnahme, erzwungene Auszahlung und Escape-Modus lösen unterschiedliche Probleme. Die Aufnahme umgeht einen zensierenden oder ausgefallenen Sequencer. Ein Auszahlungsantrag verpflichtet Protokoll oder Betreiber, den Ausstieg zu bearbeiten oder seine Ungültigkeit nachzuweisen. Der Escape-Modus ist meist die letzte Instanz: Normale Aktualisierungen enden und Auszahlungen erfolgen mit Zustandsnachweisen.
- **Über L1 einsteigen.** Der Nutzer sendet eine Transaktion an den dokumentierten L1-Inbox-, Portal- oder Abwicklungsvertrag. Beim OP Stack werden L1-Einzahlungen innerhalb des Sequenzierungsfensters in L2-Blöcke abgeleitet. Bei Arbitrum Nitro gelangt eine Nachricht in die Delayed Inbox und kann nach der konfigurierten Verzögerung in die Haupt-Inbox gezwungen werden, falls der Sequencer sie nicht aufgenommen hat.
- **Protokollverarbeitung abwarten.** Die L1-Bestätigung ist nur der erste Prüfpunkt. Der Antrag muss möglicherweise Teil der kanonischen L2-Kette werden, erfolgreich ausgeführt werden, in einem nachgewiesenen oder bestätigten Zustand erscheinen, eine Anfechtungs- oder Schonfrist durchlaufen und auf L1 finalisiert werden. Auch eine erzwungene Transaktion kann wegen falscher nonce, zu wenig Gas, falscher calldata, Token-Beschränkungen oder geändertem L2-Zustand scheitern.
- **Ausstiegsbedingungen erfüllen.** StarkEx Spot zeigt einen echten erzwungenen Auszahlungs- und Escape-Ablauf. Der Nutzer sendet `fullWithdrawalRequest`; die Anwendung muss den Antrag erfüllen oder seine Ungültigkeit beweisen. Bleibt er nach `FREEZE_GRACE_PERIOD` offen, kann das Einfrieren beantragt werden. Der Escape erfordert einen Merkle-Pfad zur eingefrorenen Vault-Wurzel, die Nachweisprüfung, einen `escape`-Aufruf und den normalen Onchain-`withdraw`-Aufruf.
- **Datenverfügbarkeit prüfen.** Eine Zustandswurzel ist eine Bindung, nicht das zugrunde liegende Guthaben oder der Merkle-Pfad. Werden die zur Rekonstruktion nötigen Daten auf L1 veröffentlicht, kann eine unabhängige Partei grundsätzlich einen Ausstiegsnachweis erstellen. Bei Validium oder anderen Offchain-Designs kann der Nutzer auf die Datenfreigabe durch Komitee oder Betreiber angewiesen sein. Nachweisgültigkeit und Datenverfügbarkeit sind getrennte Garantien.
- **Kontrolle und Werkzeuge prüfen.** Zu prüfen sind Pausen-, Einfrier-, Upgrade- und Governance-Rechte, genaue Vertragsadressen und Proxy-Implementierungen, unterstützte Vermögenswerte, Schlüssel, L1- und L2-Gas, Nachweissoftware und unabhängige Oberflächen. Ein theoretisch korrekter Mechanismus kann ohne Daten, Werkzeuge oder ausreichende L1-Mittel unpraktikabel sein.
## Beispiel
Angenommen, Sequencer und offizielle Oberfläche eines Rollups sind nicht verfügbar, L1 finalisiert aber weiter. Zuerst werden Chain-ID und kanonische L1-Verträge anhand der offiziellen Dokumentation geprüft. Gibt es nur erzwungene Aufnahme, sendet der Nutzer eine L1-zu-L2-Transaktion, welche die L2-Auszahlungsfunktion der kanonischen Bridge aufruft. Anschließend werden L1-Einreichung, erzwungene Aufnahme, L2-Ausführung, Zustandsbindung, Anfechtungs- oder Nachweisphase und L1-Finalisierung getrennt verfolgt. Eine erfolgreiche L1-Einreichung beweist nicht den Erfolg des Auszahlungsaufrufs.
Bei einem StarkEx-System ist die Reihenfolge anders: dokumentierten Zwangsantrag senden, konfigurierte Schonfrist abwarten, Erfüllung oder nachgewiesene Ungültigkeit prüfen und Einfrieren sowie Escape nur bei erfüllten Vertragsbedingungen verwenden. Vault-Kennung, Schlüssel und Merkle-Pfad müssen zum eingefrorenen Zustand passen. Das Verfahren von Arbitrum oder OP Stack zu übernehmen wäre falsch, obwohl alle gelegentlich als „erzwungene Auszahlung“ bezeichnet werden.
Vor einer Abhängigkeit von einem Pfad sollte er bei gesundem System mit kleinem Betrag getestet werden. Vertragsadressen, Funktionssignaturen, erwartete Ereignisse, Fristen und Transaktionshashes werden dokumentiert und über einen zweiten vertrauenswürdigen RPC oder Explorer geprüft. Niemals Seed-Phrase oder privaten Schlüssel auf einer „Notauszahlungs“-Website eingeben oder zusätzliche „Entsperr“-Zahlungen an Supportkonten oder Direktnachrichten senden.
## Risiken
- Das Protokoll bietet erzwungene Aufnahme, aber keine direkte Auszahlungsfunktion.
- Der L1-Antrag ist bestätigt, doch der L2-Aufruf scheiterte oder wurde noch nicht ausgeführt.
- Anfechtungs-, Nachweis-, Schon- oder Finalisierungsfristen verzögern den Zugriff.
- Zustandsdaten oder Merkle-Pfad fehlen, besonders bei Offchain-Datenverfügbarkeit.
- Falsche Chain, Vertrag, Proxy-Implementierung, Funktion oder Vault-Kennung werden benutzt.
- Der Ausstiegsvertrag ist pausiert, aktualisiert, falsch eingefroren oder fehlerhaft.
- Governance, Sicherheitsrat oder andere privilegierte Akteure können den Pfad ändern.
- Der Vermögenswert ist nicht unterstützt, nicht standardisiert, illiquide oder margengebunden.
- Hohe L1-Gaskosten oder fehlendes natives Gas verhindern Einreichung oder Finalisierung.
- Offizielle Oberflächen, RPCs, Indexer oder Nachweiswerkzeuge fehlen im Notfall.
- Gefälschte Oberfläche, Anzeige oder Supportnachricht stiehlt Zugangsdaten oder Mittel.
- Der Marktwert kann während der Verzögerung fallen; Ausstiegsfähigkeit schützt keinen Preis.
## Häufige Missverständnisse
- **„Erzwungene Auszahlung“ hat einen universellen Ablauf.** Namen und Garantien sind protokollspezifisch; Dokumentation und Verträge der bereitgestellten Version zählen.
- **Erzwungene Aufnahme bringt Mittel sofort auf L1 zurück.** Sie garantiert meist nur Reihenfolge oder Ausführungszugang; die Bridge-Auszahlung hat einen eigenen Ablauf.
- **Ein L1-Transaktionshash beweist den erfolgreichen Ausstieg.** Er beweist nur die L1-Aufnahme; L2-Ausführung und L1-Finalisierung sind getrennt zu prüfen.
- **Ein Gültigkeitsnachweis garantiert verfügbare Ausstiegsdaten.** Nachweiskorrektheit und Datenverfügbarkeit sind verschieden; Offchain-Daten schaffen Abhängigkeiten.
- **Der Notfallpfad ist vertrauenslos, weil eine Funktion existiert.** Nutzbarkeit hängt auch von Rechten, Konfiguration, Daten, Software, Gas und Schlüsseln ab.
- **Ein Notausstieg beseitigt Finanzrisiken.** Er adressiert Liveness oder Zensur, nicht Preis-, Liquiditäts-, Vertrags- oder Schlüsselrisiken.
## Verwandte Themen
- [Kanonische Bridge](/de/crypto/canonical-bridge/)
- [Optimistic Rollup](/de/crypto/optimistic-rollup/)
- [Rollup-Notausstieg](/de/crypto/rollup-escape-hatch/)
- [Sequencer](/de/crypto/sequencer/)
- [ZK Rollup](/de/crypto/zk-rollup/)
## Quellen
- [Überblick über das OP-Stack-Protokoll](https://specs.optimism.io/protocol/overview.html) - OP Stack Specification (abgerufen: 2026-08-21)
- [Arbitrum Nitro: ein Optimistic Rollup der zweiten Generation](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (abgerufen: 2026-08-21)
- [Auszahlung und Notausstieg ohne Zustimmung der Anwendung](https://docs.starkware.co/starkex/spot/withdrawing_and_escaping_without_app_approval.html) - StarkEx Documentation (abgerufen: 2026-08-21)
- [Datenverfügbarkeit](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation (abgerufen: 2026-08-21)
Source: https://wiki.fcontext.com/de/crypto/l2-forced-withdrawal/index.mdx