--- title: "DeFi-Gesundheitsfaktor" description: "Der DeFi-Gesundheitsfaktor vergleicht die um die Liquidationsschwelle bereinigten Sicherheiten mit den Schulden. Erfahren Sie, wie die Formel funktioniert, was den Wert verändert und warum der Sicherheitspuffer protokollspezifisch ist." 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. # DeFi-Gesundheitsfaktor > Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen. ## Direkte Antwort Der DeFi-Gesundheitsfaktor misst auf Kontoebene, in welchem Umfang die um Liquidationsschwellen bereinigten Sicherheiten die aktuellen Schulden decken. Im Modell von Aave bedeutet ein Wert über `1`, dass die Position noch nicht liquidierbar ist, während sie bei einem Wert unter `1` liquidiert werden kann. Ein Wert nahe `1` lässt nur wenig Spielraum für nachteilige Preisbewegungen oder weiter anfallende Zinsen. Die Kennzahl ist weder ein universeller Bonitätsscore noch eine Verlustgarantie. Definition, Preise, Parameter, Rundung und Liquidationsverfahren gehören zu einer bestimmten Protokollbereitstellung. Compound III prüft beispielsweise anhand von Liquidations-Sicherheitenfaktoren, ob ein Konto negative Liquidität aufweist, und verwendet ein `absorb`-Verfahren, statt die Aave-Formel als universellen Standard darzustellen. Beleihungsquote und Liquidationsschwelle sind ebenfalls verschieden. Die LTV begrenzt die anfängliche Kreditaufnahmekapazität; die Liquidationsschwelle bestimmt, wann eine bestehende Position liquidierbar wird. Der Abstand zwischen beiden ist ein vom Protokoll festgelegter Puffer und kein frei verfügbares Guthaben des Kreditnehmers. ## Funktionsweise Für eine Aave-ähnliche Position mit Sicherheitenwerten `i` und Schuldtiteln `j` lautet die Lehrformel: `health factor = sum(collateral_i value * liquidation threshold_i) / sum(debt_j value)` Dies entspricht `total collateral value * weighted average liquidation threshold / total debt value`. Jeder Vermögenswert muss mit dem vom Protokoll akzeptierten Oracle-Preis, den korrekten Einheiten und seinem Status als aktivierte Sicherheit bewertet werden. Bereitgestellte, aber nicht aktivierte Sicherheiten oder Vermögenswerte, die im betreffenden Markt oder Modus nicht zugelassen sind, können unberücksichtigt bleiben. Der Zähler sinkt, wenn Sicherheitenpreise fallen, Sicherheiten entnommen werden oder ein Vermögenswert nicht länger als Sicherheit zählt. Der Nenner steigt, wenn Schuldzinsen anfallen, weitere Schulden aufgenommen werden oder ein geliehener Vermögenswert gegenüber der Bewertungseinheit aufwertet. Eine Schuldentilgung oder das Hinzufügen zugelassener Sicherheiten erhöht den Gesundheitsfaktor normalerweise, doch das genaue Ergebnis hängt von der Transaktionsausführung und den aktuellen Parametern ab. Prüfen Sie vor einer Handlung aufgrund des angezeigten Werts die Chain und den Markt, das Konto, die Oracle-Bewertung, die aktivierten Sicherheiten, die Schulden einschließlich aufgelaufener Zinsen, die vermögenswertspezifischen Schwellen, den Effizienz- oder Isolationsmodus sowie anstehende Governance- oder Risikoparameteränderungen. Ein Wallet oder Dashboard kann dem Onchain-Zustand hinterherhinken. ## Rechenbeispiel Angenommen, eine Position umfasst zugelassene ETH-Sicherheiten von `$10,000`, eine Liquidationsschwelle von `80%` und Schulden von `$6,000`. Der Gesundheitsfaktor beträgt: `$10,000 * 80% / $6,000 = 1.333` - Fällt der Sicherheitenwert um `20%` auf `$8,000`, während Schulden und Parameter unverändert bleiben, sinkt der Gesundheitsfaktor auf `$8,000 * 80% / $6,000 = 1.067`. - Bei Sicherheiten von `$7,500` beträgt der Gesundheitsfaktor genau `1`. Unter diesen vereinfachten Annahmen führt jeder weitere Rückgang zu einem Wert unter `1`. - Steigen die Schulden bei einem unveränderten Sicherheitenwert von `$10,000`, wird dieselbe Schwelle bei Schulden von `$8,000` erreicht. Das Beispiel lässt den Zeitpunkt von Oracle-Aktualisierungen, Zinsen zwischen Beobachtung und Ausführung, Gebühren, Modusbeschränkungen, Parameteränderungen und die Transaktionsreihenfolge außer Betracht. Eine reale Liquidation kann teilweise oder vollständig erfolgen und je nach Regeln des bereitgestellten Protokolls einen Liquidationsbonus oder eine Strafe übertragen. ## Risiken - **Kein universell sicherer Wert:** Ein für stark korrelierte Vermögenswerte geeigneter Puffer kann für volatile oder schwach korrelierte Sicherheiten und Schulden unzureichend sein. - **Oracle- und Marktlückenrisiko:** Das Protokoll verwendet sein konfiguriertes Oracle und nicht zwingend den auf einer Börse sichtbaren Preis. Preissprünge und verzögerte Transaktionen können die Schwelle überschreiten, bevor ein Nutzer reagieren kann. - **Anwachsende und neu bewertete Schulden:** Zinsen erhöhen die Schulden im Zeitverlauf, und ein nicht stabiler geliehener Vermögenswert kann aufwerten, selbst wenn die Sicherheit nicht fällt. - **Parameter- und Modusrisiko:** Governance oder befugte Risikomanager können Schwellen, Obergrenzen, Zulässigkeit oder Moduseinstellungen ändern. Der Wechsel eines Kontos zwischen Modi kann die Berechnung verändern. - **Liquidationsverlust:** Bei der Liquidation können Sicherheiten mit einem Bonus oder Abschlag zugunsten des Liquidators eingezogen werden, Gebühren oder Slippage entstehen und dem Kreditnehmer weniger Sicherheiten verbleiben, auch wenn das Restkonto wieder gesund ist. - **Ausführungs- und Automatisierungsrisiko:** Überlastung, fehlgeschlagene Transaktionen, unzureichendes Gas, Frontend-Ausfälle und fehlerhafte automatische Tilgungs- oder Nachschusssysteme können eine geplante Rettung verhindern. ## Häufige Missverständnisse ### Mythos 1: Ein Gesundheitsfaktor von `1.5` bedeutet, dass die Sicherheit um `50%` fallen kann Wenn sich nur der bereinigte Sicherheitenwert verändert und die Schulden konstant bleiben, beträgt der vereinfachte Rückgang bis zur Schwelle `1 - 1 / health factor`. Bei `1.5` sind das ungefähr `33.3%` und nicht `50%`. Mehrere Vermögenswerte, eine Neubewertung der Schulden, Zinsen, Schwellen und das Oracle-Verhalten können das Ergebnis verändern. ### Mythos 2: Jeder Wert über `1` ist sicher Über `1` bedeutet lediglich, dass die Position nach der aktuellen Berechnung dieses Protokolls nicht liquidierbar ist; daraus folgt kein universeller Sicherheitspuffer. Eine schnelle Marktbewegung, Oracle-Aktualisierung, Zinsanrechnung oder Transaktionsverzögerung kann einen knappen Puffer aufzehren. ### Mythos 3: Die Angebotsrendite gleicht die Kreditzinsen im Gesundheitsfaktor aus Bei manchen Konstruktionen kann die Rendite den Saldo eines bereitgestellten Tokens erhöhen, doch der Gesundheitsfaktor verwendet die aktuelle Sicherheiten- und Schuldenbuchführung des Protokolls. Die angezeigte Netto-APY ersetzt nicht die Solvenzberechnung, und Anreizprämien zählen möglicherweise überhaupt nicht als Sicherheit. ### Mythos 4: Jedes Kreditprotokoll verwendet dieselbe Formel und denselben Liquidationsablauf Aave dokumentiert eine Gesundheitsfaktorquote und eine genehmigungsfreie Liquidation unterhalb seiner Schwelle. Compound III ermittelt dagegen negative Liquidität anhand von Liquidations-Sicherheitenfaktoren und erlaubt einer Adresse den Aufruf von `absorb`, wodurch Schulden und Sicherheiten über die Protokollreserven übertragen werden. Maßgeblich sind stets die Regeln des bereitgestellten Protokolls. ## Verwandte Themen - [Sicherheitenquote](/de/crypto/collateral-ratio/) - [Liquidation](/de/crypto/liquidation/) - [Liquidationsbonus](/de/crypto/liquidation-bonus/) - [Veralteter Oracle-Preis](/de/crypto/oracle-price-staleness/) - [DeFi-Zinsmodell](/de/crypto/defi-interest-rate-model/) ## 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) - [Compound-III-Dokumentation: Liquidation](https://docs.compound.finance/liquidation/) - Compound Finance (abgerufen: 2026-08-20) Source: https://wiki.fcontext.com/de/crypto/health-factor-defi/index.mdx