﻿---
title: "So legen Sie einen DeFi-Liquidationspuffer fest"
description: "Bestimmen Sie einen DeFi-Liquidationspuffer anhand gestresster Sicherheitenpreise, des Schuldenwachstums, des Oracle-Verhaltens und der Transaktionsverzögerungen und legen Sie anschließend Handlungsschwellen für Rückzahlung und Entschuldung fest."
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.

# So legen Sie einen DeFi-Liquidationspuffer fest

> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

<a id="answer"></a>

## Direkte Antwort

Ein Liquidationspuffer ist der Abstand zwischen dem gestressten Gesundheitsfaktor einer Kreditposition und der Liquidationsgrenze des Protokolls. Legen Sie ihn fest, indem Sie die gesamte Position unter gleichzeitigen Kursverlusten der Sicherheiten, Kursanstiegen der Schuldtitel, aufgelaufenen Zinsen und einer Verzögerung neu berechnen, die lang genug ist, um eine Rückzahlung onchain auszuführen. Behandeln Sie einen angezeigten Gesundheitsfaktor über `1` nicht als vollständige Risikogrenze.

Verwenden Sie drei Handlungsschwellen statt eines einzigen Alarms in letzter Minute:

- **Zielschwelle:** der Gesundheitsfaktor, der unter normalen Bedingungen wiederhergestellt werden soll und so gewählt ist, dass das definierte Stressszenario noch eine operative Marge lässt.
- **Warnschwelle:** der Punkt, an dem keine weiteren Kredite aufgenommen werden und der Betreiber prüft, ob vorbereitete Rückzahlungsmittel und Gas in der Wallet und auf der Chain, auf der die Schuld besteht, sofort ausgegeben werden können.
- **Verbindliche Entschuldungsschwelle:** ein Wert oberhalb der Liquidationsgrenze des Protokolls, bei dem die Schuld sofort zurückgezahlt wird, ohne sich auf eine Sicherheitenübertragung, Bridge, Börsenabhebung oder eine nach Ermessen erwartete Kurserholung zu verlassen.

Die Schwellen sind positionsspezifisch. Volatilität, Korrelation zwischen Sicherheiten und Schulden, Liquidität, Oracle-Design, Schwankungen der Zinssätze, Protokollparameter und die für eine Transaktion erforderliche Zeit spielen allesamt eine Rolle. Auch in der Dokumentation von Aave heißt es, dass es keinen universell sicheren Gesundheitsfaktor gibt.

<a id="mechanism"></a>

## Funktionsweise

Für eine Position mit mehreren Sicherheiten und Schuldtiteln lautet eine gebräuchliche Form des Gesundheitsfaktors:

`HF = Σ(q_i × P_i × LT_i) ÷ Σ(D_j)`

Dabei ist `q_i` die Menge der Sicherheit, `P_i` der Oracle-Preis des Protokolls, `LT_i` die Liquidationsschwelle dieses Vermögenswerts und `D_j` der Oracle-Wert jeder Schuld einschließlich aufgelaufener Zinsen. Für jede Sicherheit muss ihre eigene Schwelle verwendet werden; die höchste Schwelle darf nicht auf das gesamte Portfolio angewendet werden.

Bei Aave macht ein Gesundheitsfaktor unter `1` eine Position für eine genehmigungsfreie Liquidation verfügbar. Der Liquidator zahlt Schulden zurück und erhält dafür Sicherheiten zuzüglich eines Liquidationsbonus. Die aktuelle Dokumentation von Aave zeigt außerdem, dass der für eine Liquidation infrage kommende Betrag vom Gesundheitsfaktor und von der Positionsgröße abhängt. Andere Protokolle können andere Auslöser, Close-Faktoren, Boni, Isolationsregeln oder Auktionsmechanismen verwenden. Lesen Sie daher die aktuellen Parameter des konkreten Marktes und Deployments.

Bei einer Position mit nur einer Sicherheit und unveränderten Schulden, unveränderter Schwelle und unveränderter Oracle-Beziehung beträgt der Kursrückgang der Sicherheit, der die Position auf `HF = 1` bringen würde:

`d_liq = 1 - 1 ÷ HF_current`

Daher bedeutet `HF_current = 1.20` unter diesen engen Annahmen nur einen Kursrückgang der Sicherheit um `16.67%` bis zur Grenze, nicht `20%`. Die Kurzformel ist ungültig, wenn sich auch der Schuldenpreis, die Zinsen, die Zusammensetzung der Sicherheiten oder die Protokollparameter ändern.

Ermitteln Sie den tatsächlichen Puffer mit einem gestressten Gesundheitsfaktor:

`HF_stress = Σ[q_i × P_i × (1 - s_i) × LT_i] ÷ Σ[D_j × (1 + u_j) × (1 + r_j × t)]`

In dieser Planungsnäherung ist `s_i` der Kursstress der Sicherheit, `u_j` der Kursstress des Schuldtitels, `r_j` die angenommene annualisierte Kreditzinsrate und `t` die Verzögerung in Jahren. Verwenden Sie die tatsächliche Schuldenprojektion des Protokolls, sofern verfügbar; ein veränderlicher Kreditzins und Zinseszins können die einfache Näherung zu optimistisch machen.

<a id="example"></a>

## Beispiel

Angenommen, eine Position hat `10 ETH` als Sicherheit, einen ETH-Oracle-Preis von `$2,000`, eine Liquidationsschwelle von `80%` und `12,000` Einheiten Stablecoin-Schulden zum Preis von `$1`. Ihr aktueller Gesundheitsfaktor beträgt:

`HF_current = (10 × 2,000 × 0.80) ÷ 12,000 = 1.333`

Kombinieren Sie nun drei Stressfaktoren, statt sie einzeln zu testen:

- ETH fällt um `20%`, sodass sein gestresster Oracle-Preis `$1,600` beträgt.
- Der Schuldtitel wird `5%` über seinem Referenzwert gehandelt.
- Die Schuld läuft vor Ausführung der Rückzahlung `30 days` lang zu einem angenommenen Jahreszins von `30%` auf.

Die näherungsweise gestresste Schuld beträgt `12,000 × 1.05 × (1 + 0.30 × 30 ÷ 365) = 12,910.68`. Der um die Schwelle bereinigte Sicherheitenwert beträgt `10 × 1,600 × 0.80 = 12,800`, woraus sich `HF_stress ≈ 0.991` ergibt. Eine Position, die bei `1.333` begann, würde in diesem kombinierten Szenario somit die Liquidationsgrenze überschreiten.

Überführen Sie das Arbeitsblatt in Entscheidungen. Erfassen Sie für jede Sicherheit und jeden Schuldtitel den aktuellen Wert, den gestressten Wert, die Datenquelle und den Aktualisierungszeitpunkt; halten Sie anschließend den genauen Rückzahlungsbetrag fest, der zum Wiederherstellen der Zielschwelle erforderlich ist. Halten Sie diesen Rückzahlungswert und ausreichend native Gas-Token auf der richtigen Chain bereit. Berechnen Sie nach jeder Kreditaufnahme, Abhebung, Änderung der Sicherheiten, Änderung der Governance-Parameter oder wesentlichen Marktbewegung neu.

<a id="risks"></a>

## Risiken

### Preis- und Korrelationsrisiko

Setzen Sie alle Sicherheiten- und Schuldenpositionen gemeinsam unter Stress. Ein Kursrückgang der Sicherheit kann mit einem Aufschlag des Schuldtitels zusammenfallen, und in ruhigen Märkten beobachtete Korrelationen können während eines Abverkaufs zusammenbrechen. Wenden Sie auf wenig gehandelte, gebridgte, gewrappte oder neu eingeführte Vermögenswerte stärkere Schocks an, und nehmen Sie nicht an, dass ein Stablecoin exakt bei `$1` bleibt.

### Oracle- und Parameterrisiko

Für die Liquidation gelten der Preis und die Regeln, die das Protokoll liest, nicht unbedingt der neueste Kurs einer bevorzugten Börse. Oracle-Feeds unterscheiden sich hinsichtlich Quellen, Liquiditätsabdeckung, Aktualisierungsverhalten und Marktrisikokategorie. Die Dokumentation von Chainlink fordert Integratoren auf, Feed-Genauigkeit, Verfügbarkeit, Marktliquidität und Risikokontrollen zu bewerten. Überwachen Sie den tatsächlichen Feed des Protokolls und beziehen Sie Governance-Änderungen an `LT_i`, Obergrenzen, Moduseinstellungen und Liquidationsregeln in den Überprüfungsprozess ein.

### Zins- und Liquiditätsrisiko

Kreditzinsen fallen sofort an und können sich je nach Auslastung und Governance-Parametern ändern. Projizieren Sie die Schuld über das gesamte Reaktionsfenster, nicht nur bis zum nächsten Alarm. Prüfen Sie außerdem, ob die vorgesehene Rückzahlungsmenge bei beeinträchtigter Marktliquidität ohne unvertretbare Slippage beschafft und getauscht werden kann.

### Ausführungsrisiko

Gehen Sie davon aus, dass das normale Frontend, der RPC-Endpunkt oder der Hardware-Wallet-Pfad ausfallen kann. Testen Sie vorab eine alternative Schnittstelle oder eine direkte Protokolltransaktion. Planen Sie einen starken Gaspreisanstieg ein, halten Sie den nativen Gebührentoken außerhalb der Sicherheitenposition und berücksichtigen Sie Nonce-Ersetzung, fehlgeschlagene Genehmigungen, Chain-Überlastung sowie Verzögerungen durch L2-Sequencer oder Bridges. Ein Notfallplan, der mehrere aufeinanderfolgende Übertragungen erfordert, ist kein unmittelbarer Puffer.

### Liquidationsverlust

Eine Liquidation ist keine neutrale Stop-Loss-Order. Der Kreditnehmer gibt durch den Liquidationsbonus Sicherheitenwert ab und kann zusätzlich Protokollgebühren, nachteiligen Preisen und einem veränderten Restportfolio ausgesetzt sein. Ein Close-Faktor kann einen einzelnen Liquidationsaufruf begrenzen, ohne weitere Aufrufe zu verhindern, falls die Position ungesund bleibt.

<a id="misconceptions"></a>

## Häufige Irrtümer

### Mythos 1: `HF = 1.20` bedeutet eine Sicherheitsmarge von `20%`

Im vereinfachten Fall mit nur einer Sicherheit beträgt der Rückgang bis zur Grenze `1 - 1 ÷ 1.20 = 16.67%`. Bei Positionen mit mehreren Vermögenswerten ist die vollständige Stressberechnung erforderlich.

### Mythos 2: Mehr von derselben Sicherheit hinzuzufügen macht die Position immer sicherer

Dadurch steigt der aktuelle Gesundheitsfaktor, zugleich nimmt aber auch das Engagement gegenüber demselben Kursschock zu. Die Rückzahlung von Schulden verringert direkt den Nenner und ist in der Regel die klarere Maßnahme zur Entschuldung im Notfall.

### Mythos 3: Eine Stablecoin-Schuld ist auf `$1` festgelegt

Der Schuldtitel kann über seinem Referenzwert gehandelt werden, während die Kreditzinsen die geschuldete Tokenmenge erhöhen. Beide Effekte verkleinern den Puffer.

### Mythos 4: Alarmzeit ist gleich Handlungszeit

Ein Alarm kann eintreffen, nachdem sich das Oracle bereits bewegt hat, und eine Rückzahlung kann weiterhin Wallet-Zugriff, eine Genehmigung, Blockaufnahme und Finalität erfordern. Die Warnschwelle muss diese Verzögerungen berücksichtigen.

### Mythos 5: Mittel auf einer anderen Chain oder Börse sind verfügbare Liquidität

Abhebungen, Bridges, Ratenbegrenzungen, Wartung und Finalität schaffen Abhängigkeiten. Der Bestand für eine Notfallrückzahlung sollte sich bereits auf der Chain der Schuld und unter der Kontrolle des Kreditnehmers befinden.

<a id="related"></a>

## Verwandte Themen

- [Sicherheitenquote](/de/crypto/collateral-ratio/)
- [Cross-Chain-Bridge](/de/crypto/cross-chain-bridge/)
- [Finalität](/de/crypto/finality/)
- [DeFi-Gesundheitsfaktor](/de/crypto/health-factor-defi/)
- [Liquidationsbonus](/de/crypto/liquidation-bonus/)

<a id="sources"></a>

## Quellen

- [Gesundheitsfaktor und Liquidationen](https://aave.com/help/borrowing/liquidations) - Aave (abgerufen: 2026-08-20)
- [Token leihen](https://aave.com/help/borrowing/borrow-tokens) - Aave (abgerufen: 2026-08-20)
- [Auswahl hochwertiger Datenfeeds](https://docs.chain.link/data-feeds/selecting-data-feeds) - Chainlink (abgerufen: 2026-08-20)

Source: https://wiki.fcontext.com/de/crypto/defi-liquidation-buffer/index.mdx
