Die Welt der dezentralen Finanzen (DeFi) wird oft als digitaler Dschungel bezeichnet – und ehrlicherweise trifft das den Nagel auf den Kopf. Während normale Retail-Trader stundenlang Charts anstarren und versuchen, den nächsten Trend zu erraten, scannen die echten Profis – MEV-Searcher (Maximal Extractable Value) und Liquidations-Bot-Betreiber – direkt die Blockchain, um taktische Fehler eiskalt auszunutzen.
Richtig spannend wird es, wenn ein dicker Fisch (ein „Wal“) gigantische Kredite auf Kreditmärkten wie Aave, Compound, Spark oder Morpho aufnimmt, seine Krypto-Assets als Sicherheit hinterlegt und der Markt sich plötzlich gegen ihn dreht. Wenn so eine Position nur noch Zentimeter von der Zwangsschließung entfernt ist, entsteht eine einzigartige Ineffizienz im Markt, mit der sich extrem viel Geld verdienen lässt.
In diesem Artikel zerlegen wir die Mechanik hinter der Jagd auf solche Positionen. Wir zeigen dir, wie du Wale aufspürst, die nur noch 1 % von der Liquidation entfernt sind, und wie du das Ganze technisch und strategisch maximal profitabel ausnutzt.
Die Anatomie des DeFi-Lending: Warum Liquidationen überhaupt passieren
Um zu verstehen, wo sich die fetten Renditen verstecken, muss man die Mathematik hinter den Lending-Protokollen in- und auswendig kennen. Im Gegensatz zu zentralisierten Börsen (CEX), bei denen die Liquidations-Engine intern von der Plattform selbst betrieben wird, ist dieser Prozess im DeFi-Space komplett an externe Akteure ausgelagert – die sogenannte Liquidatoren.
Ein Protokoll kann eine Position nämlich nicht von alleine schließen; es hat keinen eingebauten, automatischen Trigger. Stattdessen bietet es einen fetten wirtschaftlichen Anreiz (einen Rabatt auf den Kauf der hinterlegten Sicherheit, meistens 5 bis 10 %). Das motiviert jeden fähigen Bot-Betreiber im Netzwerk, die Schulden des Kreditnehmers zu begleichen und sich dessen Sicherheiten zum Schnäppchenpreis unter den Nagel zu reißen.
Die wichtigste Kennzahl: Der Health Factor (HF)
Die Sicherheit jeder Kreditposition wird durch den sogenannten Health Factor (Gesundheitsfaktor) gemessen. Die Formel in den meisten EVM-kompatiblen Protokollen (wie Aave v3) sieht so aus:
Dabei gilt:
- Collateral_i - Der Gesamtwert der Sicherheit i in der Basiswährung (z. B. ETH oder USD).
- LiquidationThreshold_i (Liquidationsschwelle) - Das vom Protokoll festgelegte maximale Verhältnis von Schulden zu Sicherheiten für dieses spezifische Asset (z. B. 85 %).
- Debt_j - Der Gesamtwert des aufgenommenen Kredits j, inklusive aller aufgelaufenen Zinsen.
Der Point of no Return: Solange der HF > 1 ist, ist die Position absolut sicher. Sobald der HF unter 1 fällt, ist die Position zum Abschuss freigegeben und kann von jedem beliebigen Bot öffentlich liquidiert werden.
Was bedeutet „1 % vor der Liquidation“?
Das ist der absolute Alarmzustand einer Position, bei dem sich der HF im haarscharfen Bereich zwischen 1.0001 und 1.01 bewegt. Jede noch so kleine Kursbewegung des besicherten Assets nach unten (oder des geliehenen Assets nach oben) verwandelt diese Position sofort in gefundenes Fressen für die Bots.
Die „Profitieren vom Dump“-Strategie: Zwei Angriffsszenarien
Viele denken, der Gewinn eines Liquidators beschränkt sich nur auf den vom Protokoll gewährten Bonus. Wenn wir aber über Positionen im zweistelligen Millionenbereich sprechen (echte Wale), eröffnen sich im Hintergrund noch viel krassere und profitablere Wege.
Szenario A: Die klassische Liquidation via Flash Loans
Du findest eine Position mit einem HF < 1. Problem: Du hast gerade keine 10.000.000 USD auf der hohen Kante, um die Schulden für den Fremden abzuzahlen. Also nutzt du einen Flash Loan (Blitzkredit):
- Du leihst dir innerhalb einer einzigen Transaktion ohne jegliche Sicherheiten 10 Mio. DAI auf Uniswap oder Aave.
- Mit diesem Geld begleichst du die Schulden des Wals direkt im Protokoll.
- Als Belohnung erhältst du seine hinterlegte Sicherheit (sagen wir ETH) mit 5 % Rabatt (du ziehst also ETH im Wert von 10,5 Mio. USD ab).
- Du verkaufst das ETH sofort auf einer DEX gegen DAI, zahlst die 10 Mio. DAI des Flash Loans + Gebühren zurück.
- Der fette Reingewinn (~490.000 USD abzüglich Gas-Gebühren) wandert direkt in deine Wallet.
Szenario B: Gezielter Short und Markt-Pushing (Whale Hunting)
Das ist die extrem aggressive Variante, die ein tiefes Verständnis von Marktliquidität erfordert:
- Du entdeckst einen Wal, dessen HF bei 1.005 steht (also nur 0,5 % vom Abgrund entfernt). Seine Sicherheit besteht aus 50.000 WBTC und seine Schulden laufen in USDT.
- Du rechnest exakt aus, bei welchem WBTC-Preis sein HF genau auf 1 fällt. Sagen wir, der Kurs muss dafür nur um läppische 150 USD nachgeben.
- Du eröffnest an den Futures-Märkten oder auf einer Derivate-DEX eine fette Short-Position auf WBTC mit ordentlich Hebel.
- Wenn das Orderbuch im Spot-Markt gerade dünn ist (wenig Liquidität), feuerst du (oder andere Marktteilnehmer) eine dicke Verkaufsorder auf dem Spot-Markt ab und triggerst einen sekundenkurzen Flash Crash.
- Der Kurs knallt durch den Liquidations-Trigger. Die Liquidations-Bots (oder dein eigener Script) stürzen sich auf den Wal und liquidieren ihn in Kaskaden. Während dieses Prozesses werden massenhaft WBTC zwangsverkauft, um die Schulden zu decken, was den Kurs noch weiter in den Keller drückt (Wasserfall-Effekt).
- Deine Short-Position schließt sich per Take-Profit genau am absoluten Tiefpunkt dieses künstlich beschleunigten Impulses. Jackpot.
Das Werkzeug-Setup für die Jagd auf „angeschlagene Wale“
Die Blockchain manuell über Etherscan zu durchforsten, ist völlig utopisch. Die Profis kombinieren Tools auf drei verschiedenen Ebenen: Fertige Dashboards, Altyapı-APIs und eigene Parser, die direkt auf ihren Nodes laufen.
1. Ready-to-use Analyseplattformen (Perfekt für den schnellen Start)
- DeFi Saver (Bereich Loan Shifter / Simulation): Genial, um sich die größten offenen Positionen in den Top-Protokollen visuell anzeigen zu lassen.
- Debank / Arkham Intelligence: Das Nonplusultra, um sich Watchlists für ganz bestimmte Adressen anzulegen. Wenn du über die Top-Holder eines Tokens einen riesigen Kreditnehmer findest, hängst du dich mit einem Alert an seine Fersen.
- Dune Analytics: Es gibt unzählige öffentliche Dashboards, die den Health Factor großer Kreditnehmer in Echtzeit aggregieren. (Suchbegriffe: Aave v3 liquidation thresholds, Compound positions monitoring).
2. Spezialisierte APIs (Für die Automatisierung)
Der sauberste Weg, um direkt gefilterte Daten abzugreifen, ohne selbst eine teure Archive Node betreiben zu müssen, ist die Nutzung der offiziellen APIs der Protokolle.
Aave bietet beispielsweise einen offenen GraphQL-Endpoint über The Graph an, mit dem du den Finanzstatus aller Kreditnehmer auf einen Schlag abfragen kannst.
| Parameter | Beschreibung | Warum überwachen? |
|---|---|---|
collateralBalanceUSD | Gesamtwert der Sicherheit in USD | Damit filterst du die echten Wale heraus (alles ab 1 Mio. USD aufwärts). |
totalBorrowsUSD | Gesamtschulden in USD | Wichtig, um zu kalkulieren, wie viel Liquidität du für die Liquidation brauchst. |
currentLiquidationThreshold | Aktuelle Liquidationsschwelle | Zwingend notwendig, um den Point of no Return auf den Dollar genau zu berechnen. |
Praktischer Leitfaden: Wir bauen einen Parser für kritische Positionen
Kommen wir zum Code. Um eine Adresse aufzuspüren, die nur noch 1 % von der Liquidation entfernt ist, schreiben wir ein Skript, das die Smart Contracts (Pool oder DataProvider) des jeweiligen Protokolls abfragt.
Hier ist ein Beispiel-Skript in Python unter Verwendung der web3.py-Bibliothek. Das Skript fragt den Aave Protocol Data Provider Contract auf der Arbitrum-Blockchain ab (beste Wahl für Liquidationen: extrem niedrige Gebühren und ultraschnelle Ausführung), zieht sich die User-Daten und berechnet den genauen Abstand zur Liquidation.
import os
from web3 import Web3
# Verbindung zu einer schnellen RPC-Node (z. B. Alchemy oder QuickNode)
RPC_URL = "https://arb-mainnet.g.alchemy.com/v2/YOUR_API_KEY"
w3 = Web3(Web3.HTTPProvider(RPC_URL))
if not w3.is_connected():
raise Exception("Verbindung zur Blockchain fehlgeschlagen")
# Adresse des Aave v3 Pool Contracts auf Arbitrum
AAVE_POOL_ADDRESS = "0x794a61358D6845594F94dc1DB02A252b5b4814aD"
# Minimales ABI, das nur die Funktion getUserAccountData enthält
AAVE_POOL_ABI = [
{
"inputs": [{"internalType": "address", "name": "user", "type": "address"}],
"name": "getUserAccountData",
"outputs": [
{"internalType": "uint256", "name": "totalCollateralBase", "type": "uint256"},
{"internalType": "uint256", "name": "totalDebtBase", "type": "uint256"},
{"internalType": "uint256", "name": "availableBorrowsBase", "type": "uint256"},
{"internalType": "uint256", "name": "currentLiquidationThreshold", "type": "uint256"},
{"internalType": "uint256", "name": "ltv", "type": "uint256"},
{"internalType": "uint256", "name": "healthFactor", "type": "uint256"}
],
"stateMutability": "view",
"type": "function"
}
]
pool_contract = w3.eth.contract(address=AAVE_POOL_ADDRESS, abi=AAVE_POOL_ABI)
def check_whale_position(user_address):
try:
# Account-Daten direkt aus dem Smart Contract abrufen
data = pool_contract.functions.getUserAccountData(w3.to_checksum_address(user_address)).call()
# Die Daten kommen mit 18 Dezimalstellen (in der Basiswährung von Aave)
collateral = data[0] / 1e8 # Abhängig von der v3-Basiswährung (meistens USD mit 8 Stellen)
debt = data[1] / 1e8
hf = data[5] / 1e18 # Der Health Factor wird mit 18 Dezimalstellen zurückgegeben
# Wir filtern nur die dicken Fische (Sicherheit > 500.000 USD)
if collateral > 500000:
print(f"Adresse: {user_address}")
print(f" Sicherheit: ${collateral:,.2f} | Schulden: ${debt:,.2f}")
print(f" Health Factor: {hf:.4f}")
# Überprüfung, ob die Position in der 1%-Gefahrenzone liegt
# Da die Liquidation bei HF <= 1.0 triggert, liegt die Risikozone zwischen 1.0000 und 1.0100
if 1.0000 < hf <= 1.0100:
print(f"⚠️ ALERT: KRITISCHE POSITION - Wal steht weniger als 1% vor der Liquidation! Dump-Gefahr für die Sicherheit.")
# Hier klinkst du deinen Telegram-Webhook oder den Funktionsaufruf deines Liquidations-Bots ein
print("-" * 50)
except Exception as e:
print(f"Fehler beim Überprüfen der Adresse {user_address}: {e}")
# Testlauf mit einer Zieladresse (durch eine echte Adresse aus deiner Liste ersetzen)
whale_target = "0x..."
check_whale_position(whale_target)Wie fütterst du deine Datenbank mit Adressen?
Das Skript oben prüft erst mal nur eine einzige Adresse. Für einen echten Radar brauchst du einen konstanten Datenstrom. Profi-Bots füttern ihr System wie folgt:
- Parsing historischer Events: Der Bot scannt die Blockchain einmalig ab dem Deployment des Protokolls und zieht alle Adressen heraus, die jemals die Events
Supply,BorrowoderCollateralSwitchausgelöst haben. - Echtzeit-Log-Monitoring: Ein Skript lauscht über WebSockets (
w3.eth.subscribe('logs', ...)) auf neue Blöcke, um jede neue Adresse, die mit den Pools interagiert, sofort abzufangen. Alle eindeutigen Adressen landen direkt in einer lokalen Datenbank (z. B. MariaDB oder PostgreSQL). - Dauerschleifen-Überwachung (Polling): Ein Hintergrund-Worker rattert permanent in Endlosschleife durch die Datenbank, ruft für jedes Profil
getUserAccountDataauf und aktualisiert die Werte.
Anatomie der „Jagd“: So berechnet man den exakten Trigger-Punkt
Um die Position eines „angeschlagenen Wals“ effektiv auszubeuten, reicht es nicht aus, nur den aktuellen Health Factor zu kennen. Ein professioneller Searcher muss die Preisdynamik verstehen. Wir müssen den exakten Preis des besicherten Assets (Collateral) kennen, bei dem die Position zwangsliquidiert wird.
Formalisieren wir die Berechnung. Nehmen wir an, unser Wal hat ein einzelnes Kreditsicherheits-Asset (z. B. ETH) und eine einzige Schuldposition mit stabilem Preis (USDT). Die Liquidationsschwelle (Liquidation Threshold, kurz LT) für ETH im Protokoll liegt bei 85% (0.85).
Die Formel für den kritischen Kollateralpreis Price_crit sieht wie folgt aus:
Praktisches Rechenbeispiel
Stellt euch eine massive Live-Position auf dem Markt vor:
- Sicherheit Collateral_Amount: $10,000\ ETH$
- Aktueller ETH-Preis: $3,400\ USD$
- Wert der Sicherheit in Fiat: $34,000,000\ USD$
- Aktuelle Schuld Debt_USD: $28,500,000\ USDT$
- Liquidationsschwelle LT: 85% (0.85)
Berechnen wir zunächst den aktuellen Health Factor der Position:
Die Position steht haarscharf vor dem Knock-out, nur noch 1.4% von der Liquidation entfernt. Jetzt bestimmen wir den ETH-Preis, bei dem die Position kollabiert:
Sobald der ETH-Preis auf dem Orakel des Protokolls (in der Regel Chainlink) die Marke von $3,352.94 berührt, wird die Position zur Liquidation freigegeben.
Kaum bekannter Insider-Alpha: Smart Contracts haben keine Ahnung vom sekundengenauen Spot-Preis auf Binance. Sie hängen komplett von Orakeln ab. Chainlink-Orakel aktualisieren den On-Chain-Preis entweder zeitgesteuert (z. B. alle 20 Minuten) oder wenn der Off-Chain-Preis um einen bestimmten Prozentsatz abweicht (Deviation Threshold) – zum Beispiel 0.5% oder 1% bei den wichtigsten Paaren. Wer diesen Schwellenwert kennt, kann den exakten Moment des Liquidations-Triggers Sekunden vor der Bestätigung der Orakel-Transaktion im Mempool vorhersehen.
„Whale Hunting“-Strategie in der Praxis: Mechanik der Execution
Wenn das Ziel erfasst und der kritische Preis berechnet ist, hat der Searcher zwei Wege, um Kasse zu machen: den passiven Weg (Vorbereitung auf die Liquidation) oder den aggressiven Weg (Katalysieren des Dumps).
1. Liquiditäts-Engineering (Flash Loans vs. Eigenkapital)
Wenn ihr plant, den Liquidationsbonus abzugreifen (in unserem Beispiel 5% von 34 Mio. $ – das macht brutto schlappe 1.7 Mio. $ Profit), müsst ihr auf Schlag 28.5 Mio. $ auftreiben, um die Schuld zu begleichen.
Da es extrem kapitalineffizient wäre, solche Summen ungenutzt im Wallet liegenzulassen, nutzt man einen Flash Loan über die Liquiditätspools von Uniswap v3 oder Kreditprotokolle wie Aave. Ihr leiht euch die 28.5 Mio. $ innerhalb einer einzigen atomaren Transaktion, ruft die Funktion liquidationCall im Aave-Kontrakt auf, sackt das ETH-Collateral ein und konvertiert einen Teil des ETH sofort über einen Aggregator (1inch / Paraswap) zurück in USDT, um den Flash Loan samt Gebühr (0.05%) zurückzuzahlen. Der Rest des ETH ist euer reiner Nettoprofit.
2. Marktarbitrage und gezielter Short
Wenn die Größe des Wals die Standard-Flash-Loan-Pools sprengt oder die Liquidität auf den Spot-DEXes zu dünn ist, um das Collateral ohne massiven Slippage zu konvertieren, kommt die Frontrunning-Strategie über Derivate ins Spiel:
- Schritt 1: Ihr seht, dass bis zum kritischen Punkt von 3,352.94 nur noch mickrige 15 bis 20 Dollar Kursbewegung fehlen.
- Schritt 2: Auf dezentralen Perpetual-Börsen (Hyperliquid, dYdX, Vertex) oder großen CEXes wird ein aggressiver Short mit hohem Hebel aufgebaut.
- Schritt 3 (Der Katalysator): Auf dem Spotmarkt wird (genau dann, wenn das Orderbuch gerade am dünnsten ist) ein fetter Verkaufsauftrag platziert. Das wird oft von großen Market Makern oder koordinierten Searcher-Gruppen durchgezogen, um einen temporären Price Flush (Dump) zu erzwingen.
- Schritt 4 (Die Kaskade): Sobald der Preis den Trigger durchbricht, fangen Bots weltweit an, die Liquidations-Funktionen zu spammen. Um ihre Gewinne abzusichern, dumpen diese Bots das beschlagnahmte ETH per Market-Order direkt wieder in Stablecoins.
- Schritt 5 (Take Profit): Der massive Verkaufsdruck von 10,000 ETH innerhalb von ein bis zwei Minuten rasiert die lokalen Bids und drückt den Kurs um weitere 2-3% nach unten. Eure Short-Position schließt sich im Take-Profit perfekt am absoluten Boden dieses künstlich beschleunigten Impulses.
Architektur eines Liquidations-Bots: Wie man die Konkurrenz im MEV-Dschungel abhängt
Wenn ihr einen Bot schreiben wollt, der diese Liquidationen selbstständig ausführt, fliegt ihr mit einem Standard-Web3-Skript sofort aus der Kurve. In dieser Nische herrscht ein knallharter Krieg um Millisekunden, bekannt als PGA (Priority Gas Auction) und MEV-Boost-Kämpfe.
Eine normale Transaktion, die in den öffentlichen Mempool geschickt wird, wird von verallgemeinerten Frontrunning-Bots sofort abgefangen. Sie kopieren eure Calldata, setzen die Gas-Gebühr um 1 Gwei höher an und schnappen euch den Profit vor der Nase weg.
Der Tech-Stack eines professionellen MEV-Bots auf Production-Level:
- Programmiersprache: Datenerfassung und Analytik laufen meist über Python/Go. Der ausführende Smart Contract (der den Flash Loan aufnimmt und die Liquidation triggert) wird – zwecks maximaler Gas-Optimierung – strikt in Solidity / Yul geschrieben. In letzter Zeit hat sich Rust (über das Ökosystem der
alloy-Bibliothek) im Backend von Profi-Bots massiv durchgesetzt. - Direktanbindung an Block Builder: Profis meiden den öffentlichen Mempool wie die Pest. Sie senden ihre Transaktionen über private Relays wie Flashbots (MEV-Share / MEV-Boost), BeaverBuild oder Titan. Die Transaktion wird als „Bundle“ direkt an den Validator geschickt. Ihr sagt dem Validator quasi: „Pack meine Transaktion genau hinter die Orakel-Transaktion, die den ETH-Preis drückt, und ich gebe dir 50% meines Liquidationsgewinns als Trinkgeld (Tip) ab.“
Hier ist das logische Ablaufdiagramm für das Zusammenspiel der Bot-Komponenten:
[Blockchain Node / Websocket]
│ (Überwacht neue Blöcke & Mempool-Transaktionen)
▼
[Parser & DB] ────► [Health Factor Calculator]
│ (Triggert, wenn HF <= 1)
▼
[Flashbots / MEV Builder] ──► [Private Validator] ──► [Profit]
Ausführungs-Smart-Contract-Architektur (Solidity)
Damit die Liquidation innerhalb einer einzigen atomaren Transaktion (atomic transaction) erfolgreich durchgeht, muss die gesamte Interaktionslogik mit dem Flash Loan und dem Lending-Protokoll in einem Custom Smart Contract gebündelt werden. Das Absenden einzelner Transaktionen aus einer Wallet (EOA) ist völlig ausgeschlossen – die Konkurrenz würde die Position sofort frontrunnen und die Collateral im selben Atemzug wegschnappen.
Unten findest du ein architektonisches Beispiel für einen Smart Contract in Solidity ^0.8.20, der speziell für die Interaktion mit Aave v3 über den Flash-Loan-Mechanismus optimiert ist.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IPool {
function liquidationCall(
address collateralAsset,
address debtAsset,
address user,
uint256 debtToCover,
bool receiveAToken
) external;
function flashLoanSimple(
address receiverAddress,
address asset,
uint256 amount,
bytes calldata params,
uint16 referralCode
) external;
}
interface IERC20 {
function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address recipient, uint256 amount) external returns (bool);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
}
contract LiquidatorBot {
address public immutable owner;
IPool public immutable aavePool;
modifier onlyOwner() {
require(msg.sender == owner, "Nicht der Owner");
_;
}
constructor(address _pool) {
owner = msg.sender;
aavePool = IPool(_pool);
}
// Struktur zur Uebergabe der Parameter in den Flash-Loan-Callback
struct LiquidationParams {
address collateralAsset;
address debtAsset;
address userToLiquidate;
uint256 debtToCover;
}
// 1. Externer Trigger: Wird von deinem Off-Chain-Backend (Rust/Go/Python) aufgerufen, sobald ein Target gespottet wird
function calmedDownTrigger(
address _collateralAsset,
address _debtAsset,
address _userToLiquidate,
uint256 _debtToCover
) external onlyOwner {
bytes memory params = abi.encode(
LiquidationParams({
collateralAsset: _collateralAsset,
debtAsset: _debtAsset,
userToLiquidate: _userToLiquidate,
debtToCover: _debtToCover
})
);
// Wir fragen den Flash Loan bei Aave exakt fuer das Debt-Volumen des Wals an
aavePool.flashLoanSimple(
address(this),
_debtAsset,
_debtToCover,
params,
0
);
}
// 2. Aave-Callback: Wird innerhalb derselben Transaktion ausgefuehrt, NACHDEM die Funds auf dem Contract-Balance liegen
function executeOperation(
address asset,
uint256 amount,
uint256 premium,
address initiator,
bytes calldata params
) external returns (bool) {
require(msg.sender == address(aavePool), "Ungueltiger Aufrufer");
LiquidationParams memory lParams = abi.decode(params, (LiquidationParams));
// Wir approven den Pool, unsere geliehenen Funds fuer die Liquidation einzuziehen
IERC20(lParams.debtAsset).approve(address(aavePool), lParams.debtToCover);
// Aufruf der eigentlichen Liquidation.
// Der letzte Parameter "false" bedeutet, dass wir die nackte Collateral wollen und nicht deren aToken-Derivat
aavePool.liquidationCall(
lParams.collateralAsset,
lParams.debtAsset,
lParams.userToLiquidate,
lParams.debtToCover,
false
);
// Zu diesem Zeitpunkt liegt die liquidierte Collateral (z. B. ETH) auf der Balance des Contracts
// Aufgabe: Collateral auf einer DEX (Uniswap/1inch) direkt wieder in die Debt-Asset (z. B. USDT) swappen
// Um das Darlehen (amount) + die Flash-Loan-Gebuehr (premium) zu decken
uint256 totalOwed = amount + premium;
// [Hier kommt die Logik fuer den swap()-Aufruf auf dem Uniswap v3 / 1inch Router hin]
// Am Ende muessen wir eine Summe >= totalOwed auf der Balance in der Waehrung debtAsset haben
// Rueckzahlung des Flash Loans approven
IERC20(lParams.debtAsset).approve(address(aavePool), totalOwed);
// Den verbleibenden Nettoprofit an den Contract-Owner senden
uint256 profit = IERC20(lParams.debtAsset).balanceOf(address(this));
if (profit > 0) {
IERC20(lParams.debtAsset).transfer(owner, profit);
}
return true;
}
// Funktion fuer den Notfall-Withdraw jeglicher Token aus dem Contract
function withdrawToken(address _token) external onlyOwner {
uint256 balance = IERC20(_token).balanceOf(address(this));
IERC20(_token).transfer(owner, balance);
}
}Wenig bekannte Feinheiten und Fallstricke (Reines Alpha-Wissen)
Wenn das Ganze so trivial wäre, würde jeder Coder innerhalb einer Woche zum Millionär werden. In der Realität lauern hinter den Kulissen dieser Industrie (dem sogenannten "Dark Forest") knallharte technische Nuancen.
1. Das Problem der „Soft Liquidations“ (Close Factor)
Du kannst die Position eines Wals nicht einfach komplett auf einen Schlag liquidieren, wenn sich deren Volumen im zweistelligen Millionenbereich bewegt. Die meisten modernen Protokolle haben einen festen Close Factor (meistens liegt dieser bei 50 %). Das bedeutet, dass du in einer einzigen Transaktion maximal die Hälfte der ausstehenden Debt des Nutzers tilgen darfst.
Wenn du also einen Wal mit 20.000.000 $ Schulden findest, muss dein Bot eine Transaktion senden, die maximal 10.000.000 $ abdeckt. Der verbleibende Teil der Debt wird neu berechnet, der Health Factor (HF) fängt sich ein Stück weit, und falls die Position danach immer noch in der Risk-Zone liegt, kann sie im darauffolgenden Block erneut liquidiert werden.
2. Systemische Oracle-Lags und „Phantom“-Liquidationen
Große Player lassen ihre Positionen selten ungeschützt. Sie sichern sich oft über automatisierte, dezentrale Keepers (wie das Gelato Network oder Chainlink Automation) ab, die sofort Margin nachschießen, sobald der HF einknickt.
Mehr noch: In Momenten extremer Volatilität (Markt-Crashes) geraten das Ethereum-Mainnet oder L2-Netzwerke (Arbitrum, Base) regelmäßig unter massiven Stau (Gas Spike). Das On-Chain-Oracle hinkt dem echten Preis dann gerne mal um 1–2 Blöcke hinterher. Ein Bot, der sich am Off-Chain-Spotpreis von Derivaten (z. B. auf Binance) orientiert, ballert die Liquidations-Transaktion raus, weil er denkt, der HF sei < 1. Auf Smart-Contract-Ebene läuft das Ganze dann aber in einen REVERT, weil das On-Chain-Oracle den Preis schlicht noch nicht aktualisiert hat. Ergebnis: Du verbrennst einfach nur Gas-Gebühren für nichts.
3. Front-running-Schutz über private RPCs
Wenn dein Bot ein Bundle über Flashbots absendet, konkurrierst du mit anderen Searchern rein über die Gewinnverteilung. Wenn du eine Liquidation mit 10.000 $ Profit findest, dein Konkurrent seinen Bot aber so eingestellt hat, dass er dem Validator 99 % des Profits als Bestechungsgeld (Gas Tip) abgibt, schnappt er dir den Block vor der Nase weg – selbst wenn er am Ende nur 100 $ netto einstreicht. Deine Transaktion wird rejected.
Strategischer Hack: In Netzwerken mit extrem niedrigen Fees und hohem Durchsatz (Base, Arbitrum, Solana) funktionieren klassische Flashbots-Bundles komplett anders oder existieren in der gewohnten Form gar nicht. Dort gewinnt derjenige, der physisch am nächsten an den Validatoren sitzt (niedrigster Netzwerk-Ping zur RPC-Node) und Transaktionen im Dauerfeuer (Spamming) über Custom-gRPC-Verbindungen durchdrücken kann.
Checkliste: Wie man eine Strategie rund um Wal-Liquidationen aufbaut
Wenn du ein eigenes Monitoring-System hochziehen oder Liquidations-Kaskaden manuell bzw. teilautomatisiert traden willst, solltest du dich an folgendem Workflow orientieren:
- Target-Pool aufbauen: Schreibe ein Skript, das die Adressen der Kreditnehmer aus den großen Protokollen (Aave, Compound, Spark, Morpho, Radiant) via Indexer ausliest. Filtere alle Adressen heraus, deren Collateral-Volumen über 1.000.000 $ liegt.
- Trigger-Kalkulator: Entwickle ein Mathe-Modul, das die aktuellen Positionsgewichtungen der beobachteten Wale nimmt und den exakten Floor-Preis der Collateral berechnet, bei dem der HF exakt auf 1,0000 droppt.
- Alert-Integration: Verknüpfe diese kritischen Punkte mit einem Orderbook-Parser der Börsen. Sobald sich der Marktpreis dem Liquidations-Punkt des Wals auf weniger als 1,5 % nähert, muss das System ein High-Priority-Signal ausgeben.
- Monetarisierungs-Vektor wählen:
- Für kapitalstarke Teams: Aktivierung eines echten MEV-Bots, Vorhalten der Flash-Loan-Infrastruktur und Kampf um den Blockspace über private Relays.
- Für Retail-Trader: Eröffnen eines aggressiven Short-Trades auf den Futures-/Perpetual-Märkten, um von dem heftigen Kaskaden-Dump zu profitieren, der genau dann einsetzt, wenn die Bots anfangen, die Collateral des Wals zwangsweise auf den Markt zu schmeißen.
Der Liquidationsmarkt im DeFi-Bereich ist reine Mathematik und reine Execution-Geschwindigkeit. Wer den State der Blockchain lesen und die Berechnung kritischer Punkte automatisieren kann, wird klassischen Chart-Analysten immer fersah-weit voraus sein.
