﻿---
title: "Liquidationsbonus"
description: "Der Liquidationsbonus ist zusätzlicher Sicherheitenwert, der die Liquidation eines unterbesicherten DeFi-Kredits wirtschaftlich macht. Erfahren Sie, wie Anreiz, Aufteilung und Ausführungskosten wirken."
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.

# Liquidationsbonus

> Nur zu Bildungszwecken; keine Anlageberatung. Investitionen können zu Verlusten führen.

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

## Direkte Antwort

Ein Liquidationsbonus ist der zusätzliche Sicherheitenwert, den ein Kreditprotokoll bereitstellt, wenn jemand die Schuld eines liquidierbaren Kreditnehmers tilgt. Er entschädigt den Liquidator für Gas, Slippage, Kursbewegungen, fehlgeschlagene Transaktionen und Wettbewerb. Für den Kreditnehmer ist derselbe Betrag eine Strafe, weil mehr Sicherheitenwert das Konto verlässt als Schuldwert getilgt wird.

Es gibt keinen universellen Satz. Er kann je nach Protokoll, Deployment, Sicherheit, Marktmodus und Governance-Konfiguration abweichen. Aave dokumentiert, dass eine Position liquidierbar wird, sobald ihr Health Factor unter `1` fällt; der Liquidator tilgt Schuld und erhält gleichwertige Sicherheiten plus Bonus. Eine erlaubnisfreie Transaktion ist nicht automatisch profitabel.

Der ausgewiesene Bonus ist kein Nettogewinn. Das Protokoll kann einen Teil einbehalten, und der Liquidator trägt Ausführungs- und Finanzierungskosten. Manche Systeme nutzen außerdem eine andere Architektur. Compound III verwendet zunächst Protokollreserven, um ein Unterwasserkonto zu absorbieren, und bietet die vom Protokoll gehaltenen Sicherheiten später vergünstigt an. Der Aufrufer von `absorb` erhält nicht einfach in derselben Transaktion die Sicherheiten des Kreditnehmers.

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

## Funktionsweise

In einem vereinfachten Modell mit direkter Beschlagnahme steht `D` für den getilgten Schuldwert, `b` für den Bonussatz und `C` für den Sicherheitenwert, der zu den Oracle-Preisen des Protokolls entnommen wird:

`C = D * (1 + b)`

Der Bruttobonus beträgt `D * b`. Ist `f` der an das Protokoll fließende Anteil, lautet die vereinfachte Aufteilung:

`liquidator collateral value = D + D * b * (1 - f)`

`protocol collateral value = D * b * f`

Das sind Lehrformeln, keine Transaktionsangebote. Token-Dezimalstellen, Rundung, Oracle-Einheiten, Close-Factor-Grenzen, verfügbare Sicherheiten und protokollspezifische Regeln beeinflussen die echten Beträge. Der Aave-V3-Code berechnet etwa die Basissicherheit aus Oracle-Preisen, wendet den konfigurierten Bonus an und kann aus dem Bonusanteil eine konfigurierte Protokollgebühr an die Treasury abziehen.

Der Anreiz muss zwei Verluste ausgleichen. Ist er zu klein, decken erwartete Erlöse möglicherweise Gas, Slippage, ungünstige Kursbewegungen oder erfolglose Gebote nicht; riskante Schuld bleibt dann offen. Ist er zu groß, verlieren Kreditnehmer mehr Sicherheiten, und ein Oracle-Kurssprung verbraucht den Solvenzpuffer schneller. Governance konfiguriert Liquidationsparameter daher meist gemeinsam mit Sicherheitenfaktoren, Schwellenwerten, Close Factors und Oracle-Design.

Protokollbegriffe sind nicht austauschbar. Compound v2 nennt seinen Multiplikator Liquidationsanreiz und kann einen Beschlagnahmeanteil den Reserven zuführen. Compound III trennt `absorb` und `buyCollateral`: Reserven begleichen zunächst das Konto, das Protokoll übernimmt die Sicherheiten, und Käufer können diesen Bestand später bei passenden Reservebedingungen vergünstigt erwerben. Maßgeblich sind stets die Regeln und Live-Konfiguration des konkreten Marktes.

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

## Rechenbeispiel

Ein Markt mit direkter Beschlagnahme erlaube die Tilgung von `1,000` USDC bei `b = 5%`. Zu Oracle-Preisen verliert der Kreditnehmer Sicherheiten im Wert von `1,050` USDC. Fließen `f = 10%` des Bonus ans Protokoll, werden die brutto `50` USDC in `45` USDC für den Liquidator und `5` USDC für das Protokoll aufgeteilt.

Der Liquidator erhält somit für `1,000` USDC Tilgung Sicherheiten im Wert von `1,045` USDC. Kosten Gas und Prioritätsgebühren `12` USDC und verursacht der Verkauf `8` USDC Slippage und Gebühren, beträgt das vereinfachte Nettoergebnis `25` USDC:

`net result = 45 - 12 - 8 = 25`

Das Beispiel unterstellt eine erfolgreiche Ausführung zu erwarteten Oracle- und Marktpreisen. Erfolglose Gebote, Finanzierung, Kursbewegungen vor dem Verkauf, Transferbeschränkungen und Steuern fehlen. Ein nominaler Bonus von `5%` garantiert daher weder `5%` Rendite noch den Anteil, den der Liquidator behält.

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

## Risiken

- **Oracle- und Kurslückenrisiko:** Sicherheiten werden zum akzeptierten Protokollpreis berechnet, doch der realisierbare Marktpreis kann sich vor dem Verkauf ändern.
- **Ausführungs- und MEV-Risiko:** Konkurrenten können höher bieten oder eine Transaktion vorziehen. Fehlgeschlagene Versuche verbrauchen Gas; privater Orderflow und Auktionen können Überschüsse umleiten.
- **Liquiditätsrisiko:** Bei dünnem Handel, Limits, gebrückten oder pausierten Assets und Transferhürden kann der Bonus kleiner als die Slippage sein.
- **Parameterrisiko:** Governance oder befugte Risikomanager können Bonus, Gebühren, Schwellen und Close-Factor-Regeln ändern. Oberflächen können der On-Chain-Konfiguration hinterherhinken.
- **Ausfallrisiko:** Ein Bonus schafft keine Sicherheiten. Kurslücken, veraltete Oracles, Überlastung oder Unterdeckung können ein Defizit hinterlassen.
- **Verlust des Kreditnehmers:** Eine finalisierte Liquidation ist irreversibel und kann mehr Sicherheiten als getilgte Schuld entnehmen. Nach einer Teilliquidation droht eine weitere.

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

## Häufige Missverständnisse

### Mythos 1: Der Bonus ist kostenlos vom Protokoll erzeugte Rendite

Er wird aus den Sicherheiten des Kreditnehmers bezahlt. Er vergütet eine riskante, umkämpfte Ausführung und ist kein Zins ohne Zahlenden.

### Mythos 2: Ein ausgewiesener Bonus von `5%` garantiert `5%` Gewinn

Protokollgebühren, Gas, Prioritätsgebühren, Slippage, Hedging, Finanzierung, Fehlversuche und Kursbewegungen mindern das Ergebnis. Entscheidend ist der realisierbare Verkaufswert, nicht nur der Oracle-Wert.

### Mythos 3: Ein größerer Bonus macht den Markt immer sicherer

Er kann die Ausführung verbessern, erhöht aber auch Kreditnehmerverlust und Sicherheitenverbrauch je getilgter Schuldeinheit. Sicherheit entsteht aus Oracle-Qualität, Liquidität, Schwellen, Close Factors, Transaktionskapazität und Kalibrierung zusammen.

### Mythos 4: Jeder Liquidator erhält Sicherheiten direkt

Das gilt für manche Protokolle, darunter den grundlegenden Aave-Ablauf, aber nicht für alle. Compound III kann die Position absorbieren und Sicherheiten separat verkaufen; Auslöser und späterer Käufer müssen nicht dieselbe Adresse sein.

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

## Verwandte Themen

- [DeFi Health Factor](/de/crypto/health-factor-defi/)
- [Liquidation](/de/crypto/liquidation/)
- [DeFi-Liquidationspuffer](/de/crypto/defi-liquidation-buffer/)
- [Veralteter Oracle-Preis](/de/crypto/oracle-price-staleness/)
- [MEV](/de/crypto/mev/)

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

## Quellen

- [Health Factor & Liquidations](https://aave.com/help/borrowing/liquidations) - Aave (abgerufen: 2026-08-21)
- [Aave V3 LiquidationLogic.sol](https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/libraries/logic/LiquidationLogic.sol) - Aave (abgerufen: 2026-08-21)
- [Compound v2 Docs: Comptroller](https://docs.compound.finance/v2/comptroller/) - Compound Finance (abgerufen: 2026-08-21)
- [Compound III Docs: Liquidation](https://docs.compound.finance/liquidation/) - Compound Finance (abgerufen: 2026-08-21)

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