---
title: "Validator-Ausstiegs- und Auszahlungswarteschlangen"
description: "Eine Validator-Austrittsanfrage, eine Exit-Kapazitätswarteschlange, Verzögerung bei der Verantwortung, Auszahlungssweep oder Anspruch sowie Anbieter-Einlösung sind verschiedene Phasen. Rekonstruieren Sie den genauen Protokoll-Zustandsautomaten, die Autorität, den Durchsatz, die Strafbarkeit und den Vermögenspfad, bevor Sie schätzen, wann Gelder verfügbar sein werden."
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.
# Validator-Ausstiegs- und Auszahlungswarteschlangen
> Nur zu Bildungszwecken; keine Anlageberatung. Investieren kann zu Verlusten führen.
## Direkte Antwort
Eine Validator-Exit-Warteschlange begrenzt, wie schnell Konsensgewicht aus einem aktiven Validator-Set austreten kann. Es ist nicht unbedingt derselbe Mechanismus wie eine Abhebungs-Anforderungswarteschlange, eine Entbündelungs- oder Rechenschaftsverzögerung, ein automatisches Abräumen berechtigter Guthaben, eine nutzergesteuerte Anspruchnahme oder eine Rücknahmewarteschlange eines Staking-Anbieters. Die nützliche Frage ist nicht „Wie lang ist die Warteschlange?“, sondern „In welchem Zustand befindet sich diese Position, welcher Übergang ist als nächstes dran und unter welcher Bedingung wird die Anlage für ihren Eigentümer verfügbar?“
Trennen Sie diese Stufen und Ansprüche:
- **Annahme der Anfrage:** eine signierte Nachricht, Transaktion, Vertragsaufruf oder Anbieteranweisung ist gültig eingeschlossen und dem richtigen Validator, Konto oder der richtigen Position zugeordnet.
- **Ausstiegs- oder Deaktivierungskapazität:** ein Protokoll begrenzt, wie viele Validatoren oder effektives Gewicht pro Epoche, Sitzung oder anderem Intervall aufhören können, teilzunehmen.
- **Verantwortlichkeit oder Entbündlungsverzögerung:** eine ausgeschiedene oder nicht delegierte Position bleibt gesperrt und kann weiterhin Strafen für vorheriges zurechenbares Verhalten ausgesetzt sein.
- **Abhebungsverarbeitung:** ein berechtigtes Guthaben wird durch einen Protokoll-Sweep übertragen, durch eine Anspruchstransaktion abgerufen, von einem Einsatzkonto freigegeben oder bei der Verarbeitung einer Fälligkeitswarteschlange transferiert.
- **Anbieterrücknahme:** ein Verwahrer, Pool, Liquid-Staking-Token oder Restaking-Vertrag wendet seine eigenen Bündelungen, Liquidität, Gebühren, Wechselkurse, Berechtigungen und Verzögerungen rund um das Basisprotokoll an.
Ethereum zeigt, warum die Unterscheidungen wichtig sind. Ein vollständiger Validator-Austritt kann mit dem Validator-Signaturschlüssel initiiert werden oder nach den aktuellen Regeln von der Ausführungsschicht durch die Auszahlungsbehörde. Nach der Planung des Austritts und dem späteren abhebbaren Zustand wird eine berechtigte vollständige Auszahlung mit Ausführungsauszahlungsnachweisen automatisch durchgeführt. Legacy-Type 1-Validatoren und zusammengesetzte Type 2-Validatoren haben unterschiedliches Verhalten bei Teilabhebungen. Eine Anforderungs-Transaktion, Konsens-Austritt, abhebbares Epoch und Sweep sind daher separate Beobachtungen.
Diese Ethereum-Labels sind nicht universell. In einer Cosmos SDK-Kette erstellt die Rückdelegation eines Delegators einen Unbonding-Eintrag mit einer kettenkonfigurierten Fertigstellungszeit, und externe Module können ein Unbonding auf Eis legen. In Solana deaktiviert eine Einsatzkontoberechtigung eine Delegation, der Einsatz kühlt über Epochen hinweg ab, und die Abhebungsberechtigung kann inaktive Einsätze unter Berücksichtigung von Sperrfristen abheben. Restaking-Verträge können eine weitere ausstehende Abhebung und eine strafbare Frist hinzufügen. Überprüfen Sie immer das genaue Netzwerk, die Version, das Modul, den Vertrag und die Servicebedingungen.
## Wie man den Zeitpunkt von Ausstieg und Rückzug analysiert
### 1. Definiere die Position und das Regelwerk
Zeichnen Sie die `network`, `chain ID`, aktive Fork oder Laufzeit, Block oder Epoche, Client/Spezifikationsversion, Staking-Modul oder Verträge und Dienstleistungsbedingungen auf. Identifizieren Sie, ob das Objekt eine Validator-Identität, Eigenbeteiligung, delegierte Anteile, ein Staking-Konto, einen gebündelten Anspruch, ein Liquid-Staking-Token oder eine erneut gestakte Zuweisung ist. Wenden Sie keine Validator-Ausstiegsregel auf die Einlösung eines Delegators oder eine Off-Chain-Verpflichtung eines Anbieters an.
### 2. Überprüfen Sie die Autorität und bitten Sie um Bestätigung
Ordnen Sie den Validator-Signaturschlüssel, das Abhebungscredential oder die Berechtigung, die Einsatzberechtigung, den Kontoinhaber, den Vertragsaufrufer, den Begünstigten und den Gebührenzahler zu. Reproduzieren Sie die erforderlichen Nachrichtenfelder, die Signaturdomäne, den Validator-Index oder den öffentlichen Schlüssel, den Betrag, das Nonce, das Ziel und die Gebühr. Bestätigen Sie die endgültige Aufnahme und den resultierenden Zustand; eine lokal signierte Datei, eine eingereichte Transaktion, ein Anbieterticket oder eine erfolgreiche Simulation ist kein Nachweis dafür, dass das Protokoll die Anfrage akzeptiert hat.
### 3. Rekonstruieren Sie die Zustandsmaschine
Schreiben Sie jeden Zustand und jede Übergang statt eines geschätzten Datums. Ein illustrativer Validator-Pfad ist `active -> exit_requested -> exit_scheduled -> exited -> withdrawable -> withdrawal_processed -> wallet_credited`. Ein Delegator kann stattdessen durch `bonded -> unbonding -> matured -> transferred` gehen, während ein Stake-Konto `active -> deactivating -> inactive -> withdrawn` sein kann. Notieren Sie, welche Übergänge automatisch sind und welche eine weitere Transaktion oder Dienstleistung erfordern.
### 4. Quantifizieren Sie jedes Engpass
Getrennte Anforderungs-Eingänge, Validator-Ausstiegswechsel, feste Verzögerungen, Auszahlung-Sweep-Kapazität, Vertragswarteschlangen, Anbieter-Batching und Finalität oder Bestätigung. Bestimmen Sie, ob die Kapazität anhand von Validator-Einträgen, effektivem Einsatz, Saldo, Anfragen, Gas oder verstrichener Zeit gemessen wird. Abfragen von `queue_ahead`, `capacity_per_interval`, aktive Menge oder Saldo und eventuelle Limits am selben finalisierten Beobachtungspunkt. Eine einfache Schätzung `ceil((work_ahead + own_work) / capacity)` ist nur gültig, wenn Annahmen zu Reihenfolge und Kapazität zutreffen.
### 5. Finde Pflichten, Belohnungen und Abziehbarkeit
Finden Sie die genaue Epoche, Höhe oder den Zustand, in dem Vorschlags- und Abstimmungspflichten enden, wann gewöhnliche Belohnungen aufhören, wann Strafen noch angewendet werden können und wann das Guthaben nicht mehr kürzbar ist. Diese Zeiten müssen nicht übereinstimmen. Halten Sie den Validator online und korrekt konfiguriert, bis der Protokollzustand sagt, dass seine Pflichten beendet sind; eine übertragene Austrittsanfrage oder der Status im Front-End ist keine ausreichende Autorität, um ihn herunterzufahren.
### 6. Verfolge die Vermögens- und Anspruchsebenen
Verfolgen Sie native Einheiten von gebundenen oder aktiven Buchungen über ausstehende, entbindende, abhebungsfähige, Vertrags-Treuhand-, Anbieteraufbewahrungs- und Zielkonten. Bewerten Sie separat Anteile, Empfangstoken oder Liquid-Staking-Token anhand ihres Wechselkurses und Marktpreises. Gleichen Sie Protokollbelohnungen, Strafen, Slashing, Provision, Rücknahmegebühren, Gas, Brückenkosten und Rundungen ab. Der Verkauf einer Forderung überträgt das Liquiditätsrisiko auf einen Käufer; er beschleunigt nicht den Übergang des Basisprotokolls.
### 7. Überprüfen Sie den Abschluss und planen Sie die Liquidität
Verwenden Sie den finalisierten Zustand, Protokollereignisse, Warteschlangenaufzeichnungen, Auszahlungobjekte, Zielkonto-Salden und Anbieterverbindlichkeiten, um jeden Übergang zu beweisen. Speichern Sie Anforderungskennungen und die für die Schätzung verwendete Parametersnapshot. Erstellen Sie Geldmittelpläne mit einem Bereich und einem Notfallpuffer anstelle eines einzelnen Datums und definieren Sie Eskalationen für fehlende Abbuchungen, pausierte Verträge, falsche Zugangsdaten, Insolvenz des Anbieters oder einen Saldo, der von der erwarteten Abstimmung abweicht.
## Beispielaufgaben
### Mehrstufige Zeitberechnung
Betrachten Sie ein illustratives Protokoll mit `block_time = 12 seconds` und `epoch = 30 blocks = 6 minutes`. Eine Anfrage benötigt `4 blocks`, um den gewählten Bestätigungspunkt zu erreichen, wartet `72 epochs` auf Ausgangskapazität, hat dann eine `8 epochs`-Verantwortlichkeitsverzögerung und eine erwartete `12 blocks` bis zur Übertragungsverarbeitung:
`4 * 12 = 48 seconds`.
`72 * 6 = 432 minutes`.
`8 * 6 = 48 minutes`.
`12 * 12 = 144 seconds = 2.4 minutes`.
Die gesamte illustrative Zeit beträgt `48 seconds + 432 minutes + 48 minutes + 2.4 minutes = 483.2 minutes = 8.0533 hours`. Die Phasen summieren sich, weil sie aufeinanderfolgend sind. Dies ist keine Ethereum-Vorhersage: Reale Regeln können unterschiedliche Intervalle, zustandsabhängige Abwanderung, Mindestverzögerungen, Sweep-Algorithmen und Endgültigkeitsannahmen verwenden.
### Gewichtsbasierte Warteschlange mit variabler Kapazität
Angenommen `work_ahead = 50,000` effektive Einheiten, stellt dieser Ausgang `own_work = 320` dar, und anfängliche `capacity_per_epoch = 640`. Bei konstanter Kapazität:
`ceil((50,000 + 320) / 640) = ceil(78.625) = 79 epochs`.
Bei `6 minutes` pro Epoche, das sind `79 * 6 = 474 minutes = 7.9 hours`. Aber nehmen wir an, dass die Kapazität nach der Epoche 30 auf `512` fällt. Die ersten 30 Epochen bearbeiten `30 * 640 = 19,200`, es bleiben `50,320 - 19,200 = 31,120` übrig. Der Rest dauert `ceil(31,120 / 512) = 61 epochs`, sodass die überarbeitete Gesamtsumme `30 + 61 = 91 epochs = 9.1 hours` beträgt. Eine Live-Schätzung muss die Kapazität und Reihenfolge neu berechnen, anstatt eine Dashboard-Rate einzufrieren.
### Saldoabstimmung beim Austritt
Ein illustrativer Validator beginnt mit `32` Einheiten, verdient `0.40` bevor die Pflichten enden, verursacht `0.05` gewöhnliche Strafen und erhält später einen `1.20`-Abzug, der dem Protokollfenster der Exponierung zugeschrieben wird. Der Betrag, der vor jeglicher Anbietergebühr oder Steuer verfügbar ist, beträgt:
`32 + 0.40 - 0.05 - 1.20 = 31.15 units`.
Die Anfrage hat keine Auszahlung in 32-Einheiten gesperrt. Änderungen des Protokollguthabens, die Buchhaltung des Anbieters und Änderungen des Marktpreises sind separate Konten. Wenn das Ziel `31.15` erhält, gleicht das den Pfad der nativen Einheit aus, sagt aber nichts über den Fiat-Wert oder Erstattungsrechte aus.
### Liquiditätsanspruch versus wartende Einlösung
Angenommen, `100` Liquid-Staking-Token können jetzt jeweils zu `0.965` nativen Einheiten verkauft werden, was Folgendes einbringt:
`100 * 0.965 = 96.5 units`.
Ein Anbieter gibt stattdessen die Rücknahme mit einer nativen Einheit pro Token nach einer Warteschlange mit einer Gebühr von `0.2%` oder `100 * (1 - 0.002) = 99.8 units` an. Der Unterschied beträgt `99.8 - 96.5 = 3.3 units`, und der Sofortverkaufsabschlag im Verhältnis zu den angegebenen Warteschlangen-Erträgen beträgt `3.3 / 99.8 = 3.3066%`. Die 3.3-Einheiten-Spanne kompensiert in diesem Schnappschuss nur für Zeit, Unsicherheit und Liquidität; Kürzungen, Wechselkursänderungen, Vertragsverluste oder eine pausierte Warteschlange können die späteren Erträge verändern.
## Risiken und Prüfungsfehler
- **Falsche Warteschlange:** Validator-Austritt, Eingang von Auszahlungsanträgen, Unbonding, Sweep, Vertrag und Anbieter-Rückzahlung haben unterschiedliche Zustände und Kapazitäten.
- **Falsches Regelwerk:** Eine andere Chain, Fork, Laufzeit, Modulversion, ein Testnetz oder eine Vertragsbereitstellung kann andere Übergänge verwenden.
- **Veraltete Parameter:** Austrittsrate, feste Verzögerungen, Sweep-Grenzen, Gebühren, Sperrfristen und Anbieterbedingungen können sich nach einer Schätzung ändern.
- **Nicht akzeptierter Antrag:** Signieren, Senden, Simulieren oder Öffnen eines Tickets beweist keine endgültige Annahme durch das Protokoll.
- **Verwechslung von Befugnissen:** Validator-, Auszahlungs-, Stake-, Eigentümer-, Verwahrer- und Vertragsadmin-Schlüssel können unterschiedliche Aktionen erlauben.
- **Berechtigungs- oder Zielfehler:** Eine irreversible Umwandlung der Berechtigung oder eine falsche Auszahlungsadresse kann die Kontrolle dauerhaft übertragen.
- **Vorzeitiges Abschalten:** Wer Pflichten vor dem protokollierten Austrittszustand beendet, kann Belohnungen verlieren oder Strafen auslösen.
- **Falscher Belohnungsstichtag:** Antrag, geplanter und tatsächlicher Austritt, Auszahlbarkeit und Übertragung können unterschiedlichen Abgrenzungsregeln folgen.
- **Verbleibendes Slashing-Risiko:** Ausgetretene, im Unbonding befindliche oder wartende Mittel können wegen früherer zurechenbarer Verstöße weiterhin gefährdet sein.
- **Abweichung zwischen Anzahl und Gewicht:** Eine als Validator-Anzahl dargestellte Warteschlange kann eine nach effektivem Guthaben oder Anteilen begrenzte Kapazität falsch wiedergeben.
- **Dynamischer Warteschlangenfehler:** Spätere Parameter- oder Aktivsatzänderungen können den Durchsatz verändern, auch wenn spätere Anträge nicht vorgreifen dürfen.
- **Verwechslung von Sweep und Anspruch:** Mit der Berechtigung kann eine automatische Übertragung ausgelöst werden, ein Anspruch nötig sein oder ein zyklischer Sweep ausstehen.
- **Verwechslung von Teil und Gesamt:** Überschussauszahlung, teilweise Aufhebung der Delegation und vollständiger Validator-Austritt sind nicht gleichwertig.
- **Sperren und Zurückbehaltungen:** Kontosperren, Governance-Kontrollen, Sicherheitspausen oder externe Modulsperren können über die nominale Fälligkeit hinausreichen.
- **Abweichung beim Anbieter:** Ein Dienst kann die Rückzahlung trotz Abschluss des Basisprotokolls verzögern, bündeln, begrenzen, verrechnen oder ablehnen.
- **Überschneidung mit Restaking:** Der Austritt aus der Basis-Chain muss weder einem anderen Dienst zugewiesenen Stake freigeben noch dessen Strafzeitraum beenden.
- **Basisrisiko liquider Ansprüche:** Ein Liquid-Staking-Token kann unter seinem Anspruchswert gehandelt werden oder unter Stress seine Konvertierbarkeit verlieren.
- **Gebühren- und Rundungsverlust:** Gas, dynamische Antragsgebühren, Provisionen, Anteilskonvertierung, Bridge-Gebühren und Dezimaländerungen beeinflussen den Auszahlungsbetrag.
- **Verwahrungs- oder Vertragsausfall:** Kompromittierte Schlüssel, Insolvenz, Upgrade-Befugnisse, Fehler oder ein Bridge-Ausfall können Vermögenswerte sperren oder umleiten.
- **Beobachtbarkeits- und Finalitätsfehler:** Dashboards können verzögert sein, gesperrte Einträge auslassen, geschätzte und finale Zustände verwechseln oder ein später reorganisiertes Ereignis melden.
## Häufige Missverständnisse
### Bedeutet das Einreichen eines Austritts, dass die Validator-Aufgaben sofort enden?
Nein. Anforderungsaufnahme, Beendigung der Planung und der Zustand, in dem Aufgaben enden, sind getrennt. Fahren Sie gemäß dem Protokoll fort, bis der endgültige Zustand bestätigt, dass der Validator nicht mehr teilnehmen muss.
### Bedeutet abhebbar, dass das Zielwallet gutgeschrieben wurde?
Nein. `withdrawable` beschreibt normalerweise die Berechtigung. Das Protokoll muss möglicherweise dennoch den Validator durchsuchen, ein Benutzer muss möglicherweise beanspruchen, ein Konto benötigt möglicherweise eine explizite Abhebung, oder ein Anbieter muss möglicherweise seine Haftung freigeben. Überprüfen Sie das Zielguthaben.
### Kann die Warteschlangenlänge, geteilt durch die heutige Rate, ein genaues Datum ergeben?
Nein. Das Display kann die falsche Einheit anzeigen, die Kapazität kann zustandsabhängig sein, feste Verzögerungen und Durchlaufzeiten können folgen, und Versorgerstufen können weggelassen werden. Geben Sie alle Annahmen an und berechnen Sie eine Spannweite.
### Umgeht der Verkauf eines Liquid-Staking-Tokens die Ausstiegs-Warteschlange?
Es verschafft dem Verkäufer sofortige Marktliquidität, wenn ein Käufer existiert. Der zugrunde liegende Anteil oder der Rückforderungsanspruch eines anderen Inhabers folgt weiterhin dem Protokoll und den Regeln des Anbieters, während der Verkäufer den Marktpreis und die Handelskosten akzeptiert.
### Ist eine beworbene Entbindungs- oder Auszahlungsfrist ein garantiertes Maximum?
Nein. Es kann eine minimale oder erwartete Verzögerung sein, die die Einbeziehung von Anfragen, Überlastung, Endgültigkeit, Durchläufen, Pausen, Vertragsunterbrechungen, Anbieterbündelung oder Vorfallreaktionen ausschließt. Nur die aktiven Regeln und der beobachtete Zustand definieren den Abschluss.
## Verwandte Themen
- [Validator](/de/crypto/validator/)
- [Schlitzen](/de/crypto/slashing/)
- [Einsatz](/de/crypto/staking/)
- [Liquid Staking](/de/crypto/liquid-staking/)
- [Neustaking](/de/crypto/restaking/)
## Quellen
- [Staking-Abhebungen](https://ethereum.org/staking/withdrawals/) - Ethereum.org (zugegriffen: 2026-08-19)
- [Ethereum Konsensspezifikationen: Beacon-Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (zugegriffen: 2026-08-19)
- [Ethereum Konsens-Spezifikationen: Capella](https://github.com/ethereum/consensus-specs/blob/master/specs/capella/beacon-chain.md) - Ethereum Foundation (zugegriffen: 2026-08-19)
- [Ethereum Konsens-Spezifikationen: Electra](https://github.com/ethereum/consensus-specs/blob/master/specs/electra/beacon-chain.md) - Ethereum Foundation (zugegriffen: 2026-08-19)
- [EIP-7002: Auslöschbare Abhebungen der Ausführungsschicht](https://eips.ethereum.org/EIPS/eip-7002) - Ethereum Improvement Proposals (zugegriffen: 2026-08-19)
- [Cosmos SDK x/Staking-Modul](https://docs.cosmos.network/sdk/v0.50/build/modules/staking/README) - Cosmos SDK (zugegriffen: 2026-08-19)
- [Stake Accounts](https://solana.com/docs/references/staking/stake-accounts) - Solana Foundation (zugegriffen: 2026-08-19)
- [EigenLayer Delegationsmanager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (zugegriffen: 2026-08-19)
Source: https://wiki.fcontext.com/de/crypto/validator-exit-withdrawal-queue/index.mdx