Naciśnij ESC, aby zamknąć

Boty MEV: Jak polować na likwidacje wielorybów?

Świat zdecentralizowanych finansów (DeFi) bywa często nazywany cyfrową dżunglą i umówmy się – to określenie trafia w samo sedno. Podczas gdy ulica ślęczy nad wykresami i próbuje wywróżyć, w którą stronę pójdzie trend, grube ryby — MEV searcherzy (Maximal Extractable Value) oraz operatorzy botów likwidacyjnych — prześwietlają sam blockchain, polując na potknięcia taktyczne innych graczy.

Kiedy grubas (tzw. wieloryb) bierze potężną pożyczkę pod zastaw swoich krypto na platformie lendingowej (takiej jak Aave, Compound, Spark czy Morpho), a rynek nagle obraca się przeciwko niemu, zaczyna się nerwówka. Gdy jego pozycja balansuje na krawędzi przymusowego zamknięcia, na rynku tworzy się potężna nieefektywność, którą aż żal zostawić nietkniętą.

W tym artykule rozbijemy na czynniki pierwsze całą mechanikę tropienia takich pozycji. Wyjaśnimy, jak namierzyć wielorybów, którym brakuje zaledwie 1% do odcięcia prądu, oraz jak czysto technicznie i strategicznie przekuć to w konkretny zarobek.

Anatomia lendingu w DeFi: Dlaczego dochodzi do likwidacji?

Żeby w ogóle wiedzieć, gdzie szukać słabych punktów, trzeba mieć w małym palcu matematykę stojącą za protokołami pożyczkowymi (Lending Protocols). W przeciwieństwie do giełd scentralizowanych (CEX), gdzie za likwidację odpowiada wewnętrzny silnik samej giełdy, w DeFi ten proces jest w pełni zoutsourcingowany do zewnętrznych podmiotów — likwidatorów.

Protokół nie potrafi sam z siebie zamknąć pozycji, bo nie ma zaszytego żadnego automatycznego zapalnika. Zamiast tego kusi zachętą ekonomiczną (zniżką na wykup zabezpieczenia, zazwyczaj rzędu 5–10%). Chodzi o to, by ktokolwiek z sieci przyszedł, spłacił dług pożyczkobiorcy i zgarnął jego zabezpieczenie dla siebie.

Kluczowy wskaźnik: Health Factor (HF)

Bezpieczeństwo każdej otwartej pozycji pożyczkowej mierzy się tak zwanym Współczynnikiem Zdrowia (Health Factor). W większości protokołów kompatybilnych z EVM (np. Aave v3) wzór prezentuje się następująco:

1
 

Gdzie:

  • Collateral_i - wartość zabezpieczenia i w walucie bazowej (np. w ETH lub USD).
  • LiquidationThreshold_i (Próg likwidacji) - maksymalny stosunek długu do zabezpieczenia określony przez protokół dla danego aktywa (np. 85%).
  • Debt_j - łączna wartość zaciągniętej pożyczki j wraz z naliczonymi odsetkami.

Punkt krytyczny: Dopóki HF > 1, pozycja jest bezpieczna. W momencie gdy HF spada poniżej 1, pozycja zostaje wystawiona na żer i każdy może ją publicznie zlikwidować.

Co to znaczy: „1% od likwidacji”?

To stan, w którym HF danej pozycji balansuje na ostrzu noża w przedziale od 1.0001 do 1.01. Jakikolwiek minimalny ruch ceny zabezpieczenia w dół (lub pożyczonego aktywa w górę) w ułamku sekundy zamienia tę pozycję w darmowy obiad dla botów.

Strategia „Zarabianie na dumpie”: Dwa scenariusze

Wielu osobom wydaje się, że zarobek likwidatora ogranicza się wyłącznie do zgarnięcia bonusu od samego protokołu. Jednak gdy w grę wchodzą pozycje idące w dziesiątki milionów dolarów (należące do wielorybów), otwierają się przed nami znacznie ciekawsze i o wiele bardziej dochodowe opcje.

Scenariusz A: Klasyczna likwidacja przez Flash Loans

Namierzasz pozycję z HF < 1. Nie masz w kieszeni luźnych 10 000 000 USD, żeby spłacić czyjeś zobowiązania, więc odpalasz pożyczkę błyskawiczną (Flash Loan):

  1. Bierzesz 10 mln DAI z Uniswap/Aave w ramach jednej i tej samej transakcji, bez żadnego zastawu.
  2. Spłacasz dług wieloryba bezpośrednio w protokole.
  3. Odbierasz jego zabezpieczenie (np. ETH) z 5-procentowym rabatem (czyli zgarniasz ETH o wartości 10.5 mln USD).
  4. Błyskawicznie sypiesz to ETH na DEX-ie, oddajesz 10 mln DAI + prowizję za flash loan.
  5. Czysty zysk (~490 000 USD po odliczeniu kosztów gazu) zostaje u Ciebie.

Scenariusz B: Kierunkowy short i „popychanie kostek domina” (Whale Hunting)

To znacznie bardziej agresywne i zaawansowane zagranie, wymagające świetnego zrozumienia płynności rynkowej:

  1. Wypatrujesz wieloryba, którego HF wynosi 1.005 (czyli 1% od przepaści). Jego zabezpieczeniem jest WBTC o wartości 50 000 USD, a dług ma w USDT.
  2. Przeliczasz matematycznie, przy jakiej cenie WBTC jego HF zleci do poziomu 1. Załóżmy, że kurs musi spaść o zaledwie 150 USD.
  3. Otwierasz potężnego shorta z dźwignią na WBTC na rynku kontraktów futures lub na DEX-ie.
  4. Jeśli na rynku brakuje akurat lokalnej płynności (cienki arkusz zleceń), Ty lub inni gracze robicie mocny zrzut WBTC na rynku spot, wywołując chwilową szpilkę w dół (dump).
  5. Cena uderza w zapalnik likwidacyjny. Boty likwidacyjne (albo Twój własny skrypt) rzucają się do kaskadowego czyszczenia pozycji wieloryba. Podczas likwidacji ogromny wolumen WBTC jest z automatu wywalany na rynek w celu pokrycia długu, co wywołuje jeszcze potężniejsze tąpnięcie (efekt domina).
  6. Twój short zamyka się idealnie na take-proficie na samym dnie tego sztucznie wywołanego lub przyspieszonego zjazdu.

Narzędzia do tropienia „rannych wielorybów”

Ręczne przeklikiwanie blockchainu na Etherscanie to przepis na porażkę. Profesjonaliści korzystają z trzech poziomów narzędzi: gotowych dashboardów, infrastrukturalnych API oraz autorskich parserów podpiętych pod nody.

1. Gotowe platformy analityczne (Na dobry start)

  • DeFi Saver (zakładka Loan Shifter / Simulation): Pozwala wygodnie zwizualizować potężne pozycje w czołowych protokołach.
  • Debank / Arkham Intelligence: Służą do budowania watchlist konkretnych adresów. Gdy namierzysz grubego pożyczkobiorcę na liście top holderów danego tokena, możesz wrzucić go na radar i ustawić powiadomienia.
  • Dune Analytics: W sieci znajdziesz publiczne dashboardy, które agregują Health Factor dużych graczy w czasie rzeczywistym (szukaj po tagach: Aave v3 liquidation thresholds, Compound positions monitoring).

2. Specjalistyczne API (Do automatyzacji)

Najbardziej niezawodnym sposobem na pozyskiwanie odfiltrowanych danych — bez konieczności stawiania własnej nody archiwalnej — jest podpięcie się pod oficjalne API danych podsystemów.

Przykładowo, Aave udostępnia otwarty endpoint GraphQL (The Graph), z którego można wyciągnąć kondycję portfela każdego pożyczkobiorcy.

ParametrOpisPo co to śledzić?
collateralBalanceUSDŁączna wartość zabezpieczenia w USDOdsiewanie wielorybów (od 1 mln USD w górę)
totalBorrowsUSDŁączny dług w USDSzacowanie płynności potrzebnej do zamknięcia pozycji
currentLiquidationThresholdAktualny próg likwidacjiNiezbędny do precyzyjnego wyliczenia punktu bez powrotu

Przewodnik praktyczny: Piszemy parser pozycji krytycznych

Przejdźmy do konkretów i kodu. Żeby wyłapać adres, któremu brakuje 1% do likwidacji, musimy napisać skrypt odpytujący smart kontrakt Pool lub DataProvider danego protokołu.

Poniżej znajdziesz przykład skryptu w Pythonie z wykorzystaniem biblioteki web3.py. Ten kod uderza do kontraktu Aave Protocol Data Provider na sieci Arbitrum (gdzie opłaty są groszowe, a czas realizacji błyskawiczny, co przy likwidacjach ma kluczowe znaczenie), pobiera dane użytkownika i liczy, jak blisko krawędzi się znajduje.

import os
from web3 import Web3
# Inicjalizujemy połączenie z szybką nodą RPC (np. Alchemy lub 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("Nie udało się połączyć z blockchainem")
# Adres kontraktu Aave v3 Pool na sieci Arbitrum
AAVE_POOL_ADDRESS = "0x794a61358D6845594F94dc1DB02A252b5b4814aD"
# Minimalne ABI, zawierające wyłącznie funkcję getUserAccountData
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:
        # Pobieramy dane konta bezpośrednio ze smart kontraktu
        data = pool_contract.functions.getUserAccountData(w3.to_checksum_address(user_address)).call()
        
        # Dane są zwracane z dokładnością do 18 miejsc (w walucie bazowej Aave)
        collateral = data[0] / 1e8  # Zależnie od waluty bazowej v3 (zazwyczaj USD z 8 miejscami po przecinku)
        debt = data[1] / 1e8
        hf = data[5] / 1e18 # Health Factor zwracany jest z 18 miejscami po przecinku
        
        # Filtrujemy tylko grube ryby (zabezpieczenie > 500 000 USD)
        if collateral > 500000:
            print(f"Adres: {user_address}")
            print(f"  Zabezpieczenie: ${collateral:,.2f} | Dług: ${debt:,.2f}")
            print(f"  Health Factor: {hf:.4f}")
            
            # Sprawdzamy, czy pozycja weszła w strefę 1% do likwidacji
            # Jako że likwidacja odpala się przy HF <= 1.0, strefa ryzyka to od 1.0000 do 1.0100
            if 1.0000 < hf <= 1.0100:
                print(f"⚠️ STATUS KRYTYCZNY: Wieloryb 1% od likwidacji! Możliwy zrzut zabezpieczenia.")
                # W tym miejscu podpinasz swój trigger alertu na Telegramie albo wywołanie bota likwidacyjnego
            print("-" * 50)
            
    except Exception as e:
        print(f"Błąd podczas sprawdzania adresu {user_address}: {e}")
# Przykład sprawdzenia konkretnego adresu wieloryba (podmień na realny adres ze swojej listy)
whale_target = "0x..." 
check_whale_position(whale_target)

Skąd brać adresy do masowego sprawdzania?

Powyższy skrypt weryfikuje tylko jeden konkretny adres. Żeby postawić pełnoprawny radar, potrzebujesz stałego dopływu danych. Profesjonalne boty pozyskują je w następujący sposób:

  • Parsowanie zdarzeń historycznych (Events): Bot jednorazowo przeczesuje blockchain od momentu wdrożenia (deployu) protokołu i wyciąga wszystkie adresy, które wywołały zdarzenia takie jak Supply, Borrow czy CollateralSwitch.
  • Subskrypcja logów na żywo: Skrypt nasłuchuje nowych bloków przez WebSockets (w3.eth.subscribe('logs', ...)), wyłapując w locie świeże adresy wchodzące w interakcję z poolem. Każdy unikalny adres trafia od razu do lokalnej bazy danych (np. MariaDB/PostgreSQL).
  • Monitorowanie w pętli: Proces robotnika (worker) kręci się bez przerwy po bazie danych, odpytując o getUserAccountData dla każdego zarejestrowanego adresu po kolei.

Anatomia „Polowania”: Jak obliczyć dokładny punkt zapalny

Aby skutecznie rozegrać „rannwgo wieloryba”, sama wiedza o jego aktualnym Health Factorze nie wystarczy. Profesjonalny searcher musi czuć dynamikę zmian cenowych. Musimy namierzyć dokładną cenę aktywa zabezpieczającego (collateralu), przy której pozycja pójdzie pod nóż.

Sformalizujmy te obliczenia. Załóżmy, że nasz wieloryb ma jedno zabezpieczenie (np. ETH) i jeden dług w stabilnej monecie (USDT). Próg likwidacji (Liquidation Threshold, w skrócie LT) dla ETH w tym protokole wynosi 85% (0.85).

Wzór na krytyczną cenę zabezpieczenia Price_crit wygląda następująco:

Formula for the critical price of collateral
 

Praktyczny przykład kalkulacji

Wyobraźcie sobie potężną pozycję na rynku:

  • Wielkość zabezpieczenia Collateral_Amount: $10,000\ ETH$
  • Aktualna cena ETH: $3,400\ USD$
  • Wartość zabezpieczenia w ficie: $34,000,000\ USD$
  • Aktualny dług Debt_USD: $28,500,000\ USDT$
  • Próg likwidacji LT: 85% (0.85)

Obliczmy obecny Współczynnik Zdrowia (Health Factor) tej pozycji:

position-health-factor
 

Pozycja znajduje się zaledwie 1.4% od krawędzi. Teraz określmy cenę ETH, przy której wszystko runie:

The ETH price at which the position will collapse
 

Gdy tylko cena ETH na wyroczni protokołu (najczęściej to Chainlink) dotknie poziomu $3,352.94, pozycja z miejsca kwalifikuje się do likwidacji.

Mało znany insider alfa: Smart kontrakty nie mają zielonego pojęcia o cenie rynkowej na Binance w danej milisekundzie. Wiszą na wyroczniach. Oracle Chainlinka aktualizują cenę na blockchainie albo czasowo (np. co 20 minut), albo przy odchyleniu ceny poza siecią (Deviation Threshold) o konkretny procent — na przykład 0.5% lub 1% dla głównych par. Znając ten próg, doświadczeni gracze są w stanie przewidzieć dokładny moment „odpalenia” likwidacji na sekundy przed tym, jak transakcja wyroczni w ogóle potwierdzi się w mempoolu.

Strategia „Whale Hunting” w praktyce: Mechanika egzekucji

Gdy cel jest namierzony, a cena krytyczna rozpisana, searcher ma dwie ścieżki na monetyzację: pasywną (przygotowanie pod likwidację) i agresywną (ściągnięcie ceny w dół).

1. Inżynieria kapitałowa (Flash Loans vs. Własny kapitał)

Jeśli planujesz zgarnąć bonus likwidacyjny (w naszym przykładzie 5% z $34 mln daje okrągłe $1.7 mln zysku brutto), musisz skądś wytrzasnąć $28.5 mln na spłatę długu.

Trzymanie takiego siana na porzuconym portfelu to totalna nieefektywność kapitałowa, dlatego odpala się Flash Loan (pożyczkę błyskawiczną) z puli płynności Uniswap v3 lub lenderów typu Aave. Bierzesz $28.5 mln długu w obrębie jednej, atomowej transakcji, wywołujesz funkcję liquidationCall w kontrakcie Aave, zgarniasz ETH i natychmiast przerzucasz część tego ETH z powrotem do USDT przez agregator płynności (1inch / Paraswap), żeby oddać flash loana wraz z prowizją (0.05%). Reszta ETH to Twój czysty, nieskażony zysk.

2. Arbitraż rynkowy i celowany short

Gdy gabaryty wieloryba przerastają standardowe pule flash loanów albo płynność na DEX-ach spot jest zbyt płytka, by przełknąć konwersję zabezpieczenia bez potężnego poślizgu cenowego (Slippage), do gry wchodzi frontrunning na derywatach:

  1. Krok 1: Widzisz, że do punktu krytycznego 3,352.94 zostało marne 15-20 dolarów ruchu cenowego.
  2. Krok 2: Na zdecentralizowanych giełdach futures (Hyperliquid, dYdX, Vertex) albo na CEX-ach otwierasz agresywnego shorta z grubą dźwignią.
  3. Krok 3 (Katalizator): Na rynku spot (tam, gdzie arkusz zleceń jest w danym momencie najchudszy) wjeżdża potężne zlecenie sprzedaży aktywa. Często robią to grubi market makerzy albo zorganizowane grupy searcherów, prowokując chwilową szpilę w dół (dump).
  4. Krok 4 (Kaskada): Jak tylko cena przebije trigger, boty z całego świata zaczynają masowo bombardować sieć funkcjami likwidacyjnymi. Żeby zablokować zysk, boty te z miejsca dumpują przejęte zabezpieczenie (ETH) rynkowymi zleceniami z powrotem do stajniaków (stablecoinów).
  5. Krok 5 (Żniwa): Nagły rzut 10,000 ETH na sprzedaż w oknie minuty-dwóch całkowicie czyści lokalne bidy, ściągając cenę o kolejne 2-3% w dół. Twój short zamyka się na Take-Proficie idealnie w dnie tego sztucznie napędzonego impulsu.

Architektura bota likwidacyjnego: Jak wyprzedzić drapieżników

Jeśli porwiesz się na napisanie bota, który ma samodzielnie domykać takie transakcje, zwykły skrypt Web3 zostanie zmieciony z planszy. W tej niszy trwa krwawa wojna na prędkość, znana jako PGA (Priority Gas Auction) oraz walka na dopalacze MEV.

Zwykła transakcja puszczona w publiczny mempool zostanie momentalnie wyłapana przez uogólnione boty frontrunujące. Skopiują Twój calldata, podbiją gas price o 1 gwei wyżej i sprzątną Ci zysk sprzed nosa.

Produkcyjny stack technologiczny bota MEV:

  • Język programowania: Zbieranie danych i analityka to zazwyczaj Python/Go. Smart kontrakt wykonawczy (ten, który przyjmuje flash loan i odpala likwidację) — bezwzględnie Solidity / Yul (maksymalna optymalizacja pod gas). Ostatnio w backendach botów ostro dominuje Rust (ekosystem biblioteki alloy).
  • Bezpośrednie wpięcie do Block Builderów: Profesjonaliści omijają publiczny mempool szerokim łukiem. Ślą paczki przez prywatne przekaźniki (Relays), takie jak Flashbots (MEV-Share / MEV-Boost), BeaverBuild czy Titan. Transakcja leci jako „bundle” prosto do walidatora. Mówisz walidatorowi: „Wsadź moją transakcję dokładnie po transakcji wyroczni, która zrzuca cenę ETH, a w zamian sypnę Ci 50% mojego zysku z likwidacji jako napiwek (tip)”.

Poniżej znajduje się schemat logiczny pokazujący, jak współpracują ze sobą komponenty takiego bota:

[Blockchain Node / Websocket] 
       │ (Słucha nowych bloków i mempoola)
       ▼
[Parser & DB] ────► [Health Factor Calculator] 
                         │ (Jeśli HF <= 1)
                         ▼
                  [Flashbots / MEV Builder] ──► [Private Validator] ──► [Profit]

Architektura inteligentnego kontraktu wykonawczego (Solidity)

Aby likwidacja zakończyła się sukcesem w ramach jednej, niepodzielnej transakcji atomowej, cała logika interakcji z Flash Loanem i protokołem pożyczkowym musi być zapakowana w dedykowany smart contract. Puszczenie osobnych transakcji bezpośrednio z portfela (EOA) nie wchodzi w grę – boty konkurencji zrobią Ci front-run i zgarną zabezpieczenie w ułamku sekundy.

Poniżej znajduje się gotowy na produkcję, architektoniczny przykład smart contractu w Solidity ^0.8.20, zoptymalizowany pod kątem interakcji z Aave v3 przy użyciu mechanizmu Flash Loan.

// 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, "Not an owner");
        _;
    }
    constructor(address _pool) {
        owner = msg.sender;
        aavePool = IPool(_pool);
    }
    // Struktura do przekazywania parametrów do callbacku flash loanu
    struct LiquidationParams {
        address collateralAsset;
        address debtAsset;
        address userToLiquidate;
        uint256 debtToCover;
    }
    // 1. Zewnętrzny trigger: wywoływany przez Twój backend (w Rust/Go/Pythonie) po wykryciu celu
    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
            })
        );
        // Wnioskujemy o flash loan w Aave pod konkretną wartość długu wieloryba
        aavePool.flashLoanSimple(
            address(this),
            _debtAsset,
            _debtToCover,
            params,
            0
        );
    }
    // 2. Callback od Aave: wywoływany wewnątrz tej samej transakcji PO otrzymaniu środków na balans kontraktu
    function executeOperation(
        address asset,
        uint256 amount,
        uint256 premium,
        address initiator,
        bytes calldata params
    ) external returns (bool) {
        require(msg.sender == address(aavePool), "Invalid caller");
        
        LiquidationParams memory lParams = abi.decode(params, (LiquidationParams));
        // Pozwalamy puli na pobranie naszych pożyczonych środków w celu przeprowadzenia likwidacji
        IERC20(lParams.debtAsset).approve(address(aavePool), lParams.debtToCover);
        // Wywołujemy właściwą likwidację. 
        // Ostatni parametr false oznacza, że chcemy otrzymać czysty token zabezpieczenia, a nie jego pochodną aToken
        aavePool.liquidationCall(
            lParams.collateralAsset,
            lParams.debtAsset,
            lParams.userToLiquidate,
            lParams.debtToCover,
            false
        );
        // Na tym etapie na balansie kontraktu leży przejęte zabezpieczenie (np. ETH)
        // Zadanie: Sfechować (swapnąć) zabezpieczenie na DEX (Uniswap/1inch) z powrotem do waluty długu (np. USDT)
        // Aby pokryć kapitał pożyczki (amount) + prowizję za flash loan (premium)
        
        uint256 totalOwed = amount + premium;
        
        // [Tutaj wrzucasz logikę wywołania swap() na Uniswap v3 / 1inch Router]
        // Na wyjściu musimy mieć sumę >= totalOwed na balansie w walucie debtAsset
        
        // Zatwierdzamy zwrot flash loanu
        IERC20(lParams.debtAsset).approve(address(aavePool), totalOwed);
        // Zgarniamy czysty zysk (resztówkę) na portfel właściciela kontraktu
        uint256 profit = IERC20(lParams.debtAsset).balanceOf(address(this));
        if (profit > 0) {
            IERC20(lParams.debtAsset).transfer(owner, profit);
        }
        return true;
    }
    // Funkcja do awaryjnego wyciągania jakichkolwiek tokenów utkniętych na kontrakcie
    function withdrawToken(address _token) external onlyOwner {
        uint256 balance = IERC20(_token).balanceOf(address(this));
        IERC20(_token).transfer(owner, balance);
    }
}

Mało znane niuanse i pułapki (Czysta Alpha)

Gdyby wszystko było tak banalne, każdy programista pisałby boty i zostawał milionerem w tydzień. W rzeczywistości za kulisami tego biznesu w "ciemnym lesie" (Dark Forest) kryją się brutalne przeszkody techniczne.

1. Problem „Miękkich likwidacji” (Close Factor)

Nie możesz zlikwidować całej pozycji wieloryba za jednym zamachem, jeśli jego dług idzie w dziesiątki milionów dolarów. Większość współczesnych protokołów ma na sztywno wdrożony parametr Close Factor (zazwyczaj ustawiony na 50%). Oznacza to, że w pojedynczej transakcji możesz spłacić maksymalnie połowę długu użytkownika.

Jeśli namierzysz wieloryba z długiem rzędu $20,000,000, Twój bot musi wysłać transakcję pokrywającą maksymalnie $10,000,000. Reszta długu jest przeliczana na nowo, Health Factor delikatnie się poprawia i jeśli pozycja nadal jest pod kreską, możesz ją dobijać kolejną likwidacją w następnym bloku.

2. Lagujące wyrocznie i likwidacje-widma (Phantom Liquidations)

Grube ryby rzadko zostawiają swoje pozycje bez opieki. Często zabezpieczają je zdecentralizowanymi automatyzacjami (np. Gelato network czy Chainlink Automation), które dorzucają depozyt (margin) w momencie, gdy HF drastycznie spada.

Co więcej, podczas potężnej zmienności (ronda rzezi na rynku), sieć Ethereum lub rozwiązania L2 (Arbitrum, Base) łapią potężny congestion i gas spike'i. Wyrocznia (oracle) może zaktualizować cenę z opóźnieniem o 1-2 bloki. Bot monitorujący cenę spot na derywatach off-chain (np. na Binance) wyśle transakcję likwidacyjną, zakładając, że HF < 1, ale na poziomie smart contractu transakcja wywali REVERT, bo cena on-chain jeszcze nie drgnęła. W ten sposób przepalisz tylko kaskę na opłaty sieciowe (failed gas) za puste wywołanie.

3. Obrona przed Front-runningiem przez prywatne RPC

Kiedy Twój bot wysyła paczkę transakcji (bundle) przez Flashbots, konkurujesz z innymi searcherami na zasadzie podziału zysku. Jeśli znajdziesz likwidację na $10,000, a Twój konkurent ustawił bota tak, żeby oddawał walidatorowi 99% zysku jako łapówkę (Gas Tip), to on wygra blok – zgarniając marne $100 na czysto – a Twoja transakcja zostanie odrzucona.

Strategiczny hack: W sieciach z groszowymi opłatami i kosmiczną przepustowością (Base, Arbitrum, Solana) klasyczne bundle Flashbots działają inaczej lub w ogóle nie istnieją w znanej nam formie. Tam wygrywa ten, kto ma fizycznie najbliżej do walidatorów (najniższy ping sieciowy do węzła RPC) i potrafi spamować transakcjami w paczkach, wykorzystując bezpośrednie połączenia gRPC.

Checklista: Jak zbudować strategię wokół likwidacji wielorybów

Jeśli planujesz postawić własny system monitoringu albo trejdować kaskady likwidacji ręcznie/półautomatycznie, idź krok po kroku według tego algorytmu:

  • Budowa bazy celów: Napisz skrypt (indexer) do scrapowania adresów dłużników z największych protokołów (Aave, Compound, Spark, Morpho, Radiant). Przefiltruj portfele, których wartość zabezpieczenia przekracza $1,000,000.
  • Kalkulator triggerów: Stwórz moduł matematyczny, który bierze aktualne wagi pozycji obserwowanych wielorybów i wylicza precyzyjną cenę podłogi dla colateralu, przy której HF spadnie do dokładnie 1.0000.
  • Integracja alertów: Podepnij te krytyczne punkty pod parser orderbooków z giełd. Gdy tylko cena rynkowa zbliży się do punktu likwidacji wieloryba na mniej niż 1.5%, system musi odpalić alert o najwyższym priorytecie.
  • Wybór ścieżki monetyzacji:
    • Dla zespołów z kapitałem: Odpalenie rasowego bota MEV, ogarnięcie hydrauliki pod flash loany i walka o pierwszeństwo w bloku przez prywatne relaye.
    • Dla traderów detalicznych (retail): Otwarcie agresywnego shorta na rynkach futures (perps) z myślą o rozegraniu kaskadowego zrzutu ceny w momencie, gdy boty zaczną przymusowo dumpować zabezpieczenie wieloryba w rynek.

Rynek likwidacji w DeFi to czysta matematyka i bezwzględna prędkość egzekucji. Kto potrafi czytać stan blockchaina i automatyzować obliczenia punktów krytycznych, ten zawsze będzie miał kolosalną przewagę nad klasycznymi analitykami technicznymi rysującymi kreski na wykresie.


FAQ

Boty likwidacyjne w DeFi ogarniają flash loany tak, że pożyczają dokładnie tyle kapitału, ile trzeba na pokrycie długu zagrożonej pozycji w ramach jednej, atomowej transakcji (single atomic transaction). Dzięki temu operator bota nie musi mrozić własnego siana na start. Kiedy tylko smart kontrakt odpala funkcję flashLoanSimple na puli pożyczkowej typu Aave, pożyczone tokeny lecą prosto do wykonania liquidationCall, co pozwala zgarnąć zabezpieczenie (collateral) po zaniżonej cenie. Następnie bot z miejsca przepycha to przejęte zabezpieczenie przez DEX aggregatory albo AMM-y, żeby zrzucić je z powrotem do assetu bazowego, spłaca pożyczkę razem z prowizją protokołu (premium), a czysty zysk z arbitrażu (spread) ląduje na bezpiecznym portfelu operatora, zanim transakcja w ogóle zostanie zamknięta w bloku.

Lag wyroczni (oracle latency) tworzy rozjazd między cenami spot off-chain a stanem ceny na blockchainie, przez co boty marnują kasę na gas (lost gas fees) i łapią REVERT opcodes, próbując likwidować pozycje, których on-chainowy Health Factor nie spadł jeszcze poniżej krytycznego poziomu 1.0000. Przez to, że sieci i L2 mają swoje opóźnienia albo aktualizują ceny dopiero po przekroczeniu danego deviation threshold, szybkie ruchy cenowe na CEX-ach często triggerują symulacje botów zbyt wcześnie. Pro MEV searcherzy radzą sobie z tym, robiąc backrunning transakcji oracle feedu bezpośrednio w mempoolu — symulują dokładną zmianę stanu już po aktualizacji wyroczni i ślą paczki przez prywatne RPC (jak Flashbots), żeby nie zdradzić swojej alfa-strategii innym szukającym w ramach wojen gazowych (Priority Gas Auctions).

Close Factor to parametr na poziomie protokołu, który ucina maksymalny procent długu, jaki można spłacić w pojedynczej transakcji likwidacyjnej — zazwyczaj blokuje likwidatorów na poziomie 50% całej zagrożonej pozycji na jeden strzał. Taki mechanizm nie pozwala jednemu searcherowi zjeść potężnych, wielomilionowych pozycji instytucjonalnych w jednym bloku, dając protokołowi czas na przeliczenie pozostałego zabezpieczenia i długu, żeby powoli ustabilizować wskaźniki ryzyka. Żeby wyciągnąć pełną wartość z ogromnej likwidacji, zautomatyzowane boty muszą odpalać strategie iteracyjne (iterative state execution) — na bieżąco monitorują pozostały dług i wysyłają kolejne payloady blok po bloku, aż pozycja zostanie całkowicie wyczyszczona.
Sying Yu

I am a blockchain developer specializing in building secure, scalable, and innovative decentralized solutions. My expertise covers smart contracts, payment systems, and integrating crypto with fiat to optimize financial workflows. I thrive on creating modern, efficient tools for the evolving digital economy....

Dodaj opinię

Twój adres e-mail nie zostanie opublikowany. Obowiązkowe pola są oznaczone*