Appuyez sur ESC pour fermer

Bots MEV : Tracker et liquider les baleines DeFi

Le monde de la finance décentralisée (DeFi) est souvent comparé à une jungle numérique, et franchement, l’analogie est on ne peut plus vraie. Pendant que les traders retail ont les yeux rivés sur leurs graphiques à essayer de deviner le prochain move du marché, les vrais pros — les MEV searchers (Maximal Extractable Value) et les opérateurs de bots de liquidation — scalpent directement la blockchain à l'affût de la moindre erreur tactique.

Quand un gros poisson (une « baleine » ou « whale ») pose un énorme collatéral en crypto pour emprunter des volumes massifs sur un protocole de lending (comme Aave, Compound, Spark ou Morpho) et que le marché se retourne contre lui, tout bascule. Si sa position se retrouve à deux doigts de se faire liquider d’office, cela crée une inefficacité de marché unique, ultra-lucrative pour ceux qui savent en profiter.

Dans cet article, on va décortiquer la mécanique de tracking de ces positions chaudes, voir comment spotter les whales qui sont à moins de 1 % de la liquidation, et détailler la stratégie technique exact pour s'en mettre plein les poches.

L'anatomie du lending DeFi : pourquoi les liquidations se déclenchent

Pour piger où se planquent les failles, il faut maîtriser sur le bout des doigts les maths derrière les protocoles d'emprunt (Lending Protocols). Contrairement aux exchanges centralisés (CEX) où le moteur de liquidation est géré en interne par la plateforme elle-même, dans la DeFi, ce processus est entièrement délégué à des acteurs externes — les liquidateurs.

Le protocole ne peut pas fermer une position de lui-même, il n'a pas de trigger automatique intégré. À la place, il propose une incitation financière (une réduction sur le prix de rachat du collatéral, généralement de 5 à 10 %) pour que n’importe quel opérateur sur le réseau vienne rembourser la dette de l'emprunteur à sa place et reparte avec son collatéral à prix cassé.

La métrique reine : le Health Factor (HF)

La viabilité de n'importe quelle position d'emprunt est mesurée par ce qu'on appelle le Facteur de Santé (Health Factor). Sur la majorité des protocoles EVM-compatibles (comme Aave v3), la formule ressemble à ça :

1
 

Où :

  • Collateral_i représente la valeur du collatéral i dans la devise de référence (le plus souvent de l'ETH ou de l'USD).
  • LiquidationThreshold_i (le seuil de liquidation) est le ratio d’endettement maximal par rapport au collatéral fixé par le protocole pour cet actif précis (par exemple, 85 %).
  • Debt_j correspond à la valeur totale de l'emprunt j en cours, intérêts cumulés inclus.

Le point de non-retour : tant que le HF est supérieur à 1, la position est safe. Dès que le HF passe sous la barre des 1, la position devient publiquement liquidable par le premier bot qui passe.

Ça veut dire quoi « à 1 % de la liquidation » ?

C'est l'état critique où le HF d'une position oscille dangereusement dans une fourchette allant de 1.0001 à 1.01. Le moindre micro-mouvement du prix de l'actif mis en gage vers le bas (ou de l'actif emprunté vers le haut) transforme instantanément cette position en cible prioritaire pour les bots.

Stratégie « Profiter du dump » : deux scénarios d'attaque

La plupart des gens s'imaginent que le gain d'un liquidateur se limite au simple bonus offert par le protocole. Mais quand on commence à cibler des positions de whales qui pèsent des dizaines de millions de dollars, d’autres horizons bien plus rentables s'ouvrent à nous.

Scénario A : la liquidation classique via Flash Loans

Vous détectez une position avec un HF inférieur à 1. Problème : vous n'avez pas 10 000 000 $ de liquidités sous la main pour solder sa dette. C’est là que le Flash Loan intervient :

  1. Vous empruntez instantanément 10 millions de DAI sur Uniswap ou Aave au sein d'une seule et unique transaction, sans poser le moindre collatéral.
  2. Vous injectez ces 10 millions pour rembourser la dette de la whale directement dans le protocole.
  3. Vous récupérez son collatéral (disons de l'ETH) avec une remise de 5 % (vous repartez donc avec l'équivalent de 10,5 millions $ en ETH).
  4. Vous swappez immédiatement cet ETH contre du DAI sur un DEX, puis vous remboursez les 10 millions de DAI du Flash Loan + les frais d'emprunt.
  5. Le bénéfice net (environ 490 000 $ une fois les gas fees payés) est directement sécurisé dans votre wallet.

Scénario B : le short directionnel ciblé (Whale Hunting)

Là, on passe sur une stratégie beaucoup plus agressive qui demande une vraie lecture de la liquidité du marché :

  1. Vous repérez une whale avec un HF à 1.005 (à 0,5 % du gouffre). Son collatéral est composé de 50 000 WBTC et sa dette est en USDT.
  2. Vous calculez précisément à quel prix du WBTC son HF va tomber pile à 1. Disons qu'il suffit d'une baisse minime de 150 $.
  3. Vous ouvrez une grosse position short avec levier sur le WBTC via le marché des futures ou sur un DEX de dérivés.
  4. Si le carnet d'ordres spot est un peu "thin" (manque de liquidité locale), vous ou d'autres traders vendez lourdement du WBTC au spot pour provoquer une mèche baissière instantanée (un flash crash).
  5. Le prix vient mordre le trigger de liquidation. Les bots de liquidation (ou le vôtre) se jettent sur la whale pour la liquider en cascade. Lors du processus, d'énormes volumes de WBTC sont jetés de force sur le marché pour couvrir la dette, ce qui amplifie le dump et accélère la chute.
  6. Votre position short se ferme automatiquement sur votre Take-Profit, pile au plus bas de cette impulsion baissière provoquée ou accélérée.

La boîte à outils pour traquer les « whales blessées »

Scanner la blockchain manuellement via Etherscan, c'est purement impossible. Les pros combinent trois niveaux d'outils : des dashboards clés en main, des API d’infrastructure et des parsers custom branchés sur leurs propres nœuds.

1. Les plateformes d'analyse prêtes à l'emploi (idéal pour démarrer)

  • DeFi Saver (section Loan Shifter / Simulation) : parfait pour visualiser les plus grosses positions ouvertes sur les gros protocoles.
  • Debank / Arkham Intelligence : l'outil ultime pour se créer des Watchlists d'adresses spécifiques. Dès que vous repérez un gros emprunteur dans le top des holders d'un jeton, vous lui collez une alerte aux fesses.
  • Dune Analytics : il existe des tas de dashboards publics qui agrègent le Health Factor des plus gros emprunteurs en temps réel. (Cherchez les tags : Aave v3 liquidation thresholds ou Compound positions monitoring).

2. Les API spécialisées (pour l'automatisation)

Le moyen le plus propre pour récupérer de la donnée filtrée sans devoir faire tourner un archive node ultra-coûteux chez soi reste l’utilisation des API officielles des protocoles.

Par exemple, Aave fournit un endpoint GraphQL ouvert via The Graph, qui permet de dump d'un coup l'état financier de tous les emprunteurs du protocole.

ParamètreDescriptionPourquoi le surveiller
collateralBalanceUSDVolume total du collatéral exprimé en USDPermet de filtrer et de ne cibler que les whales (à partir d'un million $).
totalBorrowsUSDDette totale contractée exprimée en USDSert à évaluer la liquidité exacte nécessaire pour exécuter le remboursement.
currentLiquidationThresholdLe seuil de liquidation actuel de la positionIndispensable pour calculer au dollar près la zone de non-retour.

Guide pratique : coder un parser de positions critiques

Passons au code. Pour débusquer un portefeuille à moins de 1 % de la liquidation, on va pondre un script capable de requêter le smart contract Pool ou le DataProvider du protocole ciblé.

Voici un exemple de script en Python utilisant la bibliothèque web3.py. Ce script interroge le contrat Aave Protocol Data Provider sur la blockchain Arbitrum (un excellent choix pour la liquidation : frais dérisoires et exécution rapide), récupère les métriques de l'utilisateur et calcule sa proximité avec la liquidation.

import os
from web3 import Web3
# Connexion à un nœud RPC rapide (type Alchemy ou 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("Impossible de se connecter à la blockchain")
# Adresse du contrat Aave v3 Pool sur Arbitrum
AAVE_POOL_ADDRESS = "0x794a61358D6845594F94dc1DB02A252b5b4814aD"
# ABI minimal contenant uniquement la fonction 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:
        # Récupération des données du compte depuis le smart contract
        data = pool_contract.functions.getUserAccountData(w3.to_checksum_address(user_address)).call()
        
        # Les données renvoyées ont une précision à 18 décimales (dans la devise de base d'Aave)
        collateral = data[0] / 1e8  # Dépend de la devise v3 (généralement de l'USD avec 8 décimales)
        debt = data[1] / 1e8
        hf = data[5] / 1e18 # Le Health Factor est renvoyé avec 18 décimales
        
        # On filtre pour ne garder que les gros poissons (collatéral > 500 000 $)
        if collateral > 500000:
            print(f"Adresse : {user_address}")
            print(f"  Collatéral : ${collateral:,.2f} | Dette : ${debt:,.2f}")
            print(f"  Health Factor : {hf:.4f}")
            
            # Vérification de l'entrée dans la zone critique des 1 %
            # La liquidation se déclenche à HF <= 1.0, la zone à risque s'étend donc de 1.0000 à 1.0100
            if 1.0000 < hf <= 1.0100:
                print(f"⚠️ ALERTE POSITION CRITIQUE : Whale à moins de 1% de la liquidation ! Risque de dump du collatéral.")
                # C'est ici qu'on branche un webhook Telegram ou l'appel de fonction de votre bot de liquidation
            print("-" * 50)
            
    except Exception as e:
        print(f"Erreur lors du check de l'adresse {user_address} : {e}")
# Exemple de test sur une adresse cible (remplacez par une vraie adresse de votre liste)
whale_target = "0x..." 
check_whale_position(whale_target)

Comment alimenter votre base d'adresses à scanner ?

Le script ci-dessus fonctionne pour une seule adresse isolée. Pour monter un vrai radar de surveillance, il vous faut un flux d'adresses permanent. Les bots professionnels s'alimentent de la manière suivante :

  • Le parsing des événements historiques (Events) : le bot scanne la blockchain une bonne fois pour toutes depuis le déploiement du protocole pour extraire toutes les adresses ayant interagi avec les événements Supply, Borrow ou CollateralSwitch.
  • L'écoute des logs en temps réel : un script écoute les nouveaux blocs via WebSockets (w3.eth.subscribe('logs', ...)) pour intercepter instantanément chaque nouvelle adresse qui interagit avec les pools. Toutes les adresses uniques sont stockées proprement dans une base de données locale (type MariaDB ou PostgreSQL).
  • La boucle de surveillance : un worker tourne en boucle continue sur la base de données pour appeler la fonction getUserAccountData sur chaque profil enregistré et actualiser les scores.

Anatomie de la « Chasse » : Comment calculer précisément le point de trigger

Pour exploiter efficacement les failles d'une « baleine blessée », se contenter de checker son Health Factor actuel ne suffit pas. Un searcher pro doit anticiper la dynamique des prix. Il nous faut le prix exact de l'actif mis en gage (le collatéral) auquel la position partira directement à l'abattoir.

Formalisons le calcul. Disons que notre baleine a déposé un seul actif en garantie (par exemple de l'ETH) et emprunté un seul actif stable (l'USDT). Dans ce protocole, le seuil de liquidation (Liquidation Threshold, ou LT) de l'ETH est fixé à 85 % (0.85).

La formule pour déterminer le prix critique du collatéral, Price_crit, se présente ainsi :

Formula for the critical price of collateral
 

Exemple concret de calcul

Prenons le cas d'une position massive actuellement ouverte sur le marché :

  • Montant du collatéral Collateral_Amount : $10,000\ ETH$
  • Prix actuel de l'ETH : $3,400\ USD$
  • Valeur de la garantie en fiat : $34,000,000\ USD$
  • Dette actuelle Debt_USD : $28,500,000\ USDT$
  • Seuil de liquidation LT : 85% (0.85)

Calculons d'abord le Health Factor actuel de la position :

position-health-factor
 

La position est sur le fil du rasoir, à seulement 1.4 % de la correction. Déterminons maintenant le prix de l'ETH qui va tout faire s'effondrer :

The ETH price at which the position will collapse
 

Dès que le prix de l'ETH poussé par l'oracle du protocole (généralement Chainlink) touchera la barre des $3,352.94, la position passera instantanément en mode « liquidable ».

Alpha insider méconnu : Les smart contracts n'ont aucune idée du prix spot réel sur Binance à la milliseconde près. Ils dépendent entièrement des oracles. Les oracles de Chainlink mettent à jour le prix on-chain soit selon un intervalle de temps (par exemple toutes les 20 minutes), soit dès que le prix off-chain dévie d'un certain pourcentage (Deviation Threshold) — typiquement 0.5 % ou 1 % sur les paires majeures. En maîtrisant ce seuil, les searchers d'élite peuvent anticiper le moment exact du « déclenchement » de la liquidation quelques secondes avant que la transaction de l'oracle ne soit validée dans le mempool.

La stratégie « Whale Hunting » en pratique : Mécanique d'exécution

Une fois la cible verrouillée et le prix critique calculé, le searcher a deux options pour extraire de la valeur : la méthode passive (se préparer à liquider) et la méthode offensive (provoquer le dump).

1. Ingénierie de la liquidité (Flash Loans vs Fonds propres)

Si votre plan est de rafler le bonus de liquidation (dans notre exemple, un bonus de 5 % sur $34M représente un profit brut de $1.7M), vous devez sortir $28.5M d'un coup pour rembourser la dette.

Laisser dormir une telle somme sur un wallet étant une hérésie en termes d'efficience en capital, on utilise un Flash Loan (prêt flash) via les pools de liquidité d'Uniswap v3 ou les lenders d'Aave. Vous empruntez les $28.5M au sein de la même transaction atomique, vous appelez la fonction liquidationCall sur le contrat d'Aave, vous saisissez l'ETH, et vous convertissez immédiatement une partie de cet ETH en USDT via un agrégateur (1inch / Paraswap) pour rembourser le flash loan et sa louche de frais (0.05 %). Le reste de l'ETH, c'est du bénéfice net et pur.

2. Arbitrage de marché et short directionnel

Quand la taille de la baleine dépasse les capacités des pools de flash loans standards ou que la liquidité des DEX spot est trop fine pour absorber la conversion du collatéral sans un slippage destructeur, on bascule sur une stratégie de frontrunning via les dérivés :

  1. Étape 1 : Vous repérez qu'il ne manque plus qu'un petit mouvement de 15 à 20 dollars pour atteindre le point critique des 3,352.94.
  2. Étape 2 : Vous ouvrez un short agressif à fort levier sur les perps via des DEX spécialisés (Hyperliquid, dYdX, Vertex) ou des CEX majeurs.
  3. Étape 3 (Le catalyseur) : Sur le marché spot (en choisissant le moment où l'order book est le plus fin), une grosse vente est balancée. C'est souvent le fait de gros market makers ou de groupes de searchers coordonnés pour provoquer un mini-crash (un price flush) instantané.
  4. Étape 4 (La cascade) : Dès que le prix franchit le trigger, les bots de la terre entière se mettent à spammer les fonctions de liquidation. Pour sécuriser leurs gains, ces bots vont dump au prix du marché le collatéral saisi (ETH) directement pour récupérer des stablecoins.
  5. Étape 5 (La récolte) : L'injection massive de 10,000 ETH à la vente en l'espace d'une minute ou deux défonce les bids locaux, entraînant le cours 2 à 3 % plus bas. Votre position short est complétée au bottom absolu de ce mouvement artificiel ou accéléré.

Architecture d'un bot de liquidation : Comment gratter les concurrents

Si vous comptez coder un bot pour exécuter vous-même la liquidation, un simple script Web3 de base va se faire découper. Dans cette niche, c'est la guerre de vitesse absolue, connue sous le nom de PGA (Priority Gas Auction) et de course aux MEV-boosts.

N'importe quelle transaction classique envoyée dans le mempool public sera interceptée par des bots de frontrun généralisés. Ils vont copier votre calldata, rajouter 1 gwei sur les frais de gaz et vous voler la liquidation sous le nez.

Le stack technique d'un bot MEV de niveau production :

  • Langage de programmation : L'ingestion des données et l'analyse se font généralement en Python/Go. Le smart contract d'exécution (celui qui gère le routage du flash loan et l'appel de la liquidation) doit impérativement être écrit en Solidity / Yul (optimisation maximale du gaz). Récemment, Rust s'est imposé sur les backends des bots pros via l'écosystème de la bibliothèque alloy.
  • Connexion directe aux Block Builders : Les pros zappent complètement le mempool public. Les transactions passent par des relais privés (Relays) comme Flashbots (MEV-Share / MEV-Boost), BeaverBuild ou Titan. La transaction est envoyée sous forme de « bundle » directement au validateur. En gros, vous dites au validateur : « Glisse ma transaction pile après celle de l'oracle qui fait baisser le prix de l'ETH, et je te file 50 % de mon profit de liquidation en pourboire (tip) ».

Voici le schéma logique des interactions entre les composants d'un tel bot :

[Blockchain Node / Websocket] 
       │ (Scanne les nouveaux blocs & le mempool)
       ▼
[Parser & DB] ────► [Health Factor Calculator] 
                         │ (Déclenché si HF <= 1)
                         ▼
                  [Flashbots / MEV Builder] ──► [Private Validator] ──► [Profit]

Architecture du smart contract d'exécution (Solidity)

Pour qu'une liquidation passe crème au sein d'une seule et unique transaction atomique, toute la logique d'interaction avec le Flash Loan et le protocole de lending doit être packagée dans un smart contract custom. Pas question de balancer des transactions séparées directement depuis un wallet (EOA) — les bots concurrents vont vous front-run et siffler le collatéral en un clin d'œil.

Voici un exemple d'architecture de smart contract sous Solidity ^0.0.20, taillé pour interagir proprement avec Aave v3 via un mécanisme de 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, "Pas le owner");
        _;
    }
    constructor(address _pool) {
        owner = msg.sender;
        aavePool = IPool(_pool);
    }
    // Structure pour faire passer les paramètres au callback du flash loan
    struct LiquidationParams {
        address collateralAsset;
        address debtAsset;
        address userToLiquidate;
        uint256 debtToCover;
    }
    // 1. Trigger externe : callé par votre backend (en Rust/Go/Python) dès qu'une cible est spotée
    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
            })
        );
        // On demande le flash loan à Aave pour calibrer pile-poil la dette de la baleine
        aavePool.flashLoanSimple(
            address(this),
            _debtAsset,
            _debtToCover,
            params,
            0
        );
    }
    // 2. Callback d'Aave : exécuté dans la MEME transaction APRÈS réception des fonds sur le solde du contract
    function executeOperation(
        address asset,
        uint256 amount,
        uint256 premium,
        address initiator,
        bytes calldata params
    ) external returns (bool) {
        require(msg.sender == address(aavePool), "Caller invalide");
        
        LiquidationParams memory lParams = abi.decode(params, (LiquidationParams));
        // On approve la pool pour qu'elle vienne scale nos fonds empruntés afin de liquider la position
        IERC20(lParams.debtAsset).approve(address(aavePool), lParams.debtToCover);
        // On déclenche la liquidation pure et dure.
        // Le dernier paramètre à false indique qu'on veut récupérer le collatéral brut, pas son dérivé aToken
        aavePool.liquidationCall(
            lParams.collateralAsset,
            lParams.debtAsset,
            lParams.userToLiquidate,
            lParams.debtToCover,
            false
        );
        // À ce stade, le contract a récupéré le collatéral saisi (par exemple de l'ETH)
        // Reste à faire : Swap le collatéral sur un DEX (Uniswap/1inch) pour repasser dans la devise de la dette (ex: USDT)
        // Le but : Couvrir le principal de l'emprunt (amount) + les frais du flash loan (premium)
        
        uint256 totalOwed = amount + premium;
        
        // [Insérer ici la logique de call du swap() sur Uniswap v3 / 1inch Router]
        // En sortie, on doit avoir un solde >= totalOwed dans l'asset debtAsset
        
        // On approve le remboursement du flash loan
        IERC20(lParams.debtAsset).approve(address(aavePool), totalOwed);
        // On transfère le reste des profits nets dans la poche du owner du contract
        uint256 profit = IERC20(lParams.debtAsset).balanceOf(address(this));
        if (profit > 0) {
            IERC20(lParams.debtAsset).transfer(owner, profit);
        }
        return true;
    }
    // Fonction d'urgence pour rescue n'importe quel token bloqué sur le contract
    function withdrawToken(address _token) external onlyOwner {
        uint256 balance = IERC20(_token).balanceOf(address(this));
        IERC20(_token).transfer(owner, balance);
    }
}

Subtilités méconnues et chausse-trappes (L'Alpha brute)

Si c'était si facile, n'importe quel dev deviendrait millionnaire en une semaine. En réalité, les coulisses de la "forêt sombre" (Dark Forest) regorgent de barrières techniques impitoyables.

1. Le problème des « Liquidations douces » (Close Factor)

Impossible de raser toute la position d'une baleine d'un coup si son volume se compte en dizaines de millions. La plupart des protocoles modernes intègrent un paramètre de Close Factor (généralement capé à 50 %). Cela implique que sur une seule transaction, vous ne pouvez rembourser que la moitié de la dette de l'utilisateur.

Si vous dénichez une baleine avec 20 000 000 $ de dette, votre bot devra envoyer une transaction pour couvrir au maximum 10 000 000 $. Le reste de la dette est recalculé, le Health Factor remonte un poil, et si la position est toujours dans le rouge, elle redeviendra éligible à un nouveau coup de balai au bloc suivant.

2. Désynchronisation des Oracles et liquidations « Fantômes »

Les gros poissons ne laissent que rarement leurs positions à l'abandon. Ils blindent souvent leurs arrières avec des automatisations décentralisées (type Gelato network ou Chainlink Automation) qui vont venir injecter de la marge (margin) dès que le HF commence à flancher.

De surcroît, lors des phases de volatilité extrême (les bains de sang sur le marché), le réseau Ethereum ou les L2 (Arbitrum, Base) saturent complètement, ce qui fait exploser les frais (Gas Spike). L'oracle peut accuser un retard de mise à jour d'un ou deux blocs. Un bot branché sur les prix spot des dérivés off-chain (comme Binance) va instantanément envoyer sa transaction de liquidation en pensant que le HF < 1, sauf qu'au niveau du smart contract, la transaction va REVERT (fail) parce que l'oracle on-chain n'a pas encore actualisé le prix. Résultat : vous venez de cramer des frais de gas pour une transaction fantôme.

3. Blindage contre le Front-running via les RPC privés

Quand votre bot pousse un bundle via Flashbots, vous jouez des coudes avec d'autres searchers sur le partage des gains. Si vous repérez une liquidation à 10 000 $ et que votre concurrent a configuré son bot pour reverser 99 % du profit au validateur sous forme de pot-de-vin (Gas Tip), c'est lui qui va rafler le bloc — en se dégageant un maigre 100 $ net — tandis que votre transaction sera tout simplement rejetée.

Le hack stratégique : Sur les réseaux aux frais dérisoires et à haute fréquence (Base, Arbitrum, Solana), les bundles Flashbots classiques fonctionnent différemment ou n'existent pas sous leur forme habituelle. Là-bas, le gagnant est celui qui est physiquement le plus proche des validateurs (ping réseau le plus faible vers le nœud RPC) et qui est capable de spammer des salves de transactions en utilisant des connexions gRPC customisées.

Check-list : Comment monter sa stratégie de liquidation de baleines

Si vous voulez monter votre propre infra de monitoring ou trade ces cascades de liquidations à la main ou en semi-auto, suivez scrupuleusement cet algorithme :

  • Collecte des cibles : Codez un script (indexer) pour parser les adresses des emprunteurs sur les gros protocoles (Aave, Compound, Spark, Morpho, Radiant). Filtrez les portefeuilles dont le collatéral dépasse le 1 000 000 $.
  • Calculateur de triggers : Créez un module mathématique qui récupère le poids en temps réel des positions des baleines ciblées et calcule le prix exact du collatéral pour lequel leur HF va toucher exactement 1.0000.
  • Intégration des alertes : Branchez ces points critiques sur un parseur d'order books d'exchanges. Dès que le prix de marché s'approche à moins de 1.5 % du point de rupture de la baleine, le système doit envoyer une alerte de priorité absolue.
  • Choix du vecteur de monétisation :
    • Pour les équipes capitalisées : Activation d'un bot MEV pur et dur, tuyauterie prête pour les flash loans et guerre de blocs via des relais privés.
    • Pour les traders retail : Ouverture d'un short agressif sur les marchés futures (perps) pour capitaliser sur la cascade de ventes forcées au moment où les bots vont dump le collatéral de la baleine au prix du marché.

Le marché des liquidations en DeFi, c'est de la pure mathématique couplée à de la vitesse d'exécution. Ceux qui savent lire l'état de la blockchain et automatiser le calcul des points de rupture auront systématiquement une longueur d'avance sur les analystes techniques classiques qui tracent des lignes sur des graphiques.


FAQ

Les bots de liquidation DeFi capturent des flash loans en empruntant exactement le capital nécessaire pour refresh la dette d'un emprunteur sous l'eau (distressed), le tout au sein d'une seule transaction atomique sur la blockchain. Du coup, pas besoin pour l'opérateur du bot de stacker des fonds propres au départ. Dès que le smart contract trigger la fonction flashLoanSimple sur un protocole de lending comme Aave, les fonds reçus sont instantanément routés pour call la liquidationCall, ce qui permet de target le collateral sous-jacent avec une bonne décote. Le bot fait ensuite direct passer ce collateral par des agrégateurs de DEX ou des AMM pour le swap et repasser sur l'asset de la dette initiale, rembourse le principal plus la premium du protocole, et envoie le spread d'arbitrage restant sur le wallet safe de l'opérateur avant que la transaction ne soit validée dans le bloc.

La latence des oracles crée un mismatch entre les prix spot off-chain et l'état des prix on-chain. Résultat : les bots se mangent des échecs de bundles et perdent des thunes en gas fees à cause d'opcodes REVERT en tentant de liquider des positions dont le Health Factor on-chain n'est pas encore officiellement passé sous la barre critique des 1.0000. Comme les réseaux de consensus et les L2 se tapent des délais déterministes ou brident les updates selon des deviation thresholds précis, les flux de prix haute fréquence des CEX font souvent trigger les simulations des bots trop tôt. Pour s'en sortir, les MEV searchers pros contournent le problème en faisant du backrunning sur les transactions de price feed directement dans le mempool : ils simulent le changement d'état exact post-update de l'oracle et passent par des relais RPC privés pour éviter que leur alpha ne leak chez les searchers concurrents en pleine Priority Gas Auction.

Le Close Factor est un paramètre gravé dans le protocole qui cap le pourcentage maximal de la dette d'un borrower qu'on peut rembourser en une seule transaction de liquidation. En général, ça limite les liquidateurs à clean seulement 50% de la position en détresse d'un seul coup. Cette barrière structurelle empêche un searcher solo de complètement dump et absorber d'énormes positions institutionnelles en un seul bloc, ce qui laisse le temps au protocole de recalculer le collateral restant et la dette pour stabiliser gentiment les health metrics du portefeuille. Pour chasser la valeur totale d'une liquidation à plusieurs millions de dollars, les moteurs de recherche automatisés doivent call des stratégies d'exécution itératives (iterative state execution), en checkant en boucle les liabilities restantes et en envoyant des payloads d'exécution bloc après bloc jusqu'à ce que le profil de risque ciblé soit totalement clean.
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....

Partager votre avis

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués *