La MEV, maximal extractable value, est l'un de ces termes utilisés pour dire trois choses différentes dans la même conversation. Une partie est structurelle et nécessaire ; une partie est une taxe silencieuse, régressive, sur les utilisateurs retail ; une partie est un problème de sécurité qui détermine si votre protocole peut être utilisé en sécurité.
Cet article est l'explication qu'on donne aux fondateurs qui construisent un DEX, aux traders qui essaient de comprendre pourquoi leurs exécutions ont l'air mauvaises, et aux équipes de protocole dont les opérations price-sensibles ont besoin d'une réponse crédible à « mon protocole est-il exposé à la MEV ? »
Ce qu'est la MEV
Le mécanisme est simple. Quelqu'un, historiquement un mineur, aujourd'hui un block builder dans la séparation proposer-builder, a le droit de choisir l'ordre, l'inclusion et l'exclusion des transactions du prochain bloc. Ce droit a une valeur économique parce que l'ordre des transactions compte : mettre un achat avant l'achat de quelqu'un d'autre, ça s'exécute à un prix différent.
La MEV, c'est la valeur qu'on peut extraire en exerçant ce droit. Elle n'est pas forcément extractive pour les utilisateurs ; une partie de la MEV est de l'infra essentielle. Mais la MEV qui touche les utilisateurs tombe en trois catégories qui méritent d'être distinguées.
Catégorie 1 : MEV nécessaire
Arbitrage entre DEXes. Quand ETH/USDC trade à 3 000 $ sur Uniswap et 3 001 $ sur SushiSwap, un arbitrageur fait converger le prix en achetant bas et vendant haut. Cette MEV-là, c'est ce qui maintient les marchés décentralisés en ligne entre eux et avec la price discovery centralisée. Sans, les DEXes dériveraient sauvagement.
Liquidations de positions de prêt en mauvaise santé. Quand le collatéral d'un emprunteur tombe sous le ratio de maintenance, quelqu'un doit liquider. La MEV de la liquidation rémunère le liquidateur et protège le protocole de prêt de la dette mauvaise.
Ces activités sont compétitives mais pas extractives. Les utilisateurs en bénéficient indirectement via des spreads plus serrés et la solvabilité des protocoles.
Catégorie 2 : MEV extractive
Les sandwich attacks sont le pattern extractif canonique.
Le mécanisme :
- L'attaquant voit un swap en attente qui va bouger le prix (par exemple, un acheteur veut acheter de l'ETH).
- Il soumet son propre achat en premier, avec une priority fee plus haute, qui s'exécute avant la victime. Ça monte le prix.
- La transaction de la victime s'exécute, payant le nouveau prix (plus haut).
- L'attaquant soumet une vente immédiatement après, qui s'exécute contre l'impact prix créé par la victime.
La victime obtient une exécution pire que ce qu'elle aurait eu sans l'attaque. La différence va à l'attaquant. Le protocole ne reçoit rien. La pool ne voit aucune amélioration de price discovery.
Le front-running des updates d'oracle et des gros swaps suit le même pattern : quelqu'un exploite la visibilité des transactions en attente pour trader devant.
Ces patterns ne sont pas de l'infra nécessaire. C'est une taxe régressive sur les utilisateurs assez visibles dans la mempool pour être pris.
Catégorie 3 : MEV toxique
La manipulation d'oracle combinée à des flash loans est la catégorie la plus dangereuse. Un attaquant utilise la machinerie MEV, transactions atomiques, visibilité de la mempool, pour drainer entièrement un protocole. Pas de l'extraction à la marge ; de l'exploitation.
La défense n'est pas au niveau MEV ; elle est au niveau du design du protocole, comme couvert dans notre post sur la manipulation d'oracle.
Ce que les utilisateurs perdent
Les chiffres varient par écosystème et tooling, mais l'ordre de grandeur est significatif.
Un utilisateur retail qui swap quelques milliers de dollars sur une pool Uniswap publique via une UI DEX par défaut, avec slippage par défaut, paie régulièrement 10 à 50 points de base à la MEV. Sur un swap de 10 000 $, c'est 10 à 50 $. Composé sur de nombreux trades, ça finit par représenter une part significative du volume tradé capturée par les bots de sandwich.
Les gros utilisateurs (desks institutionnels, opérations de trésorerie) perdent souvent plus en absolu. Un swap de 5 M$ avec slippage par défaut sur une mempool publique peut perdre des dizaines de milliers de dollars à la MEV en une seule transaction.
Ce n'est pas catastrophique, mais c'est une taxe continue. Et, surtout, c'est largement évitable.
Ce que les utilisateurs peuvent faire
Les mitigations existent et ne sont pas techniquement difficiles.
Utilisez une mempool privée
Flashbots Protect, MEV Blocker et services similaires routent votre transaction directement vers les block builders sans la diffuser publiquement. Les bots de sandwich ne peuvent pas sandwicher ce qu'ils ne voient pas.
Sur MetaMask, c'est un changement de RPC unique. Les autres wallets ont des réglages similaires. Le coût, c'est la sensibilisation à l'option.
Réglez un slippage réaliste
Un pattern UI courant, c'est « tolérance de slippage : 50 % » parce que la transaction par défaut a échoué une fois et l'utilisateur a remonté sans réfléchir. 50 % de slippage, c'est une invitation explicite : prenez jusqu'à la moitié de la valeur du trade en MEV.
Le slippage réaliste pour la plupart des pools est 0,1 à 1 %. Le remonter doit être un choix délibéré basé sur la profondeur réelle, pas une UI par défaut qu'on a cliquée pour s'en débarrasser.
Tradez sur des protocoles à enchères groupées
CoW Swap, l'intégration CowSwap-style de Balancer, 1inch Fusion, les protocoles qui groupent les trades et matchent à un prix uniforme dans chaque batch éliminent les sandwich attacks structurellement. Ils donnent aussi en moyenne une meilleure exécution.
Évitez de trader depuis un wallet visiblement riche
Si le même wallet qui détient huit chiffres d'ETH fait un swap de 10 M$ sur un DEX public, les bots de sandwich vont l'optimiser spécifiquement. Une séparation opérationnelle entre trésorerie et trading aide ; on couvre l'architecture dans Wallet Setup.
Ce que les protocoles peuvent faire
Si vous opérez un DEX ou tout protocole avec des opérations price-sensibles, la MEV fait partie de votre modèle de menace.
Mettez par défaut les utilisateurs en exécution protégée. Une UI de DEX qui route par défaut en mempool privée capture moins de son volume pour les bots. La friction est petite ; le bénéfice utilisateur est grand.
Utilisez des limites de slippage, pas des tolérances utilisateur, pour les opérations protocole-internes. Liquidations, rebalances automatiques, opérations alimentées par oracle doivent avoir des caps stricts dans le contrat, pas des paramètres réglés par l'utilisateur.
Surveillez votre propre qualité d'exécution. Un protocole dont les opérations de trésorerie se font régulièrement sandwicher, c'est un protocole dont la trésorerie saigne sur la MEV, et qui devrait donc faire ces opérations en mempool privée ou via enchères groupées.
Traitez la MEV dans votre audit. Un Smart Contract Audit sérieux considère la MEV comme une menace. Spécifiquement : quelles opérations sont price-sensibles, peuvent-elles être sandwichées, quelle est la perte maximale ?
Où ça va
Le paysage MEV change plus vite que la plupart des sujets de sécurité. Séparation proposer-builder, mempools chiffrées, schémas de chiffrement à seuil, batching au niveau application, les mitigations cryptographiques et protocolaires mûrissent.
Pour les équipes de protocole, la posture pratique :
- Supposez que vos utilisateurs sont exposés par défaut.
- Faites en sorte que l'exécution protégée soit le chemin de moindre résistance.
- Traitez la MEV comme un sujet de sécurité, pas un « souci de trader ».
Pour les utilisateurs, la posture pratique :
- Utilisez une mempool privée.
- Réglez un slippage réaliste.
- Utilisez des protocoles construits pour l'exécution protégée quand la taille du trade est significative.
Le coût de la sensibilisation est faible. Le coût de l'inattention se compose à chaque trade.