Les gains d’un trader sur Ethereum et autres Layer‑1 peuvent être rognés en quelques secondes par des algorithmes : comprendre le phénomène et ses parades est désormais indispensable. Cet article explique en détail qui agit, comment ils agissent, et quelles mesures pratiques réduire leurs effets.
Points Clés
- Comprendre le MEV : Le MEV correspond à la valeur que des acteurs peuvent extraire en réordonnant ou en incluant/excluant des transactions, et il affecte directement le résultat des trades.
- Identifier les attaques : Les sandwichs, snipers, front‑runs et back‑runs sont les formes les plus courantes qui augmentent le slippage et réduisent les gains.
- Mesures concrètes : Ajuster la tolérance de slippage, fractionner les ordres, utiliser ordres limit/off‑chain et recourir à des relays privés quand nécessaire.
- Outils et surveillance : Utiliser Flashbots, Etherscan et des agrégateurs réputés pour analyser et limiter l’exposition.
- Équilibrer coût et protection : La protection contre le MEV a un coût ; elle doit être proportionnée à la taille et à la sensibilité de la transaction.
Qu’est‑ce que le MEV et pourquoi il menace vos trades ?
MEV signifie « Miner/Maximal Extractable Value » (parfois présenté comme « Maximal Extractable Value » depuis la généralisation de la preuve d’enjeu). Il représente la valeur additionnelle qu’un mineur, validateur ou tout acteur capable d’ordonnancer les transactions peut capturer en choisissant l’inclusion, l’exclusion ou l’ordre des transactions dans un bloc.
Cette extraction dépasse le simple paiement du gas : un proposeur de bloc peut insérer sa propre transaction avant une grosse swap, regrouper plusieurs transactions dans un bundle ou refuser certaines transactions pour tirer profit des mouvements de prix ou des opportunités d’arbitrage. La problématique a été étudiée académiquement, notamment dans l’article « Flash Boys 2.0 », qui décrit comment la possibilité de réordonner des transactions crée des opportunités d’extraction de valeur.
Pour un trader de détail, ces extractions se matérialisent souvent sous la forme de front‑running, sandwich attacks ou de snipes lors de listing : au lieu d’obtenir le prix attendu, il subit un glissement (slippage) plus élevé, voit une partie de son gain captée par des bots, ou paie davantage en frais pour prioriser sa transaction.
Anatomie technique : mempool, gas et ordre d’exécution
Pour comprendre qui prend quoi, il faut savoir comment une transaction circule avant d’être incluse dans un bloc. Lorsqu’un utilisateur soumet une transaction, elle est diffusée aux nœuds et reste visible dans le mempool public tant qu’elle n’est pas minée.
Des bots scrutent continuellement ce mempool pour repérer des opportunités : gros swaps, listes de token, transferts importants, liquidations, etc. Ils réagissent automatiquement en envoyant des transactions concurrentes avec un gas price plus élevé afin d’être traités avant (front‑run) ou après (back‑run) la transaction cible.
Le rôle du mineur/validateur est central : il reçoit des transactions publiques et privées, puis choisit quelles inclure et dans quel ordre. L’introduction de mécanismes comme la séparation proposer/builder via MEV‑Boost a modifié ces dynamiques : elle a professionnalisé la construction de blocs et structuré le marché de l’extraction de MEV, tout en introduisant des débats sur la centralisation et la redistribution des revenus.
Les attaques courantes qui prennent vos gains
Certaines tactiques sont devenues standard dans l’arsenal des bots. Les connaître permet d’adapter son exécution et de limiter les pertes.
Snipers (sniping de tokens et d’ordres)
Snipers sont des bots conçus pour être les premiers à profiter d’un événement court — par exemple un listing de token, une migration de liquidité ou une fenêtre d’arbitrage fraîchement ouverte. Ils surveillent :
- les transactions d’ajout de liquidité dans le mempool,
- le déploiement de contrats récents et les fonctions d’initialisation,
- les signaux on‑chain ou hors‑chaîne annonçant une opportunité.
En recevant l’information, le sniper envoie une transaction avec des frais élevés pour être traitée avant le reste, ce qui lui permet d’acheter avant d’autres participants, faire monter le prix, puis revendre après pour capturer la marge.
Sandwich attacks
Le sandwich est devenu l’attaque la plus visible sur les AMM (automated market makers) comme Uniswap. Son mécanisme :
- le bot détecte une transaction d’achat importante en mempool,
- il place une transaction d’achat juste avant la transaction cible (front‑run) pour pousser le prix à la hausse,
- la victime exécute son achat à ce prix augmenté, puis le bot revend immédiatement après (back‑run), récupérant la différence.
Le coût pour la victime dépasse le simple spread : elle subit un slippage artificiellement amplifié et paie des frais gas qui ont servi à prioriser les transactions du bot. Des analyses sur des échanges réels montrent que ces pratiques peuvent grignoter plusieurs pourcents d’un trade, particulièrement sur des pools peu profondes.
Front‑running et back‑running
Front‑running consiste à exécuter une transaction avant une autre identifiée pour profiter du mouvement anticipé ; back‑running intervient juste après la transaction cible pour capter les effets induits. Ces stratégies s’appliquent aussi aux liquidations de prêts, aux arbitrages et aux opérations de market making.
Les front‑running bots ne cherchent pas uniquement la volatilité liée à un swap : ils peuvent interférer avec des liquidations, perturber des stratégies d’arbitrage inter‑DEX, ou retirer un profit lors d’une reconfiguration de pool. Tous ces comportements augmentent l’incertitude d’exécution et réduisent les rendements attendus.
Le rôle du slippage et pourquoi il compte
Slippage désigne l’écart entre le prix espéré d’une transaction et le prix auquel elle est réellement exécutée. Sur les AMM, il dépend de la taille de l’ordre relative à la profondeur de la pool et de l’ordre d’exécution des transactions.
Les interfaces de swap proposent un paramètre de tolérance de slippage : si le slippage réel dépasse cette tolérance, la transaction échoue. Mais choisir la tolérance est un arbitrage : une tolérance trop élevée expose à des sandwichs et front‑runs ; une tolérance trop basse génère des échecs fréquents en période de volatilité ou lorsque le gas change.
Quelques règles pratiques pour l’exécution :
- pour des petits ordres sur des pools profondes, une tolérance basse (0,1–0,5 %) est généralement suffisante ;
- pour des ordres conséquents sur pools peu liquides, il vaut mieux fractionner (TWAP) plutôt que d’augmenter la tolérance ;
- ne pas augmenter mécaniquement la tolérance pour « garantir » l’exécution sans évaluer le coût réel : cela équivaut à laisser la porte ouverte aux bots.
Private mempool et Flashbots : refuge ou nouvelle menace ?
Pour réduire l’exposition au mempool public, des canaux privés permettent d’envoyer des transactions directement aux mineurs/validateurs. Flashbots est l’acteur le plus connu : il propose des relais et des outils pour soumettre des bundles de transactions hors du mempool public, et ainsi limiter certaines formes de front‑running.
Les avantages du recours à un service privé comme Flashbots :
- réduction du risque de front‑running via le mempool public,
- possibilité de soumettre des bundles atomiques (ex. swap + arbitrage conditionnel),
- meilleure prévisibilité d’exécution pour des ordres complexes.
Mais l’usage de canaux privés crée également des marchés secondaires : des bundles lucratifs peuvent bénéficier à ceux qui peuvent payer pour l’inclusion prioritaire par les validateurs. Autrement dit, Flashbots structure et rend transparent un marché qui existait déjà, sans l’éliminer. Pour en savoir plus, consulter la documentation sur Flashbots.
Détecter quand un trade a été affecté par le MEV
Un trader peut apprendre à identifier si son trade a été ciblé ou affecté par une opération de MEV en examinant la transaction et son contexte :
- sur Etherscan, vérifier les transactions précédentes et suivantes du même bloc pour détecter un front‑run et un back‑run autour de la transaction ;
- observer le pattern : achats justes avant, vente immédiate après, montants et adresses inconnues ;
- utiliser des outils d’analyse comme Flashbots pour retrouver des sandwichs et bundles identifiés ;
- surveiller le gas payé : des gas fees anormalement élevés autour d’une transaction sont souvent un indice d’activité de bot.
À partir de ces indices, le trader peut documenter l’incident et adapter ses futures exécutions (réglage du slippage, fractionnement, usage de canaux privés).
Réglages anti‑MEV dans le portefeuille et sur les DEX
Un trader peut agir directement via le portefeuille et l’interface DEX pour limiter l’extraction :
- Réduire la tolérance de slippage autant que possible sans bloquer l’exécution ;
- Régler le deadline : limiter la durée de validité d’une transaction pour éviter qu’elle reste exploitable longtemps dans le mempool ;
- Fixer manuellement le gas fee plutôt qu’utiliser des estimations dynamiques naïves ;
- Utiliser des order types hors mempool : ordres limit ou solutions d’exécution off‑chain (protocoles de limit order, 0x, matchers) ;
- Passer par des relays privés ou options « protect » proposées par certains wallets/agrégateurs ;
- Tester à petite échelle pour vérifier l’exécution réelle et ajuster les paramètres.
Par exemple, MetaMask permet de modifier manuellement le gas et la tolérance de slippage ; certains agrégateurs intègrent des options de routage qui minimisent l’exposition au mempool public. L’utilisation judicieuse de ces fonctionnalités réduit l’impact des bots sur la majorité des trades de détail.
Bonnes pratiques d’exécution pour les traders
Voici une checklist opérationnelle qu’un trader prudent peut suivre avant d’envoyer une transaction :
- Évaluer la profondeur de la pool : lorsqu’un swap dépasse 1–2 % de la pool, le risque de sandwich augmente significativement ;
- Fractionner l’ordre : exécuter en plusieurs petits swaps ou utiliser un TWAP (Time‑Weighted Average Price) ;
- Privilégier les ordres limit lorsque possible pour éviter d’être exposé trop longtemps dans le mempool public ;
- Passer par des agrégateurs réputés : 1inch, Matcha ou Paraswap optimisent les routes et peuvent réduire le slippage ;
- Utiliser des canaux privés pour les opérations sensibles : Flashbots Protect ou relays similaires ;
- Surveiller le mempool si la stratégie le permet : anticiper des risques en observant des transactions conflictuelles ;
- Documenter et apprendre : garder trace des incidents pour affiner une stratégie d’exécution sur le long terme.
Bonnes pratiques pour les développeurs de tokens et d’AMM
Les équipes qui lancent des tokens ou créent des pools ont une responsabilité forte pour atténuer l’impact des snipers et bots :
- Whitelist initiale ou vente privée : limiter l’accès initial aux participants identifiés pour réduire les snipes immédiats ;
- Locker la liquidité : verrouiller la liquidity pool sur une période pour limiter les rug pulls et réduire l’incitation aux snipes ;
- Introduire des délais ou limites de transfert pendant les premières heures pour empêcher les swaps massifs automatisés ;
- Utiliser des mécanismes de lancement progressif (liquidity bootstrapping pools, auctions) pour distribuer l’offre sans créer une opportunité de sniping instantané ;
- Éduquer la communauté : expliquer les risques et recommander des méthodes d’achat moins exposées pour les premiers acheteurs.
Ces mesures peuvent rendre un lancement moins « spectaculaire » mais plus sûr et durable pour les investisseurs ordinaires.
Approches avancées : TWAP, limit order, bundling et commit‑reveal
Pour des ordres importants, des techniques plus professionnelles existent :
- TWAP / VWAP : exécution automatique en tranches pour réduire l’impact de marché et l’exposition au mempool ;
- Ordres limit off‑chain : expressés hors chaîne et appariés via des contreparties ou des protocoles qui évitent la publication immédiate ;
- Bundles atomiques : soumettre un ensemble de transactions atomiques (swap puis arbitrage) pour limiter la fenêtre exploitée par des bots ;
- Commit‑reveal : engager une valeur cryptographique puis révéler pour contrer le front‑running (ajoute de la latence mais protège certaines opérations) ;
- Encrypted mempool / threshold encryption : techniques de recherche qui visent à empêcher la lecture des transactions avant leur inclusion, proposées dans la recherche académique et expérimentées sur certains réseaux.
Exemples pratiques et cas chiffrés
Un exemple chiffré simple illustre l’impact d’un sandwich sur une AMM avec courbe constante x*y=k. Imaginons une pool avec 10 000 tokens X et 100 ETH (prix implicite 100 X = 1 ETH) et que la victime achète 100 X pour 1 ETH (valeur ≈ 1 000 $ si 1 ETH = 1 000 $ pour simplifier).
Si un bot réalise un front‑run en achetant d’abord 10 X, le ratio change et le prix pour la victime devient plus élevé. Après le back‑run, le bot revend ses 10 X en profitant de la hausse artificielle. Le profit du bot dépendra de la pente de la courbe d’AMM ; sur des pools peu profondes, ce profit peut représenter plusieurs % du trade initial, soit des dizaines à centaines de dollars sur cet exemple.
Des analyses publiques et des données agrégées montrent que l’extraction de MEV a représenté des montants importants annuellement sur Ethereum, illustrant l’ampleur du phénomène pour les traders et la nécessité de meilleures protections.
Outils et ressources pour surveiller et comprendre le MEV
Plusieurs ressources aident à analyser et se protéger :
Limitations et compromis : la protection contre le MEV a un coût
Se protéger n’est pas gratuit. Utiliser des canaux privés, payer un relayer, ou fractionner un trade augmente les frais totaux. Les solutions de lancement pour projets ajoutent de la complexité et peuvent retarder la liquidité initiale.
Chaque stratégie doit être proportionnée au montant et à la sensibilité de l’opération. Un petit swap sur une pool très liquide n’exige pas les mêmes précautions qu’un swap à cinq chiffres sur une pool peu profonde.
Aspects juridiques et réglementaires : que surveiller en France et en Europe ?
Le cadre réglementaire autour du MEV est en évolution. Les autorités de marché examinent les pratiques d’exécution algorithmique et les risques de manipulation. En France, l’Autorité des marchés financiers (AMF) surveille les marchés de cryptoactifs et publie des recommandations générales sur la protection des investisseurs et la conformité des acteurs.
Au niveau européen, l’entrée en vigueur prochaine de MiCA (Markets in Crypto‑Assets) créera un cadre pour les prestataires de services de cryptoactifs, mais la régulation spécifique des pratiques de séquencement des transactions ou du MEV dépendra des textes d’application et de l’interprétation des règles de manipulation de marché dans un contexte on‑chain.
Les acteurs institutionnels et les développeurs doivent suivre les évolutions : le front‑running algorithmique ou l’usage commercial de bots pourrait, selon le contexte, tomber sous les prohibitions de pratiques de marché abusives si la régulation lève l’équivoque entre décentralisation technique et comportements de marché classiques.
Perspectives techniques et initiatives de mitigation
Plusieurs pistes techniques visent à réduire les effets néfastes du MEV :
- Mempools chiffrés (encrypted mempool) : les transactions sont chiffrées jusqu’à ce qu’un proposeur de bloc les décrypte, empêchant la lecture par des bots jusqu’à l’inclusion ;
- Commit‑reveal : masquer temporairement les détails de la transaction pour empêcher le sniping sur la base d’informations publiques ;
- Systèmes de séquencement équitables : proposer des règles d’ordre de traitement (par ex. ordre par timestamp vérifié, rotations) pour réduire l’avantage des enchères de gas ;
- Redistribution du MEV : mécanismes pour partager une partie des revenus de MEV avec les utilisateurs ou l’écosystème afin d’atténuer l’effet extractif ;
- Proposer/Builder Separation (PBS) : continue d’évoluer pour équilibrer efficacité et risques de centralisation ;
- Solutions L2 : certains rollups expérimentent des règles de séquencement et des relayers différents pour limiter l’exposition des transactions des utilisateurs.
Ces pistes sont en continuelle expérimentation et chacune présente des compromis entre sécurité, latence, coût et centralisation. Les développeurs et opérateurs de réseau doivent évaluer la pertinence technique et économique avant adoption.
Étapes pratiques : comment utiliser Flashbots Protect et autres relays privés
Pour un utilisateur souhaitant réduire l’exposition au mempool public, voici un guide pragmatique (approche générale) :
- vérifier si son wallet ou agrégateur propose une option « protect » ou d’envoi privé (certains intégrateurs de Flashbots offrent cette fonctionnalité) ;
- si non, utiliser un agrégateur qui intègre l’envoi de bundles privés ou un service spécialisé ;
- préparer la transaction et, si pertinent, inclure une transaction complémentaire (bundle) qui annule ou sécurise l’opération en cas d’échec ;
- soumettre le bundle via l’interface du relay et surveiller la confirmation hors mempool public ;
- documenter le coût additionnel et comparer avec le bénéfice évité (perte due aux bots).
Chaque service a sa propre interface et des règles de tarification : il est recommandé d’effectuer des tests et de lire la documentation officielle, par exemple sur Flashbots Protect.
Recommandations pour les organisations et les institutions
Les gestionnaires de trésorerie, fonds et institutions qui interagissent avec la DeFi doivent adopter une politique formalisée d’exécution :
- définir des seuils (quand recourir à des canaux privés, quand fractionner, etc.) ;
- former les traders et ingénieurs sur la détection et l’impact du MEV ;
- intégrer des outils de monitoring on‑chain aux workflows de compliance ;
- documenter les incidents et les partager, le cas échéant, avec la communauté pour améliorer collectivement les pratiques.
Une approche institutionnelle réduit les pertes et limite l’effet d’entraînement négatif sur la liquidité et la confiance des utilisateurs.
Limitations pratiques : quand la protection n’est pas nécessaire
Il est aussi important de reconnaître que toutes les transactions n’ont pas besoin d’une protection sophistiquée. Pour la majorité des utilisateurs qui effectuent des swaps modestes sur des pools profondes, les réglages standards et l’usage d’agrégateurs suffisent.
La décision doit reposer sur l’analyse coûts‑bénéfices : protéger à grand frais un trade minime peut coûter plus que ce que le MEV aurait capté. L’essentiel est d’adapter la défense à l’enjeu financier et à la sensibilité du cas d’usage.
Questions fréquentes que se pose un trader
Plusieurs questions reviennent souvent :
- « Le MEV est‑il illégal ? » — Pas systématiquement ; il s’agit d’une exploitation des règles techniques actuelles. Certaines pratiques peuvent toutefois relever de la manipulation de marché selon le cadre légal, et la réglementation évolue. Il faut suivre les avis des autorités (AMF, régulateurs européens).
- « Dois‑je systématiquement utiliser Flashbots ? » — Pas nécessairement : Flashbots est utile pour des ordres sensibles ou de grande taille. Pour des échanges courants, d’autres protections suffisent.
- « Un wallet peut‑il me protéger automatiquement ? » — Certains wallets et agrégateurs intègrent des options de protection, mais le paramétrage reste essentiel : tolérance de slippage, gas, et choix du routeur font la différence.
Les transactions sur blockchain sont publiques et rapides : cela offre des opportunités autant qu’une immense vitrine pour des bots. En combinant réglages techniques, bonnes pratiques d’exécution et recours aux outils privés lorsque cela est justifié, un trader ou un projet peut réduire significativement le risque de voir ses gains détournés.
Quels moyens un lecteur utilise‑t‑il déjà pour se protéger ? Quels scénarios restent problématiques ? Partager une expérience ou une question permettra d’orienter de futurs guides pratiques.
