Anatomie du MEV : sandwiches, frontrunning et la forêt obscure du mempool
Lorsque vous signez un swap sur un exchange décentralisé et le diffusez vers un endpoint RPC public, vous n'avez pas envoyé une instruction privée à un moteur de matching. Vous avez publié une déclaration d'intention signée et exécutable sur un tableau d'affichage mondial, et vous y avez attaché une prime — le prix du gas — pour quiconque accepte de l'exécuter. Tout le monde peut lire cette déclaration. Personne n'est obligé de l'exécuter de manière équitable, dans l'ordre, ou même de l'exécuter tout court. L'ordre dans lequel elle atterrit par rapport aux autres transactions n'est pas une propriété de votre soumission ; c'est une décision prise par un tiers qui profite de la prendre contre vous.
C'est le cœur inconfortable du trading on-chain. Dans Arbitrage statistique et pairs trading sur les marchés crypto, nous avons mentionné, en passant, que déplacer une position entre un CEX et un DEX comporte un « risque MEV », en laissant ce terme en suspens. Cet article règle cette dette. C'est la porte d'entrée d'une série sur l'économie de l'exécution on-chain, et son rôle est de définir le vocabulaire — mempool, bundle, backrun, sandwich, PBS — avec assez de précision pour que les articles suivants sur l'arbitrage atomique avec flash loans et la liquidité concentrée d'Uniswap v3 pour les quants puissent supposer que vous comprenez déjà la mécanique.
Le MEV — Maximal (ou Maximum) Extractable Value, valeur extractible maximale — est le profit qu'une partie peut extraire en choisissant l'inclusion, l'exclusion et l'ordonnancement des transactions au sein d'un bloc, au-delà de la récompense de bloc standard et des frais de priorité. Ce n'est pas un bug ; c'est une conséquence structurelle de la façon dont les blockchains permissionless ordonnent les transactions. Depuis que le mécanisme a été formellement caractérisé en 2019, la valeur cumulée extraite se chiffre en milliards de dollars, et toute une industrie — searchers, builders, relais, proposers de blocs — s'est développée pour la capturer et la redistribuer. Si vous tradez on-chain, soit vous payez cette taxe, soit vous avez pris des mesures délibérées pour l'éviter.
1. Le cycle de vie d'une transaction : pourquoi votre intention est publique
Pour voir où fuit la valeur, suivons une transaction depuis votre wallet jusqu'à un bloc finalisé.
Le mempool public
Lorsque votre wallet signe une transaction et la soumet à l'endpoint RPC d'un nœud standard, ce nœud la valide (signature, nonce, solde suffisant) et, si elle passe, la propage à travers le réseau pair-à-pair vers d'autres nœuds. Chaque nœud conserve ces transactions pas encore incluses dans un tampon local appelé le mempool (memory pool, pool de mémoire). En une seconde ou deux, pratiquement tous les nœuds du réseau — y compris des nœuds exploités par des parties dont l'activité entière consiste à extraire de la valeur des transactions en attente — détiennent une copie de votre transaction signée et entièrement décodée.
« Entièrement décodée » est l'expression clé. Votre transaction n'est pas un blob opaque. C'est un appel encodé en ABI vers un contrat connu. Quiconque surveille le mempool peut la décoder et lire, en termes clairs : cette adresse est sur le point d'échanger 40 ETH contre des USDC sur le pool Uniswap v2 WETH/USDC, et elle acceptera aussi peu que 96 000 USDC. Cette dernière clause — la sortie minimale acceptable — est votre tolérance au slippage, et ce n'est pas un indice. C'est un paramètre strict compilé dans le calldata. Nous verrons bientôt que c'est aussi la ligne budgétaire de l'attaquant.
Le mempool est parfois appelé la forêt obscure, en référence à un essai de 2020 de Dan Robinson et Georgios Konstantopoulos qui empruntait la métaphore de Liu Cixin : un espace où toute entité visible est immédiatement chassée par des prédateurs que vous ne pouvez pas voir. Diffusez une transaction naïve et profitable dans le mempool public, et elle pourrait ne jamais atteindre un bloc sous la forme que vous avez signée — un bot aura consumé l'opportunité et remodelé le bloc environnant contre vous.
Le prix du gas comme file de priorité
Le marché des frais d'Ethereum (post-EIP-1559) divise le prix du gas en un base fee protocolaire, qui est brûlé, et un priority fee (le « tip »), qui revient au proposer du bloc. Lors de la construction d'un bloc, le builder est économiquement incité à inclure les transactions qui le paient le plus. En première approximation, le mempool est une file de priorité indexée sur le tip : tip plus élevé, inclusion plus rapide.
C'est ce mécanisme qui rend l'ordonnancement achetable. Si je vois votre swap en attente et que je veux que ma transaction s'exécute immédiatement avant la vôtre, je n'ai besoin de rien pirater. Je soumets simplement une transaction qui paie un tip plus élevé. Le builder, suivant son incitation, place la mienne en premier. L'ordonnancement n'est pas une garantie d'équité fournie par le protocole ; c'est une enchère que le protocole organise, et le lot mis aux enchères est le droit d'agir sur l'information contenue dans votre transaction en attente.
Deux faits se combinent pour former l'ensemble du problème du MEV :
- Les transactions en attente sont visibles (mempool public).
- Leur ordonnancement est à vendre (enchère à priorité par tip).
Tout ce qui suit en est un corollaire.

2. Mécanique du sandwich, avec les vraies mathématiques
Le sandwich est la stratégie de MEV toxique canonique contre un swapper, et il vaut la peine de détailler l'arithmétique car les chiffres expliquent pourquoi votre réglage de slippage est le paramètre défensif le plus important que vous contrôliez.
L'invariant à produit constant
Un pool Uniswap v2 détient des réserves du token X et du token Y, et applique l'invariant
après chaque trade (en ignorant les frais pour l'instant). Si un trader vend du token X dans le pool, la nouvelle réserve X est , et pour préserver le pool doit verser
Avec les frais Uniswap v2 de 0,3 %, l'entrée est mise à l'échelle par :
La propriété clé : plus vous achetez dans une direction, pire est votre prix marginal. L'impact prix est convexe. Cette convexité est exactement ce que l'attaquant monétise.
La mise en place
Prenons un pool WETH/USDC. Pour garder des chiffres propres, supposons des réserves qui placent l'ETH à environ 2 500 USDC :
- WETH
- USDC
Vous voulez acheter des USDC avec 40 WETH (une vente de WETH dans le pool). En ignorant les frais pour l'illustration, un fill honnête dans un bloc vide vous donnerait
Le prix spot avant votre trade est USDC/WETH, donc 40 WETH « valent » 100 000 USDC au mid pré-trade. Vous recevez 99 601 — l'écart d'environ 399 USDC correspond à votre propre impact prix plus les frais. Supposons maintenant que vous fixiez une tolérance au slippage de 1 %. Le amountOutMin de votre transaction est
Ce chiffre est désormais public dans le mempool. Il indique à tout observateur : cette personne acceptera aussi peu que 98 605 USDC pour ses 40 WETH. La différence entre ce que vous obtiendriez dans un bloc propre (99 601) et votre plancher (98 605) — environ 996 USDC — est la marge que vous avez volontairement remise à quiconque vous front-run. C'est le budget de l'attaquant.
L'attaque, étape par étape
Un searcher construit trois transactions et force cet ordre au sein d'un même bloc :
1. Front-run (l'attaquant achète en premier). L'attaquant vend son propre WETH dans le pool avant vous, poussant le prix de l'USDC vers le haut (le WETH vers le bas) de sorte que lorsque votre trade atterrit, vous obtenez moins d'USDC par WETH. L'attaquant dimensionne cela de façon à ce que votre transaction respecte encore votre amountOutMin — sinon, votre swap revert et il n'y a pas de victime à sandwicher. La taille de front-run optimale est la plus grande qui vous laisse exactement à votre plancher.
Supposons que l'attaquant front-run avec 40 WETH des siens. Le pool passe à , et par l'invariant l'attaquant reçoit
laissant des réserves WETH, USDC.
2. Victime (votre swap s'exécute dans le pool dégradé). Vos 40 WETH atterrissent maintenant contre ces réserves :
Vérifions la contrainte : 98 811 > 98 605, donc votre transaction ne revert pas — vous êtes exécuté, juste dans de moins bonnes conditions. Vous avez reçu 98 811 au lieu des 99 601 que vous auriez obtenus dans un bloc propre. Vous perdez environ 790 USDC, et vous n'avez aucune idée que cela s'est produit ; votre swap a « réussi ». Le pool est désormais WETH, USDC.
3. Back-run (l'attaquant revend). L'attaquant vend maintenant les USDC qu'il a achetés à l'étape 1 de retour dans le pool — ou de manière équivalente rachète son WETH — capturant le prix élevé que votre trade a créé. En rachetant du WETH avec les ~99 601 USDC qu'il détient :
L'attaquant a dépensé 40 WETH à l'étape 1 et en a récupéré 40,32 à l'étape 3 — un profit d'environ 0,32 WETH (~800 USDC) avant gas, extrait presque entièrement de votre budget de slippage. Resserrez votre slippage et ce budget se réduit ; la taille de front-run optimale de l'attaquant diminue, et en dessous d'un certain seuil le sandwich cesse d'être profitable après le gas et le searcher vous ignore.
La leçon n'est pas « la tolérance au slippage est mauvaise ». Vous avez besoin d'une certaine tolérance, sinon vos transactions revertent au moindre mouvement de prix ordinaire. La leçon est que la tolérance au slippage est une quantité directement extractible, et la fixer à une valeur par défaut paresseuse comme 1 %, ou pire, « auto » sur un pool peu liquide, revient à laisser autant d'argent sur la table pour quiconque surveille. Sur un pool à faible liquidité où votre propre trade fait bouger le prix de plusieurs pourcents, un slippage par défaut peut céder une fraction choquante de votre notionnel.
Voici une esquisse minimale de la condition de profit d'un searcher :
def sandwich_profit(x, y, gamma, victim_dx, victim_min_out, attack_dx, gas_cost):
out1 = (y * gamma * attack_dx) / (x + gamma * attack_dx)
x1, y1 = x + attack_dx, y - out1
vout = (y1 * gamma * victim_dx) / (x1 + gamma * victim_dx)
if vout < victim_min_out:
return None # victim would revert; no sandwich
x2, y2 = x1 + victim_dx, y1 - vout
got_back = (x2 * gamma * out1) / (y2 + gamma * out1)
return got_back - attack_dx - gas_cost # profit in WETH
Le searcher exécute une petite optimisation sur attack_dx pour trouver le plus grand front-run qui maintient vout >= victim_min_out. Cet optimum est le point où votre plancher de slippage devient contraignant — ce qui revient à dire que le gain de l'attaquant est plafonné précisément par la marge que vous avez laissée.
3. Une taxonomie du MEV : toxique versus bénin
Le terme « MEV » est utilisé comme une insulte, mais il ne s'agit pas toujours d'extraction aux dépens d'une victime. Il est utile de classer les stratégies selon si quelqu'un est lésé par l'ordonnancement.
Frontrunning. Observer une transaction en attente profitable, la copier ou la devancer, et payer un tip plus élevé pour s'exécuter en premier. L'archétype consiste à voir un gros achat qui va faire bouger un prix et à acheter avant lui. Purement toxique : la victime obtient un prix moins bon, ou son opportunité lui est carrément volée.
Backrunning. Placer sa transaction immédiatement après une transaction cible pour agir sur l'état qu'elle crée. Point crucial, un backrun pur ne dégrade pas l'exécution de la cible — il s'exécute après, donc le prix de la victime est déjà verrouillé. Si votre gros swap déséquilibre le pool WETH/USDC par rapport à Binance, un arbitragiste vous backrun pour le rééquilibrer et empoche la différence. Vous n'êtes pas lésé ; en fait, cet arbitrage est ce qui maintient les prix on-chain alignés sur le marché plus large. Le backrunning est l'extrémité bénigne du spectre, et — comme nous le verrons — les systèmes modernes de protection contre le MEV sont construits précisément pour restituer le profit de backrun à l'utilisateur qui l'a créé.
Sandwiching. Un front-run et un back-run enveloppant la même victime, comme disséqué ci-dessus. Toxique par construction : le front-run n'existe que pour dégrader le fill de la victime afin que le back-run puisse le récolter.
Arbitrage atomique. Une transaction unique qui achète un actif à bas prix sur une venue et le vend cher sur une autre — disons du WETH moins cher sur Uniswap que sur Sushiswap — encaissant un profit sans risque, tout ou rien au sein d'une seule transaction (elle revert si non profitable). Pas de victime spécifique ; il s'agit de fermer un écart de prix que le marché avait laissé ouvert. Généralement considéré comme bénin — il améliore la cohérence des prix entre venues — et c'est le sujet de l'article sur l'arbitrage atomique et les flash loans de cette série, où la propriété « sans capital requis » des flash loans le rend particulièrement tranchant.
Liquidations. Lorsqu'une position de prêt (Aave, Compound, Maker) tombe en dessous de son seuil de collatéral, le protocole offre une prime à quiconque rembourse la dette impayée et saisit le collatéral. Les searchers se font concurrence pour être ce liquidateur. Il y a bien une « victime » — l'emprunteur liquidé — mais il sera liquidé selon les règles du protocole de toute façon ; la concurrence MEV détermine surtout qui obtient la prime et, par la concurrence, peut la réduire. Considérons cela comme neutre à bénin pour la santé du marché, désagréable pour l'emprunteur.
Une carte approximative :
| Stratégie | Victime lésée ? | Verdict |
|---|---|---|
| Frontrun | Oui | Toxique |
| Sandwich | Oui | Toxique |
| Backrun (pur) | Non | Bénin |
| Arbitrage atomique | Non | Bénin (améliore la cohérence des prix) |
| Liquidation | Emprunteur (selon les règles du protocole) | Neutre |
La ligne toxique/bénin importe car toute la pile moderne de mitigation du MEV est une tentative de supprimer les stratégies toxiques tout en préservant — et en redistribuant — les bénignes. On ne peut pas interdire les jeux d'ordonnancement sans aussi casser l'arbitrage qui maintient les prix des DEX honnêtes. L'astuce consiste à renvoyer la valeur toxique vers la personne à qui elle a été prise.
4. Une brève histoire : des enchères de gas à Flashbots
Flash Boys 2.0 et les enchères de gas prioritaires
Le phénomène a été nommé et mesuré dans l'article de 2019 « Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges » par Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach et Ari Juels. L'article a introduit le terme « miner extractable value » (plus tard généralisé en « valeur extractible maximale » à mesure que l'industrie passait des mineurs proof-of-work aux proposers proof-of-stake) et documenté les priority gas auctions (PGA), enchères de gas prioritaires : des bots surenchérissant les uns sur les autres sur le prix du gas, en temps réel, pour remporter l'ordonnancement d'une opportunité profitable.
Les PGA étaient visiblement pathologiques. Comme le seul levier dont disposaient les bots était le prix du gas public, ils menaient des guerres d'enchères ouvertes — resoumettant à répétition avec des tips toujours plus élevés en l'espace de quelques secondes — pour remporter un unique arbitrage ou une liquidation. Deux conséquences fâcheuses en découlaient. Premièrement, cela congestionnait le réseau et gonflait les prix du gas pour tout le monde, lié au MEV ou non. Deuxièmement, et plus alarmant encore, l'article soutenait que si le MEV disponible dans un bloc dépassait la récompense de bloc, des mineurs rationnels seraient incités à réorganiser la chaîne pour le voler, menaçant la stabilité du consensus lui-même. Le MEV n'était pas seulement un problème d'équité pour les utilisateurs ; c'était une menace pour la chaîne.
Flashbots comme réponse
Flashbots a été lancé en 2020 pour désamorcer les PGA. Son intuition : déplacer l'enchère d'ordonnancement hors du mempool public vers un canal off-chain à enchère scellée. Au lieu de diffuser une transaction et de se battre dans une guerre de gas publique, un searcher assemble un bundle — une liste ordonnée de transactions à inclure atomiquement, tout ou rien, dans un ordre relatif spécifique — et le soumet en privé à un block builder, accompagné d'une offre (souvent payée sous forme de transfert direct au proposer plutôt que via le prix du gas). Le builder assemble le bloc le plus précieux possible à partir de tous les bundles et transactions qu'il reçoit et le propose au proposer.
Deux choses s'améliorent en même temps. Les searchers cessent de spammer le mempool public avec des offres échouées, donc l'externalité sur le prix du gas pour les utilisateurs ordinaires diminue. Et le bundle gagnant atterrit intact ou pas du tout, éliminant les transactions de « front-run échoué » qui encombraient auparavant les blocs. La guerre d'enchères a toujours lieu — elle se déroule simplement comme une enchère privée à l'intérieur du builder plutôt que comme une foire d'empoigne publique on-chain.
PBS : séparation proposer-builder
L'architecture de Flashbots s'est généralisée en proposer-builder separation (PBS), séparation proposer-builder, le modèle dominant sur Ethereum aujourd'hui. Les rôles se répartissent ainsi :
- Les searchers trouvent des opportunités de MEV et les empaquettent en bundles.
- Les builders se font concurrence pour assembler le bloc complet le plus précieux à partir des bundles et des transactions publiques.
- Les relais se situent entre les builders et les proposers, recevant des blocs complets des builders et ne transmettant que les headers du bloc plus une offre de valeur au proposer, de sorte que le proposer s'engage sur un bloc avant d'en voir le contenu (empêchant le proposer de simplement voler le MEV).
- Les proposers (validateurs) choisissent le header avec l'offre la plus élevée, le signent et collectent le paiement.
Ceci est mis en œuvre hors protocole via MEV-Boost, un middleware que l'écrasante majorité des validateurs Ethereum exécutent — de l'ordre de 80 à 90 % des blocs sont construits via des builders externes par le biais de MEV-Boost. Cela fonctionne, mais cela repose sur des relais de confiance. L'étape suivante, l'ePBS enshrined (PBS inscrit dans le protocole, EIP-7732), vise à intégrer directement la séparation proposer-builder dans le protocole Ethereum et à supprimer la dépendance aux relais de confiance. À la mi-2026, elle est prévue pour la mise à niveau Glamsterdam, avec une activation mainnet ciblée plus tard en 2026, ses partisans affirmant qu'elle peut réduire substantiellement les pertes de MEV pour les utilisateurs en améliorant la façon dont les blocs sont engagés et en réduisant la fenêtre de réordonnancement toxique. Considérez les chiffres exacts comme aspirationnels tant que cela n'est pas déployé, mais la direction est claire : le protocole absorbe la chaîne d'approvisionnement du MEV qu'il a passé des années à prétendre ne pas exister.
MEV-Share : rendre la valeur
Le développement le plus déterminant pour les traders ordinaires est MEV-Share, l'enchère de flux d'ordres (order-flow auction) de Flashbots. L'idée inverse la forêt obscure. Au lieu que votre transaction soit visible par tout prédateur, vous l'envoyez en privé à un nœud MEV-Share, qui ne révèle que des indices partiels la concernant (vous choisissez à quel point) aux searchers. Les searchers enchérissent pour backrun votre transaction — rappelons qu'un backrun ne vous nuit pas — et une large fraction du profit résultant vous est remboursée, le reste étant partagé entre le searcher et le proposer pour faire inclure le bundle.
Le recadrage économique est élégant. Un gros swap crée une opportunité de backrun ; la question est de savoir qui la capture. Dans le monde de la forêt obscure, les searchers et les builders prennent tout. Sous MEV-Share, la valeur que votre propre transaction a créée vous est largement rendue. Le RPC grand public de Flashbots, Flashbots Protect, achemine les transactions retail à travers ce système, et en 2025 il a ajouté des remboursements de frais de gas par-dessus, augmentant sensiblement ce que les utilisateurs récupèrent. C'est le principe « redistribuer le bénin, supprimer le toxique » rendu concret.
5. Défenses pratiques pour un trader
Vous n'avez pas besoin de faire tourner un searcher pour cesser d'être une proie. Par ordre approximatif d'impact :
Fixer le slippage délibérément, par pool
La section 2 a établi que votre tolérance au slippage est le budget de l'attaquant. Deux règles en découlent. Premièrement, dimensionnez le slippage en fonction de la liquidité réelle du pool et de l'impact prix de votre trade, pas d'un habituel 1 %. Sur un pool profond, une tolérance de 0,1 à 0,3 % peut suffire amplement ; sur un pool peu profond, acceptez que vous ne puissiez pas trader une telle taille en toute sécurité, ou fractionnez en clips plus petits. Deuxièmement, n'utilisez jamais un slippage « auto »/« illimité » sur une paire à faible liquidité — c'est un chèque en blanc signé. Si un swap revert continuellement avec une tolérance serrée, c'est le marché qui vous dit que votre trade est trop grand pour le pool, pas une invitation à relâcher le plancher.
Passer par un RPC privé
Le correctif structurel le plus propre consiste à garder votre transaction entièrement hors du mempool public. Pointez votre wallet vers un RPC privé qui transmet les transactions directement aux builders plutôt que de les propager publiquement :
- Flashbots Protect — envoie votre transaction dans le système MEV-Share, de sorte qu'elle n'est jamais visible publiquement par les frontrunners, et restitue une part de toute valeur de backrun plus des remboursements de gas.
- MEV Blocker (par CoW Protocol et d'autres) — un service de RPC privé similaire qui protège contre le frontrunning et le sandwiching et reverse le profit de backrun aux utilisateurs, avec un modèle de frais gratuit à l'usage.
Comme un sandwich exige que l'attaquant voie votre transaction en attente et insère un front-run avant elle, retirer votre transaction du mempool public élimine purement et simplement l'opportunité de front-run. L'opportunité de backrun subsiste, mais elle vous est désormais restituée par enchère plutôt que volée. Le compromis est un peu de confiance envers l'opérateur du RPC et, occasionnellement, une inclusion marginalement plus lente — généralement dérisoire face à l'élimination du risque de sandwich. (Une étude de référence de 2025 sur les RPC de protection privée a montré que leur règlement en conditions réelles n'est pas toujours strictement meilleur que la soumission publique, donc l'effet est fort mais pas universel ; pour la plupart des swaps DEX de taille retail, le routage privé reste néanmoins le bon choix par défaut.)
Privilégier les venues à enchères par lots et basées sur l'intention
Certaines conceptions de DEX suppriment l'avantage d'ordonnancement par construction. CoW Protocol règle les trades par enchères par lots (batch auctions) avec un prix de compensation uniforme — chaque trade d'un lot se règle au même prix, il n'y a donc pas de position « première » et « dernière » à exploiter, et les solvers se font concurrence pour vous offrir la meilleure exécution plutôt que pour se réordonner autour de vous. Les systèmes basés sur l'intention, où vous signez ce que vous voulez et laissez des solvers trouver l'exécution, plutôt que de signer un chemin spécifique, privent de même le sandwich de tout point d'appui. Si vous tradez en taille, ces venues valent plus que n'importe quel ajustement de slippage.
Comprendre en quoi les L2 sont différentes
Sur la plupart des rollups Ethereum aujourd'hui (Arbitrum, Optimism, Base), les blocs sont produits par un séquenceur unique exploité par l'équipe du rollup. Il n'y a pas de mempool public de transactions en attente que les searchers pourraient surveiller, et il y a une seule partie de confiance qui décide de l'ordre. En pratique, la plupart des séquenceurs ordonnent les transactions par ordre d'arrivée (first-come-first-served) et ne mènent pas d'attaques sandwich contre leurs utilisateurs, donc le sandwiching est largement absent sur ces chaînes au niveau du protocole.
Mais lisez le compromis avec précision : la raison pour laquelle vous êtes à l'abri de l'extraction de MEV décentralisée est que vous faites confiance à un ordonnanceur centralisé pour ne pas l'extraire. Le séquenceur pourrait vous frontrun ; il choisit simplement (et est réputationnellement tenu) de ne pas le faire. C'est un équilibre temporaire. À mesure que les rollups décentralisent leurs séquenceurs — séquenceurs partagés, based sequencing, enchères de style PBS sur L2 — les mêmes dynamiques de visibilité du mempool et d'ordonnancement à vendre peuvent réapparaître, et la question du MEV sur L2 devient un problème de conception ouvert plutôt qu'un problème résolu. Ne présumez pas que « je suis sur une L2 » signifie « le MEV ne peut pas me toucher » indéfiniment ; cela signifie « une partie de confiance a promis de ne pas le faire, pour l'instant ».
Ce qu'il faut retenir pour la suite de la série
Ramenons le sujet à ses faits porteurs :
- Un swap sur mempool public, c'est une intention publique plus un créneau d'ordonnancement achetable. Cette combinaison, et non un quelconque bug isolé, est tout le problème.
- Sur un AMM à produit constant, votre tolérance au slippage est une quantité qu'un attaquant peut extraire, et le gain d'un sandwich est borné précisément par la marge que vous avez laissée. Fixer le slippage est une décision de sécurité, pas un simple réglage de confort.
- Le MEV n'est pas monolithique : les front-runs et sandwiches sont toxiques ; les backruns et l'arbitrage atomique sont bénins, voire utiles, car ils maintiennent la cohérence des prix on-chain. Une bonne mitigation supprime les premiers et redistribue les seconds.
- La réponse de l'industrie est passée des PGA (guerres de gas publiques, Flash Boys 2.0, 2019) à Flashbots / bundles / PBS (enchères privées scellées) puis à MEV-Share (restitution de la valeur de backrun à l'utilisateur) et, prochainement, au PBS enshrined dans le protocole.
- En tant que trader, vos défenses sont un slippage serré par pool, des RPC privés (Flashbots Protect, MEV Blocker) et des venues à enchères par lots — ainsi qu'une conscience que la sécurité sur L2 est actuellement une hypothèse de confiance envers le séquenceur, pas une loi physique.
L'article sur l'arbitrage atomique et les flash loans prend le point de vue du searcher dans ce tableau — comment l'extraction bénigne est construite, avec du capital emprunté et les reverts atomiques comme filet de sécurité. L'article sur la liquidité concentrée d'Uniswap v3 revisite les mathématiques du produit constant ci-dessus et montre comment la liquidité concentrée remodèle la courbe d'impact prix — et donc le budget du sandwich — que nous avons dérivée ici. Le mempool est une forêt obscure. Vous savez maintenant ce qui y chasse.
Références
- Daian, Goldfeder, Kell, Li, Zhao, Bentov, Breidenbach, Juels (2019), Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges. arXiv:1904.05234.
- Robinson & Konstantopoulos (2020), Ethereum is a Dark Forest.
- Documentation Flashbots : MEV-Boost, MEV-Share, Flashbots Protect, remboursements MEV (docs.flashbots.net).
- Ethereum PBS / EIP-7732 (séparation proposer-builder enshrined), documents de la mise à niveau Glamsterdam.
- MEV Blocker (mevblocker.io) ; conception des enchères par lots de CoW Protocol.
- Private MEV Protection RPCs: A Benchmark Study (arXiv:2505.19708, 2025).
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.