Liquidationen on-chain: Die Mechanik von Aave und Compound und das Bot-Geschäft dahinter

Eine Liquidation bei Aave ist ein stehendes öffentliches Angebot: Begleiche die Schuld eines anderen und erhalte dessen Sicherheiten mit einem Abschlag von 5–15%. Das Angebot ist in einen unveränderlichen Vertrag geschrieben, erfordert keine Erlaubnis, kein KYC, keine Beziehung zum Protokoll — man muss nur die erste Adresse sein, die liquidationCall() in dem Block aufruft, in dem eine Position die Grenze überschreitet. Es ist das reinste Rennen in der Krypto-Welt: Der Preis ist auf den Cent genau bekannt, der Auslöser ist (größtenteils) vorhersehbar, und die einzige Frage ist, ob die eigene Infrastruktur vor allen anderen dort ankommt.

Dieser Artikel seziert die Maschine von Anfang bis Ende: die genaue Mathematik, die definiert, wann eine Position liquidierbar wird, warum die Chainlink-Oracle-Mechanik Liquidationen vorhersehbar statt reaktiv macht, woraus ein wettbewerbsfähiger Liquidationsbot tatsächlich besteht, und warum sich die Ökonomie des Rennens so weit verdichtet hat, dass mittlerweile der größte Teil des Bonus an Block-Builder abfließt — und zunehmend zurück an die Protokolle selbst. Am Ende stellen wir dem Ganzen die Liquidationen auf Perp-DEXs (GMX, Hyperliquid) gegenüber, die oberflächlich ähnlich aussehen, aber ein vollkommen anderes Spiel sind.

Die Mechanik: Health Factor, Schwellenwerte, Boni

LTV vs. Liquidationsschwelle

Jeder Sicherheiten-Asset bei Aave v3 trägt zwei unterschiedliche Risikoparameter, und sie zu verwechseln ist der häufigste Fehler, den Kreditnehmer machen:

• LTV (Loan-to-Value) — der Höchstbetrag, den man bei Eröffnung gegen den Asset leihen kann. Für WETH auf Aave v3 Mainnet liegt dieser bei etwa 80%.
• Liquidationsschwelle — die Besicherungshöhe, ab der eine Position liquidierbar wird. Für WETH liegt sie bei etwa 83%.

Der Abstand zwischen beiden ist ein bewusster Puffer: Man kann keine Position eröffnen, die sofort liquidierbar wäre. Doch der Puffer ist dünn — wenige Prozent ungünstiger Kursbewegung trennen "maximal beliehen" von "zum Abholen freigegeben."

Der Health Factor fasst alles in einer Zahl zusammen:

$HF = \frac{\sum_i C_i \cdot P_i \cdot LT_i}{\sum_j D_j \cdot P_j}$

wobei $C_i$ die Menge des Sicherheiten-Assets $i$ ist, $P_i$ dessen Oracle-Preis, $LT_i$ dessen Liquidationsschwelle, und $D_j \cdot P_j$ der Wert jeder Schuldposition. Wenn $HF < 1$, darf jeder liquidieren. Es gibt keine Karenzzeit, keinen Margin Call, keine Benachrichtigung. Die Bedingung wird träge ausgewertet — nichts geschieht, bis jemand die Funktion aufruft.

Close Factor und Liquidationsbonus

Zwei weitere Parameter definieren, was der Liquidator erhält:

• Close Factor — der Anteil der Schuld, den eine einzelne Liquidation begleichen darf. Der Standardwert bei Aave v3 liegt bei 50%. Seit Aave v3.3 springt der Close Factor auf 100%, wenn $HF < 0,95$ (der CLOSE_FACTOR_HF_THRESHOLD), oder wenn die Sicherheit oder Schuld der Position unter einem Staubschwellenwert liegt (~2.000 $) — kleine Positionen sind zwei Transaktionen nicht wert, und übrig gebliebener Staub erzeugt Buchungsprobleme mit uneinbringlichen Forderungen.
• Liquidationsbonus (auch Liquidationsstrafe genannt, je nachdem, auf wessen Seite man steht) — der Abschlag, zu dem der Liquidator die Sicherheiten kauft. Bei Aave ist das ein fester Spread, der pro Asset von der Governance festgelegt wird: etwa 5% für WETH und große Stablecoins, bis zu 10–15% für volatile Long-Tail-Sicherheiten.

Compound v2 funktioniert nach demselben Prinzip mit anderen Konstanten: liquidateBorrow() mit einem Close Factor von 50% und einem Liquidationsanreiz von 8% (die eingezogene cToken-Sicherheit ist das 1,08-Fache der zurückgezahlten Schuld wert). Compound v3 (Comet) hat den Ablauf in zwei Schritte umgestaltet: absorb() zieht die unterbesicherte Position auf die eigene Bilanz des Protokolls (die Schuld wird in die Reserven sozialisiert, die Sicherheit wird Protokolleigentum), und buyCollateral() erlaubt es jedem, diese Sicherheit vom Protokoll mit einem von der Governance festgelegten Abschlag zu kaufen, bezahlt im Basis-Asset. In der Praxis ruft ein Liquidator beides in einer Transaktion auf — absorb selbst zahlt nichts aus, der Gewinn liegt vollständig im rabattierten buyCollateral.

Eine konkrete Position, Schritt für Schritt liquidiert

Nehmen wir repräsentative Aave-v3-WETH-Parameter: LTV 80%, Liquidationsschwelle 83%, Liquidationsbonus 5%.

Ausgangslage. Man hinterlegt 10 WETH zu 3.000 $(30.000$ Sicherheit) und leiht sich 20.000 USDC.

$HF = \frac{30{,}000 \times 0.83}{20{,}000} = 1.245$

Liquidationspreis. $HF = 1$, wenn der Sicherheitswert auf 20{,}000 / 0.83 = 24.096\$$ fällt, also ETH bei **2.410 ** — ein Rückgang von 19,7%. Fühlt sich sicher an. Ist es aber nicht, denn ETH frühstückt 20%-Rückgänge geradezu.

Der Absturz. ETH notiert im Oracle bei 2.350 $. Die Sicherheit beträgt nun 23.500$:

$HF = \frac{23{,}500 \times 0.83}{20{,}000} = 0.975$

$0.95 < HF < 1$, also greift der Close Factor von 50%. Ein Liquidator begleicht 10.000 USDC der Schuld und zieht Sicherheiten im Wert von $10{,}000 \times 1.05 = 10.500$$ zum Oracle-Preis ein:

$\frac{10{,}500}{2{,}350} = 4.468 \text{ WETH}$

Die Gewinn- und Verlustrechnung des Liquidators. Er hat 10.000 $ausgegeben und 10.500$ in ETH erhalten: 500 $ Bruttogewinn für einen einzigen Funktionsaufruf, vor Gas, Swap-Kosten für den Ausstieg aus ETH und — entscheidend — vor allem, was er bieten musste, um das Rennen zu gewinnen (dazu weiter unten mehr).

Ihre Gewinn- und Verlustrechnung. Schuld reduziert auf 10.000 $, Sicherheit reduziert auf 5,532 WETH (13.000$). Neuer Health Factor:

$HF = \frac{13{,}000 \times 0.83}{10{,}000} = 1.079$

Zwei unbequeme Tatsachen sind zu beachten. Erstens: Man hat 500 $ für das Privileg des erzwungenen Deleveraging bezahlt — der Bonus kommt vollständig aus dem eigenen Eigenkapital. Zweitens: Der neue HF von 1,079 liegt nur knapp über Wasser: Ein weiterer Rückgang von ETH um 7% löst die Liquidation der verbleibenden Hälfte erneut aus. Liquidation mit festem Spread stellt Solvenz wieder her, nicht Sicherheit. Dieses Muster "halbe Liquidation, immer noch fragil, erneut liquidiert" ist die Mikrostruktur hinter den Kaskadendynamiken, die wir im Schwesterartikel über Liquidationskaskaden als Handelssignal behandeln.

Der Auslöser: Liquidationen sind vorhersehbar, nicht reaktiv

Hier liegt der Teil, der Menschen, die dieses Geschäft verstehen, von denen unterscheidet, die es nicht tun: Bei Aave und Compound werden Positionen nicht liquidierbar, wenn sich der Marktpreis bewegt. Sie werden liquidierbar, wenn das Oracle aktualisiert wird.

Beide Protokolle beziehen Preise aus Chainlink Data Feeds. Ein Chainlink-Feed auf dem Ethereum-Mainnet pusht einen neuen On-Chain-Preis, wenn eine von zwei Bedingungen eintritt:

• Abweichungsschwelle — der off-chain aggregierte Preis weicht um mehr als einen festgelegten Prozentsatz vom letzten On-Chain-Wert ab: 0,5% für ETH/USD auf dem Mainnet, 1–2% für die meisten kleineren Feeds.
• Heartbeat — ein maximales Intervall (3.600 Sekunden für ETH/USD), nach dem ein Update unabhängig von der Abweichung gepusht wird.

Das hat eine tiefgreifende Konsequenz. Zwischen den Updates ist der On-Chain-Preis konstruktionsbedingt veraltet. Wenn der ETH-Preis auf Binance um 0,6% fällt, während der On-Chain-Feed noch den alten Preis anzeigt, weiß jeder versierte Akteur, dass eine Oracle-Update-Transaktion kommt, weiß (ungefähr), welchen Wert der neue Preis haben wird, und kann — bevor das Update eintrifft — genau berechnen, welche Positionen in dem Moment $HF < 1$ unterschreiten werden.

Die dominante Strategie ist daher nicht "Health Factors beobachten und reagieren", sondern das Oracle-Update backrunnen: ein Bundle konstruieren, in dem der eigene liquidationCall() unmittelbar nach der Chainlink-Transmit-Transaktion im selben Block ausgeführt wird. Das Oracle-Update ist der Startschuss, und jeder kann sehen, wie der Starter die Pistole hebt. Die Bundle-Mechanik — private Übermittlung an Block-Builder, atomare Reihenfolgegarantien — ist dieselbe Maschinerie, die wir im Artikel über Sandwich-Angriffe und Mempool-Frontrunning behandelt haben; Liquidationen sind schlicht die legitimste Anwendung davon.

Zwei Feinheiten sind in der Praxis wichtig:

1. Man muss den Transmit nicht einmal im Mempool sehen. Da die Off-Chain-Aggregation beobachtbar ist (man kann dieselbe Preisberechnung aus CEX-Feeds nachvollziehen), kann man vorhersagen, dass ein Update ausgelöst werden muss, sobald die Abweichung die Schwelle überschreitet, und Bundles im Voraus sowohl für den Preispfad nach oben als auch nach unten vorbereiten.
2. Heartbeat-Updates sind geplante Liquiditätsereignisse. Wenn ein Feed innerhalb einer Stunde nicht um 0,5% abgewichen ist, kommt trotzdem ein Update — und wenn sich der Preis um 0,4% gegen eine Wand von Positionen verschoben hat, die sich um $HF = 1$ häufen, ist dieses "harmlose" Heartbeat der Auslöser. Wettbewerbsfähige Betreiber verfolgen die Zeit seit dem letzten Update pro Feed als erstklassiges Signal.

Diese Vorhersehbarkeit ist auch der Grund, warum die Protokolle irgendwann dazu übergingen, den Wert zurückzugewinnen. Im März 2025 integrierte Aave Chainlink SVR (Smart Value Recapture): Oracle-Updates für teilnehmende Feeds werden über Flashbots MEV-Share geleitet, das Recht, sie zu backrunnen, wird versteigert, und das Gewinnergebot wird zwischen der Aave DAO (65%) und Chainlink (35%) aufgeteilt, statt vollständig an Searcher und Builder abzufließen. Innerhalb weniger Monate hatte das System über 32 Mio. $an Liquidationen verarbeitet und über 1,1 Mio.$ zurückgewonnen und dabei über 80% des berechtigten Liquidations-MEV eingefangen. Das lässt sich als Marktpreis lesen: Das offene Rennen war so effizient geworden, dass das Protokoll die Ziellinie versteigern konnte.

Den Bot bauen: die vier Teilsysteme

Ein wettbewerbsfähiger Liquidationsbot ist kein Skript; er ist eine Infrastruktur im Umfang einer kleinen Trading-Firma. Vier Teilsysteme, jedes für sich einfach, in der Summe alle latenzkritisch.

1. Positionsindexierung

Man braucht die vollständige Menge aller Kreditnehmer und deren Salden, in Echtzeit gepflegt. Der Bootstrap ist ein Event-Backfill — jedes Supply, Borrow, Repay, Withdraw, LiquidationCall seit dem Protokoll-Deployment — zusammengefasst zu aktuellen Salden pro Nutzer und danach live gehalten über ein Websocket-Abonnement neuer Logs. Aaves getUserAccountData(address) liefert den Health Factor direkt, aber ihn pro Nutzer und pro Block für über 100.000 Kreditnehmer aufzurufen, ist aussichtslos; ernsthafte Betreiber replizieren die Buchhaltung des Protokolls lokal (einschließlich der Zinsindex-Mathematik, da die Schuld sich jede Sekunde vergrößert) und reservieren RPC-Aufrufe für die Verifikation.

2. Health-Factor-Überwachung mit Oracle-Simulation

Die Kernschleife lautet nicht "HF zu aktuellen Oracle-Preisen berechnen." Sondern: "HF zu dem Preis berechnen, den das Oracle gleich veröffentlichen wird":

def liquidatable_at(positions, feed, candidate_price):
    """Positions that cross HF < 1 if `feed` updates to candidate_price."""
    out = []
    for pos in positions.borrowers_exposed_to(feed):
        hf = pos.health_factor(price_override={feed: candidate_price})
        if hf < 1.0:
            close_factor = 1.0 if hf < 0.95 else 0.5
            repay = pos.debt_value * close_factor
            seized = repay * (1 + pos.liq_bonus)
            gross = seized - repay          # the prize, pre-costs
            out.append((pos, repay, gross))
    return sorted(out, key=lambda x: -x[2])

deviation = abs(offchain_px - onchain_px) / onchain_px
if deviation > FEED_DEVIATION_THRESHOLD * 0.8:   # update imminent
    targets = liquidatable_at(positions, feed, offchain_px)
    for pos, repay, gross in targets:
        prepare_bundle(pos, repay, max_bid=gross - costs(pos))

Positionen nach ihrer Nähe zu $HF = 1$ zu sortieren (eine Prioritätswarteschlange, geordnet nach dem Preis, der jede Position auslösen würde), hält die heiße Menge klein. Der Faktor 0.8 ist das ganze Spiel: Man will Bundles gebaut und übermittelt haben, bevor das Update sicher ist, nicht danach.

3. Über Flash Loans finanzierte Ausführung

Man braucht kein Kapital, um zu liquidieren — man braucht es für etwa 200 Millisekunden Blockzeit. Der kanonische Ausführungsvertrag tut Folgendes, atomar:

1. Den Schuld-Asset per Flash Loan leihen (Balancer bei 0 bps, oder Aave selbst bei ~5 bps — dasselbe Primitiv, das wir in atomarer Arbitrage mit Flash Loans aufgebaut haben).
2. liquidationCall(collateral, debtAsset, user, repayAmount, false) aufrufen — das false erhält das zugrunde liegende Asset statt aTokens.
3. Die eingezogene Sicherheit auf der Venue mit der besten Notierung zurück in den Schuld-Asset tauschen (Uniswap v3 / v4, 1inch-Route oder ein privater Fill).
4. Den Flash Loan zurückzahlen; der Rest ist Gewinn, verifiziert mit einem require(profit >= minProfit), damit eine veraltete Simulation lieber revertiert, statt mit Verlust auszuführen.

Das Swap-Bein ist der Punkt, an dem schlampige Bots sterben: 10.500 $ eines Long-Tail-Tokens einzuziehen bedeutet, dessen DEX-Liquidität aufzuzehren, und der Preiseinfluss beim Ausstieg kann den Liquidationsbonus übersteigen. Wettbewerbsfähige Betreiber simulieren die gesamte Hin- und Rückfahrt — einschließlich des Ausstiegs-Swaps — und überspringen Liquidationen, bei denen das Netto negativ ist, oder halten die Sicherheit und hedgen sie über einen Perp, statt sie am Markt abzuladen.

4. Bundle-Übermittlung

Die finale Transaktion kommt dem öffentlichen Mempool nicht nahe. Sie wird als Bundle an Block-Builder übermittelt (oder in die SVR/OEV-Auktion, wo diese zutrifft) mit der Aussage: "Platziere meine Liquidation unmittelbar nach diesem Oracle-Transmit; hier ist mein Trinkgeld." Das Trinkgeld ist das eigene Gebot in einer Alles-oder-nichts-Auktion gegen jeden anderen Bot, der dieselbe Simulation gefahren hat. Womit wir bei der unbequemen Ökonomie ankommen.

Der Wettbewerb: wohin der Bonus tatsächlich fließt

Die akademische Basislinie ist Qin, Zhou, Gamito, Jovanovic und Gervais, "An Empirical Study of DeFi Liquidations: Incentives, Risks, and Instabilities" (2021), die das Geschäft über Aave, Compound, MakerDAO und dYdX von April 2019 bis April 2021 vermaßen: 28.138 Liquidationen mit einem Gesamtvolumen von 807 Mio. $, bei einem aggregierten Liquidator-Gewinn von 63,6 Mio.$. Das Papier dokumentierte auch die strukturelle Ineffizienz der Liquidation mit festem Spread — der Abschlag ist ein stumpfes Instrument, das Kreditnehmer regelmäßig stärker bestraft, als es eine Auktion tun würde — und zeigte, dass Liquidatoren mit naiven Strategien messbares Geld auf dem Tisch liegen ließen.

Die Gewinne jener Ära werden sich nicht wiederholen, aus drei sich verstärkenden Gründen:

Aus der Gasauktion wurde eine Builder-Auktion. In 2019–2020 konkurrierten Liquidatoren in Priority-Gas-Auktionen im offenen Mempool; der Gewinner überzahlte Gas, die Verlierer scheiterten, und ein nennenswerter Anteil des Bonus verblieb beim Liquidator. Nach MEV-Boost findet der Wettbewerb in versiegelten Builder-Auktionen statt. Wenn N Bots dieselbe deterministische Gelegenheit auf dieselbe Gewinnzahl hin simulieren, konvergiert das Bieten in Richtung des vollen Preises: Das gewinnende Bundle gibt regelmäßig 90%+ des Bruttogewinns als Trinkgeld an Builder/Validator ab. Der Vorteil des Liquidators schrumpft auf denjenigen, der marginal bessere Ausstiegspreise, marginal geringere Kosten oder von anderen übersehene Gelegenheiten hat.

Oracle-Backruns dominieren, und sie werden eingezäunt. Da fast alle Geldmarkt-Liquidationen durch Oracle-Updates ausgelöst werden, ist der profitable Strategieraum auf einen einzigen Punkt kollabiert: den Slot direkt nach dem Transmit gewinnen. SVR-artige Mechanismen formalisieren das — das Protokoll versteigert diesen Slot und behält den größten Teil des Erlöses. Der Anteil des Searchers schrumpft von "Bonus minus Gas" auf "die Marge des Auktionsgewinners", die der Wettbewerb um Gebote gegen null treibt.

Der Long Tail ist, was übrig bleibt. Die realistischen Nischen für einen Neueinsteiger im Jahr 2026: Chains und L2s, auf denen Builder-Märkte noch unreif sind; Long-Tail-Lending-Forks mit falsch bepreisten Bonusparametern und wenigen konkurrierenden Bots; Positionen mit exotischen Sicherheiten, bei denen die Simulation des Ausstiegs-Swaps wirklich schwer ist (Vorsprung durch bessere Ausführung, nicht durch bessere Latenz); und Stressereignisse, wenn Gaspreise explodieren und RPC-Ausfälle die Grenzbetreiber aus dem Rennen werfen — MakerDAOs Black Thursday (März 2020), als Nullgebot-Auktionen Liquidatoren erlaubten, 8,3 Mio. $ an Sicherheiten praktisch umsonst zu beanspruchen, weil sonst niemandes Infrastruktur funktionierte, bleibt das kanonische Beispiel dafür, dass das Rennen genau dann am besten zahlt, wenn es am schwersten zu betreiben ist.

Um die ehrliche Erwartung zu beziffern: Das ist inzwischen ein Geschäft mit echten Fixkosten (Nodes, Builder-Beziehungen, Monitoring über ein Dutzend Deployments hinweg), das um einen stark rabattierten Preispool konkurriert. Es ist ein guter Weg, mehr über EVM-Interna, Oracles und MEV-Infrastruktur zu lernen, als jeder Kurs vermitteln kann. Es ist ein harter Weg, seinen Lebensunterhalt zu verdienen.

Perp-DEX-Liquidationen: gleiches Wort, anderes Spiel

Auch Perpetual DEXs "liquidieren", und die Schlagzeilenzahlen sind größer — aber der Mechanismus, und damit die Gelegenheit, ist strukturell verschieden.

GMX (v2): Positionen handeln gegen einen Liquiditätspool zu Oracle-Preisen (Chainlink Low-Latency Data Streams). Die Liquidation wird ausgelöst, wenn Sicherheit minus Verluste und Gebühren unter die Maintenance-Anforderungen fällt, und sie wird von Keepern ausgeführt — dedizierter Infrastruktur, die auf Oracle-signierten Preisen operiert, kein offenes Rennen. Es gibt keine öffentliche Funktion, die 5% Bonus an denjenigen zahlt, der zuerst ruft; verbleibende Sicherheit fließt gemäß Protokollregeln an den Pool. Aus Sicht eines Searchers gibt es nichts zu gewinnen.

Hyperliquid: Liquidationen laufen innerhalb der Matching-Engine der eigenen L1. Wenn das Konto-Eigenkapital unter die Erhaltungsmarge fällt (bewertet zu einem Mark-Preis, der aus CEX-Feeds und dem Orderbuch gemischt wird, genau um den oben beschriebenen Oracle-Spielen zu widerstehen), sendet die Engine Liquidations-Marktorders in das Orderbuch — große Positionen in Teilblöcken, um den Impact zu begrenzen. Fällt das Eigenkapital weiter unter zwei Drittel der Erhaltungsmarge, wird die Position von einem Backstop-Liquidator-Vault, der eine Strategie innerhalb von HLP ist, dem gemeinschaftlich getragenen Market-Making-Vault des Protokolls, zum Mark-Preis übernommen, mit Auto-Deleveraging als letzter Schicht. Die Liquidations-Gewinn-und-Verlust-Rechnung fließt an die HLP-Einleger — der "Liquidator-Gewinn" wird in einen Vault sozialisiert, dem jeder beitreten kann, statt pro Ereignis erkämpft zu werden.

Die Konsequenz für einen Trader: Auf Geldmärkten besteht das Spiel darin, der Liquidator zu sein — ein Infrastrukturrennen um einen festen Spread. Auf Perp-DEXs ist die Rolle des Liquidators geschlossen, sodass sich das Spiel hin zum Handeln rund um Liquidationen verschiebt: Liquidationspreise lassen sich aus offenen Positionen berechnen, erzwungener Flow trifft auf ein sichtbares Orderbuch, und geballte Liquidationsniveaus werden sowohl zum Magneten als auch zur Treibstoffquelle für Preisbewegungen. Das ist dieselbe Logik, die CEX-Liquidationskaskaden handelbar macht — die Dynamik, die wir in Funding Rates killen deinen Hebel (Hebelkosten sind das, was Positionen zur Klippe treibt) und in der Pump-and-Dump-Mechanik bei Shitcoins (konstruierte Pushs in Liquidations-Cluster hinein) gestreift haben. Die vollständige Behandlung von Kaskaden als Signal — ihr Entstehen erkennen, ihren Treibstoff messen, das Overshoot handeln — ist Thema des nächsten Artikels dieser Serie.

Was man mitnehmen sollte

Geldmarkt-Liquidation ist die seltene Ecke der Krypto-Welt, in der alles lesbar ist: Die Auslösebedingung ist eine Formel, der Preis ist eine von der Governance festgelegte Konstante, der Startschuss ist eine Oracle-Transaktion, die man kommen sieht. Diese Lesbarkeit hat 2019–2021 ein wirklich offenes Geschäft aufgebaut, und dann — genau weil alles lesbar war — hat der Wettbewerb den Vorteil auf Infrastrukturqualität heruntergepreist und den Rest zurück an die Protokolle versteigert. Die Mechanik bleibt essenzielles Wissen: Wer on-chain leiht, für den ist diese Mathematik das eigene Risikomodell; wer rund um erzwungenen Flow handelt, dem sagen Oracle-Kadenz und Close Factors, wann und wie viel; und wer den Bot trotzdem baut, sollte ihn zumindest im Wissen darum bauen, wohin das Geld tatsächlich fließt.