Révision technique du 6 septembre 2026. Contenu éducatif : les exemples chiffrés sont hypothétiques, et ne constituent ni des cotations ni des recommandations d’investissement.
Le MEV des swaps permet de comprendre pourquoi un swap sur un DEX peut aboutir à un résultat moins favorable que prévu alors que le portefeuille affiche une transaction réussie. Cela ne signifie pas que chaque différence de prix révèle une attaque. Liquidité, frais, variations du marché et ordre des transactions produisent des effets distincts. Les séparer est plus utile que de se fier à une simple étiquette de protection.
Ce guide concerne principalement les swaps et leur exécution sur Ethereum. Pour le fonctionnement général des échanges décentralisés, consultez notre guide des DEX crypto. Les autres réseaux peuvent organiser différemment la transmission et le classement des transactions : une configuration RPC ou une promesse commerciale ne s’applique pas automatiquement à toutes les blockchains.
MEV des swaps : de quoi parle-t-on ?
MEV désigne la Maximal Extractable Value, c’est-à-dire la valeur accessible en intervenant sur l’inclusion, l’exclusion ou l’ordre des transactions, au-delà des récompenses et frais habituels de production des blocs. La documentation Ethereum sur le MEV présente notamment l’arbitrage, les liquidations et les attaques sandwich.
L’idée économique est simple : deux séquences contenant des opérations similaires peuvent répartir la valeur différemment. Acheter avant un ordre qui déplace le prix d’un pool n’offre pas les mêmes conditions qu’acheter après. Pour une personne qui souhaite seulement échanger des tokens, l’essentiel est de savoir combien elle reçoit et quelles conditions elle a autorisées.
Un résultat défavorable n’identifie toutefois pas son responsable. Observer un autre swap près du sien dans un bloc ne prouve pas un sandwich. Une analyse sérieuse examine le sens des échanges, les pools utilisés, leur ordre effectif, les changements de réserves et les liens entre les opérations suspectées.
Qui intervient entre la signature et la confirmation ?
Le portefeuille prépare et signe une opération, puis un canal de transmission la communique à l’infrastructure du réseau. Dans l’écosystème Ethereum, des searchers recherchent des opportunités, des builders peuvent assembler des blocs et des proposers participent à leur proposition selon le mécanisme de consensus. Ces fonctions ne sont pas simplement un autre nom pour le DEX, et ne correspondent pas nécessairement à une seule organisation.
Du point de vue de l’utilisateur, trois questions comptent : qui voit la demande avant sa confirmation, qui la transmet et quel chemin est utilisé si la première tentative n’aboutit pas ? Le nom d’un agrégateur affiché à l’écran ne répond pas toujours à ces trois questions.
Cette distinction aide aussi à diagnostiquer une transaction en attente. Le problème peut concerner les frais, le nonce, la disponibilité du chemin ou les contraintes de l’ordre. Augmenter la tolérance de prix sans identifier la cause modifie la protection du swap, mais ne résout pas nécessairement ce qui empêche son inclusion.
Slippage, impact sur le prix et frais : trois notions distinctes
L’impact sur le prix décrit l’effet de votre propre échange sur les conditions offertes par la liquidité utilisée. Un ordre important par rapport à la taille du pool peut obtenir un taux moyen moins favorable même si personne d’autre n’intervient. L’explication d’Uniswap sur le price impact met précisément en relation la taille de l’échange et la profondeur de la liquidité.
Le slippage désigne l’écart entre un résultat attendu et celui de l’exécution, selon le point de référence choisi par l’interface. La tolérance constitue une limite autorisée, pas une commission automatiquement prélevée. Une tolérance large ne provoque pas obligatoirement une mauvaise exécution, mais peut permettre un résultat nettement inférieur à l’estimation initiale.
Les frais doivent être comparés séparément. Les frais de gas Ethereum, les commissions du pool et les frais éventuels du service ne sont pas toujours présentés de la même manière. Un chemin promettant davantage de tokens peut être moins intéressant après les coûts supplémentaires ; inversement, le chemin le moins cher en gas peut proposer un moins bon taux de change.
| Élément | Question à poser | Erreur à éviter |
|---|---|---|
| Impact sur le prix | Quel poids représente cet ordre dans la liquidité disponible ? | Tout attribuer à un attaquant |
| Tolérance de slippage | Quel résultat minimal suis-je en train d’autoriser ? | La confondre avec une commission fixe |
| Frais | Quels coûts sont compris dans cette estimation ? | Comparer des devis reposant sur des hypothèses différentes |
| Inclusion | Que se passe-t-il si l’ordre reste en attente ? | Assouplir les limites sans diagnostic |
Exemple chiffré : lire le montant minimal reçu
Supposons qu’une interface estime une sortie de 1 000 unités du token de destination. Pour cet exemple pédagogique, nous définissons explicitement le minimum comme l’estimation multipliée par un moins la tolérance. Avec 1 %, le minimum vaut 990 ; avec 5 %, il vaut 950. Ce n’est pas une formule universelle pour chaque SDK ou type d’ordre : dans une opération réelle, il faut lire le montant effectivement affiché et signé.
Si l’exécution livre 992 unités, l’écart par rapport au devis est de huit unités, soit 0,8 %. Dans notre modèle, les deux limites sont respectées. Avoir choisi une tolérance de 5 % ne signifie donc pas avoir automatiquement payé 50 unités : l’écart autorisé et l’écart réalisé sont deux valeurs différentes.
Si la sortie disponible baisse à 975, elle ne respecte plus un minimum de 990, mais reste supérieure à 950. En supposant un swap atomique et un contrat qui applique correctement le minimum, le premier ordre ne devrait pas s’exécuter à ce résultat. Cela ne rend pas tous les échecs gratuits : une transaction incluse puis annulée par un revert peut consommer du gas.
L’exemple ne démontre ni une attaque ni le bénéfice d’un attaquant. Il sépare uniquement estimation, minimum et résultat réel. Pour mesurer un sandwich, il faudrait aussi reconstruire une exécution crédible sans l’intervention suspectée, puis prendre en compte les commissions et les autres transactions pertinentes.
Un second exemple : le prix change sans attaquant
Considérons un pool de liquidité fictif contenant 100 unités du token A et 200 000 unités du token B. Nous supposons une courbe à produit constant, aucun frais, aucune autre transaction et des tokens ordinaires sans mécanisme particulier de transfert. Le rapport initial vaut 2 000 B pour un A, mais ce n’est pas un prix moyen garanti pour n’importe quelle quantité.
L’ajout d’une unité de A porte sa réserve à 101. Pour conserver le produit initial de 20 000 000, la réserve de B devient environ 198 019,802. Le swap restitue donc environ 1 980,198 B, et non 2 000. L’écart d’environ 0,99 % avec le rapport initial provient ici de la courbe, sans attaque sandwich.
Il s’agit d’un calcul simplifié, pas d’une cotation Uniswap. Les pools réels peuvent facturer des frais, utiliser une liquidité concentrée ou une autre fonction de prix, et recevoir des transactions entre le devis et l’exécution. La documentation du pricing Uniswap v2 distingue le calcul de la sortie des précautions nécessaires avant de considérer le prix du pool comme équitable.
L’intérêt du calcul est diagnostique : réduire la tolérance ne supprime pas l’impact déjà présent dans le devis. Il faut d’abord évaluer la qualité de cette cotation, puis décider de l’écart ultérieur acceptable. Confondre ces étapes peut donner une apparence de prudence à un ordre dont les conditions initiales sont déjà défavorables.
Comment une attaque sandwich modifie l’exécution
Dans un sandwich typique, un acteur place une opération avant le swap ciblé et une autre après, afin de profiter du déplacement de prix dans le pool. L’utilisateur peut recevoir moins que prévu tout en respectant le minimum autorisé. L’opportunité dépend des conditions concrètes, et pas seulement de la valeur nominale de l’ordre.
Une liquidité faible et des limites très permissives peuvent accroître cette exposition. Une liquidité importante n’est pourtant pas une assurance, et une limite serrée n’est pas une solution complète. Des contraintes plus strictes peuvent aussi multiplier les tentatives non exécutées lorsque les conditions changent ; il faut considérer le chemin et le coût des nouvelles tentatives.
Pour une vérification ultérieure, conservez le devis avec son heure, le minimum signé et le hash de la transaction. Comparez l’exécution à ce devis contemporain, pas à un cours consulté beaucoup plus tard. Si l’état antérieur du pool manque, une estimation du préjudice doit reconnaître cette limite plutôt que d’afficher une précision artificielle.
Arbitrage et liquidations ne se confondent pas avec le sandwich
Un arbitrage exploite une différence de prix entre marchés. Une liquidation peut appliquer les règles d’un prêt lorsque les garanties sont insuffisantes. Ces mécanismes diffèrent de la dégradation intentionnelle d’un swap encadré par deux opérations. Les regrouper sous le terme MEV ne signifie pas qu’ils ont les mêmes effets sur chaque utilisateur.
La question utile n’est pas seulement de savoir si quelqu’un a gagné de l’argent, mais comment et aux dépens de qui. Un bénéfice observé ne démontre pas automatiquement une perte équivalente pour un portefeuille précis. Les statistiques agrégées de MEV exigent également une méthode explicite avant de servir à estimer un préjudice individuel.
Routage privé : moins de visibilité publique, mais toujours de la confiance
Un canal privé peut éviter la diffusion ordinaire de la transaction dans le mempool public. Cela change qui peut la voir avant son inclusion, mais ne signifie pas que personne ne la voit. Le service et les destinataires autorisés font partie des acteurs auxquels l’utilisateur doit accorder sa confiance.
Le guide de démarrage de Flashbots Protect précise cette confiance envers les builders : ils ne doivent ni anticiper la transaction ni la divulguer à des tiers. Il avertit aussi qu’un changement de RPC dans MetaMask avant confirmation peut provoquer une nouvelle diffusion vers le mempool public. C’est une condition d’exécution importante, pas une simple préférence d’affichage.
Avant d’utiliser un service, vérifiez réseau pris en charge, méthode de transmission, destinataires et traitement des demandes en attente. Comparez les endpoints avec la documentation officielle, plutôt qu’avec des messages privés ou des annonces. Configurer un canal de transmission ne nécessite pas de communiquer sa phrase de récupération.
Paramètres, remboursements et chemin de secours
La documentation des paramètres Protect consultée pour cette révision distingue configuration par défaut, mode fast et options de partage. Ajouter des destinataires peut favoriser l’inclusion, mais étend le cercle de confiance. Les différentes options de partage ne représentent pas des garanties de confidentialité identiques.
La documentation permet aussi des réglages concernant les transactions reverties et la plage de blocs pendant laquelle l’inclusion est tentée. Le comportement par défaut ne doit donc pas devenir une promesse inconditionnelle valable pour toute configuration. Un remboursement éventuel ne doit pas non plus être présenté comme un rendement certain ou comme la preuve que le swap était avantageux.
Notez les conditions avant de comparer deux chemins. Si un portefeuille ou un service change automatiquement de mode, vérifiez si l’exposition des informations change aussi. Le nom commercial peut rester identique alors que le chemin effectif ou les destinataires ne sont plus les mêmes.
Intentions et enchères : les conditions signées restent essentielles
Un intent exprime des conditions de négociation plutôt que de décrire directement chaque étape d’exécution. La documentation de CoW Protocol sur les intents présente l’ordre signé comme un ensemble de contraintes, distinct d’une transaction utilisateur directement exécutable.
Cette séparation permet à des participants spécialisés de rechercher une exécution compatible avec les contraintes. Elle ne rend pas la signature anodine : actifs, montants, destinataire, échéance et permissions doivent rester corrects. Une demande de signature de message sans paiement immédiat de gas ne prouve pas que l’action est dépourvue de conséquences.
Les produits décrits comme intent-based ou auction-based peuvent suivre des règles différentes. Il faut lire la procédure d’annulation propre au service et, lorsqu’il autorise des exécutions partielles, distinguer un ordre expiré d’un ordre partiellement exécuté. Une catégorie technique ne constitue pas une garantie uniforme de meilleur prix.
Diviser un gros ordre : un compromis, pas une défense universelle
La version précédente recommandait de fragmenter les gros ordres comme protection générale. Cette formulation était trop large : fractionner ne garantit ni moins de MEV ni une meilleure exécution globale. Si la liquidité ne change pas et que les swaps suivent la même courbe, multiplier les clics ne crée pas une nouvelle profondeur.
Prenons un exemple purement comptable : quatre transactions coûtant chacune trois euros de frais de réseau hypothétiques représentent douze euros, contre trois euros pour un seul envoi au même coût unitaire. Les neuf euros supplémentaires doivent être compensés par un avantage réel. Ces montants sont pédagogiques, pas une estimation du gas Ethereum.
Étaler les échanges expose aussi le montant restant aux mouvements de marché entre les tranches. Une comparaison pertinente porte sur l’ensemble de l’ordre, les frais cumulés et le temps écoulé. Ne retenir que la meilleure tranche sélectionne un résultat favorable tout en masquant les autres exécutions.
Une checklist adaptée à la transaction avant de signer
- Vérifiez le réseau et l’adresse des tokens : des symboles similaires ne désignent pas nécessairement le même actif.
- Contrôlez le bénéficiaire de l’autorisation et son montant. N’accordez pas de permissions que vous ne comprenez pas.
- Lisez montant d’entrée, estimation de sortie et minimum effectif, pas seulement le pourcentage de tolérance.
- Séparez frais de réseau, commissions du pool et coûts éventuels du service.
- Contrôlez le chemin de transmission et les conditions de protection, y compris si l’ordre reste en attente.
- Vérifiez échéance, exécutions partielles et méthode d’annulation lorsque ces options s’appliquent.
- Relisez la confirmation finale : un devis actualisé peut modifier le chemin ou la sortie attendue.
Cette checklist ne certifie pas la sécurité du token ou du contrat. Elle rend explicites les conditions d’une opération. Un routeur réputé ne transforme pas tous les tokens en actifs sûrs, et une limite de prix ne protège pas contre toutes les autorisations malveillantes.
Pour comparer deux devis, enregistrez le même montant initial, le token de destination, l’heure et les hypothèses de frais. Un devis obtenu plusieurs minutes auparavant n’est pas une référence fiable si le marché a bougé. Distinguez coûts estimés et coûts payés, et précisez si les quantités sont nettes des frais du service : ce relevé rend le rapprochement reproductible, sans prédire quel chemin sera préférable la prochaine fois.
Que vérifier après le swap ?
Contrôlez l’état de la transaction et les quantités réellement reçues. La réussite technique indique que l’exécution respecte les règles applicables, pas qu’elle représente le meilleur prix disponible sur tous les marchés. Les informations conservées au moment de la signature permettent de rapprocher le résultat des conditions acceptées.
Si l’opération reste en attente, ne la répétez pas aveuglément. Distinguez une transaction non incluse d’un ordre expiré, d’un revert ou d’un affichage lent. Suivez les instructions du portefeuille et du chemin utilisés : un nouvel essai ou un remplacement peut changer les coûts et la visibilité.
En cas de soupçon de sandwich, rassemblez hashes, heures et devis original avant de conclure. Ne publiez jamais phrase de récupération, clés ou exports sensibles pour demander de l’aide. Les informations publiques et les conditions du swap sont des preuves utiles ; le contrôle de votre portefeuille n’est pas nécessaire à une analyse technique ordinaire.
Questions fréquentes sur la protection contre le MEV
Une tolérance nulle résout-elle le problème ?
Non. Elle peut empêcher certaines exécutions sous le devis, mais aussi empêcher l’opération quand les conditions changent. Elle n’améliore pas une cotation initiale défavorable, ne supprime pas les frais et n’élimine pas le risque du contrat.
Un swap échoué prouve-t-il une attaque ?
Non. Plusieurs contraintes techniques peuvent provoquer un échec. Une attribution nécessite des preuves : un message générique du portefeuille et un mouvement de prix défavorable ne suffisent pas à eux seuls.
Une transmission privée rend-elle le swap anonyme ?
La diffusion limitée avant inclusion n’est pas l’anonymat. Elle ne supprime pas les informations inscrites on-chain et n’implique pas que le fournisseur ne reçoit aucune donnée. Examinez les règles de visibilité du service précis.
Quel chemin choisir pour tous les swaps ?
Il n’existe pas de réponse universelle. Montant, liquidité, frais, urgence et contraintes du produit changent la comparaison. Une décision défendable expose ces hypothèses au lieu de les remplacer par une étiquette de protection.
Conclusion : contrôler l’exécution plutôt que chercher une garantie absolue
Comprendre le MEV des swaps revient à lire un swap comme un ensemble de conditions : devis, sortie minimale, chemin, permissions et coûts. Des contrôles utiles distinguent ces éléments et permettent de comparer ce qui a été signé avec ce qui s’est réellement produit.
Les protections peuvent réduire certaines expositions, mais conservent des limites et des dépendances. Vérifiez le minimum reçu et le canal de transmission avant de signer, puis conservez le résultat pour une comparaison cohérente. L’objectif n’est pas une promesse de risque nul, mais une compréhension du risque qui subsiste.
