Passer au contenu principal

Qu'est-ce que le MEV (valeur maximale extractible) et comment protéger vos transactions sur Solana ?

Mis à jour le
16 juin 2026
Profil d'Aaron Milano
Aaron Milano
Tout
Solana
SVM
MEV
DeFi
Produits Quicknode
Marketplace

12 minutes de lecture

Aperçu​

Pour les développeurs qui créent des applications DeFi et des bots de trading sur Solana, il est essentiel de bien comprendre le MEV (Maximal Extractable Value, ou valeur maximale extractible). Le MEV peut avoir un impact sur l’exécution des transactions de vos utilisateurs ou menacer la rentabilité de votre propre bot. Une exposition au MEV non protégée entraîne souvent une augmentation des coûts, une baisse des bénéfices et une friction accrue sur le réseau. Ce guide aborde les principes fondamentaux du MEV sur Solana, notamment les mécanismes du flux de transactions, les types courants de MEV et les risques croissants pour les développeurs qui développent sur ce réseau. Vous découvrirez des stratégies clés pour atténuer les effets négatifs du MEV et protéger vos transactions contre toute manipulation.


Introduction au MEV sur Solana​

La « valeur maximale extractible » (MEV) désigne la valeur maximale pouvant être tirée des transactions des utilisateurs en les réorganisant, en les incluant ou en les excluant d’un bloc. Dans un réseau de type « Proof-of-Stake » comme Solana, le validateur, qui est également le producteur de blocs, a la possibilité de décider quelles transactions seront incluses dans ce bloc et dans quel ordre. Cela signifie qu’un producteur de blocs malveillant ou motivé par le profit pourrait réorganiser les transactions (ou en insérer de ses propres) afin de réaliser des profits d’arbitrage, de devancer les utilisateurs ou de tirer profit d’une autre manière de l’ordre des transactions. Bien que Solana ne dispose pas d’un mempool public comme Ethereum, la MEV existe bel et bien — souvent via la connectivité directe entre nœuds, des mempools privés ou d’autres infrastructures spécialisées.

Pour les développeurs qui créent des bots de trading ou des bourses décentralisées (DEX), ne pas tenir compte du MEV peut entraîner :


  • Une exécution des ordres moins efficace (par exemple, les « attaques en sandwich »).
  • Perte de bénéfices (des bots qui anticipent vos transactions).
  • Problèmes de congestion du réseau (qui affectent la capacité à valider vos transactions sur le réseau).

L'activité DeFi sur Solana a connu un essor fulgurant en 2024, entraînant dans son sillage une croissance tout aussi spectaculaire du MEV. Messari illustre l'évolution dans le temps de la valeur économique réelle (frais + MEV) de Solana :

Messari - Activité économique totale de Solana Source :Messari : État des lieux de Solana – 4e trimestre 2024

Bien que la plupart des opérations de MEV soient d'un montant relativement modeste, il existe d'innombrables exemples où des transactions sont extraites pour des dizaines de milliers de dollars (voir la capture d'écran ci-dessous), voire des cas de transactions s'élevant à plusieurs millions de dollars.

Jito - Explorateur d'arbitrage Source : Jito - Arbitrage Explorer

Pour les développeurs qui créent des applications DeFi et des bots de trading sur Solana, il est essentiel de bien comprendre le MEV. Le MEV peut avoir un impact sur l'exécution des transactions de vos utilisateurs (en provoquant un slippage inattendu ou des transactions échouées) et même sur la rentabilité de votre propre bot si un concurrent parvient à intercepter ou à réorganiser vos transactions. Récapitulons quelques principes fondamentaux concernant le flux des transactions sur Solana, passons en revue les types courants de MEV sur Solana et discutons des mesures que vous pouvez prendre pour protéger vos transactions contre le MEV.

Flux des transactions sur Solana​

Le pipeline de transactions de Solana présente certaines différences majeures par rapport à celui d'Ethereum, qui influencent la manière dont le MEV se manifeste :

  • Pas de mempool global : contrairement à Ethereum, Solana ne dispose pas d’un mempool public unifié où les transactions en attente sont stockées en attendant d’être incluses. À la place, Solana utilise le protocole Gulf Stream pour transmettre les transactions directement au prochain leader de bloc prévu (validateur) avant que ce ne soit son tour de produire un bloc. Cela signifie qu’il n’existe pas de pool durable de transactions en attente visibles que les bots pourraient surveiller à l’échelle du réseau. Chaque transaction Solana inclut un hash de bloc récent et expire après environ 150 slots (environ 1 minute) si elle n’est pas confirmée. En résumé, les transactions sont soit rapidement prises en charge par un leader, soit abandonnées — elles ne persistent pas dans un mempool. Cela réduit les possibilités pour les stratégies de MEV consistant notamment à observer et à devancer les transactions publiques en attente, bien que les chercheurs déterminés pallient cela en exploitant leurs propres nœuds pour voir les transactions au fur et à mesure de leur arrivée.

  • Qualité de service (QoS) pondérée par la mise : Solana hiérarchise le trafic de transactions entrant en fonction de la mise. Les validateurs allouent la majeure partie de leur capacité d'entrée aux clients/retransmetteurs proportionnellement au poids de leur mise. Concrètement, cela signifie que les transactions provenant de nœuds disposant d'une mise importante, ou transitant par ceux-ci, ont moins de chances d'être rejetées en période de congestion. La QoS pondérée en fonction de la mise agit comme un mécanisme de résistance aux attaques de Sybil : les paquets des spammeurs ne disposant d’aucune mise sont déprioritisés, tandis que les transactions transitant par des validateurs disposant d’une mise importante bénéficient d’un traitement plus rapide.

  • Frais de priorité (marchés locaux des frais) : Solana utilise les frais de priorité comme des frais supplémentaires facultatifs que les utilisateurs peuvent ajouter à leurs transactions afin d’augmenter leurs chances d’être traitées rapidement lorsque le réseau est saturé. En temps normal, les transactions Solana sont soumises à des frais forfaitaires très bas, mais lorsque le trafic intense (par exemple, lors de la frappe de NFT ou d’une frénésie d’échange de memecoins) entraîne une congestion, les utilisateurs peuvent définir un frais de priorité par unité de calcul afin, en substance, d’enchérir pour obtenir de l’espace dans un bloc. Les validateurs perçoivent 50 % de ces frais de priorité et les 50 % restants sont brûlés conformément aux règles du protocole (bien que cela puisse changer via le processus SIM de Solana) ; ainsi, des frais de priorité plus élevés augmentent les chances qu’un validateur inclue votre transaction. Les frais de priorité ont été conçus pour lutter contre le spam et permettre aux transactions urgentes de « passer devant » dans la « file d’attente ». Sur Solana, cela crée un marché local des frais par unité de calcul et par bloc. En 2024, les frais de priorité constituent une part importante des recettes totales de Solana issues des frais, ce qui souligne à quel point les utilisateurs enchérissent effectivement pour obtenir la priorité en cas de congestion. Pour les développeurs, cela signifie que dans un bloc saturé, votre transaction aura probablement besoin d’un frais de priorité pour l’emporter sur les spammeurs ou les transactions concurrentes.

Types courants de MEV sur Solana​

Voici les types de MEV les plus courants que les développeurs Solana doivent connaître :

Arbitrage​

L'arbitrage est l'une des formes les plus courantes de MEV sur Solana. L'arbitrage consiste généralement à acheter et vendre de manière simultanée le même actif sur plusieurs bourses. L'arbitragiste effectue un achat sur le marché où le prix est le plus bas et une vente sur celui où le prix est le plus élevé, empochant ainsi la différence. Par exemple :

- $199 (Bot buys 1 SOL for 199 USDC on DEX A)
+ $200 (Bot sells 1 SOL for 200 USDC on DEX B)
-------------------------------------------------
+ $1   (Bot net gain $1)

Comme Solana permet de regrouper plusieurs instructions au sein d'une même transaction, les utilisateurs recourent souvent à l'arbitrage atomique (les deux volets de la transaction étant effectués au sein d'une seule transaction) afin de s'assurer que l'opération est effectivement sans risque. Les transactions qui échouent entraînent la perte des frais de priorité pour l'acheteur ; celui-ci doit donc trouver un équilibre entre la taille de l'opportunité et le marché des frais de priorité.

La concurrence en matière d'arbitrage sur Solana est féroce : les bots inondent le réseau de transactions visant à réaliser des opérations d'arbitrage. Les faibles frais de Solana permettent aux bots d'effectuer un volume élevé de transactions d'arbitrage ; même si la plupart échouent ou ne génèrent aucun profit, les rares succès peuvent s'avérer rentables. En effet, on estime que plus de 50 % des transactions sur Solana sont en réalité des tentatives d'arbitrage infructueuses (spam) : des bots tentent aveuglément de tirer parti des écarts de prix (Référence : Solana MEV - An Introduction). Bien que cela puisse poser un problème de congestion du réseau, cela signifie généralement que les prix parviennent à rester équilibrés entre les différentes plateformes DeFi.

Les attaques au sandwich​

Une « attaque en sandwich » est une stratégie classique de MEV négatif qui a également fait son apparition sur Solana. Lors d’une telle attaque, la transaction d’un utilisateur victime est « prise en sandwich » entre deux transactions de l’attaquant : l’une exécutée juste avant celle de la victime, et l’autre juste après. Supposons qu’un utilisateur soumette un swap important sur un DEX ; un chasseur de MEV qui apprend l’existence de ce swap en attente peut rapidement soumettre son propre ordre d’achat du même actif juste avant la transaction de l’utilisateur (ce qui fait grimper le prix), puis laisser l’ordre d’achat important de l’utilisateur s’exécuter (au prix désormais plus élevé), et enfin, vendre immédiatement l’actif juste après la transaction de l’utilisateur à ce prix gonflé. L’attaquant réalise un bénéfice en achetant à bas prix et en revendant plus cher, tandis que la victime obtient un prix moins avantageux pour son échange (glissement de prix plus important).

En tant que développeur ou trader, vous devez savoir que si un tiers peut observer votre swap avant qu'il ne soit finalisé, il pourrait tenter de le « sandwich ». Les tolérances élevées en matière de slippage définies par les utilisateurs les rendent particulièrement vulnérables : si un utilisateur autorise un slippage allant jusqu'à 5 %, un bot de « sandwich » peut exploiter la majeure partie de cette marge pour en tirer profit. Pour atténuer le slippage et le risque de « sandwich », il faut maîtriser le slippage, la confidentialité et le contrôle des ordres.

Liquidations​

Les liquidations constituent une autre opportunité importante de MEV, en particulier dans les protocoles de prêt DeFi de Solana (par exemple, Marginfi, Kamino, Save, etc.). Lorsque la valeur des garanties d’un emprunteur tombe en dessous du ratio requis (c’est-à-dire que son prêt est sous-garanti), cette position devient susceptible d’être liquidée. Les liquidateurs (généralement des bots) peuvent rembourser tout ou partie du prêt pour le compte de l’emprunteur et, en contrepartie, récupérer une partie des garanties à prix réduit. Cela génère essentiellement un bénéfice pour le liquidateur, puisqu’il achète les garanties à un prix inférieur à celui du marché.

Les bots de recherche de MEV analysent en permanence l'état de la chaîne et les flux de prix des oracles afin de détecter les positions sur le point d'être liquidées. Lorsqu'ils en trouvent une, ils se précipitent pour envoyer la transaction de liquidation afin de s'approprier la prime. Sur Solana, en l’absence de mempool public, les bots de liquidation veillent plutôt à être aussi rapides que possible pour détecter tout changement sur la chaîne (comme une baisse des prix fournie par un oracle ou un facteur de santé dépassant un seuil), puis envoient immédiatement une transaction de liquidation au leader du moment. Si plusieurs bots tentent de liquider le même compte, seul le premier à être inclus dans le bloc remporte la récompense, tandis que les transactions des autres échouent. Les liquidations sont considérées comme essentielles à la santé du protocole (elles préviennent les créances irrécouvrables).

Les « Jito Bundles » et autres applications MEV​

Le paysage du MEV sur Solana évolue, et les « bundles » de Jito ont joué un rôle majeur dans la manière dont le MEV est extrait (et potentiellement atténué). Les validateurs exécutant le client Jito-Solana participent à un marché hors-chaîne de construction de blocs. Les chercheurs envoient des lots de transactions (ainsi que les pourboires associés) directement à ces constructeurs de blocs plutôt qu’au réseau « gossip » habituel de Solana. Le producteur de blocs inclut alors dans le bloc les lots les mieux rémunérés, ce qui lui permet de percevoir le pourboire. Ce système permet aux chercheurs de MEV de mettre en œuvre des stratégies telles que l’arbitrage, les liquidations et le « sandwiching » en toute confidentialité (leurs transactions ne sont pas rendues publiques tant qu’elles ne sont pas incluses) et de manière prioritaire, à condition qu’ils versent un pourboire compétitif. Il en résulte une source de revenus importante pour les validateurs de Solana. La majeure partie du MEV malveillant sur Solana provient de mempools exploités de manière privée.

Les risques liés au MEV pour les développeurs de Solana​

Le MEV présente plusieurs risques et défis pour les développeurs sur Solana, en particulier ceux qui créent des bots de trading ou des applications DEX :

  • Réorganisation des transactions par les validateurs: les validateurs Solana pouvant organiser les transactions au sein des blocs qu’ils produisent, un validateur pourrait réorganiser les transactions à son avantage. Par exemple, si votre transaction sur un DEX offrait une opportunité d’arbitrage, un validateur pourrait insérer sa propre transaction avant la vôtre afin de s’approprier ce profit. Cela pourrait entraîner un résultat moins favorable pour votre transaction, voire son échec (si l’opportunité a disparu). L'ordre d'exécution des transactions peut avoir un impact considérable sur les résultats dans la DeFi, et sans protection, vos transactions sont à la merci des motivations du producteur de blocs.

  • Spam et congestion du réseau: un volume considérable de transactions Solana est généré par le MEV (spam d’arbitrage, etc.). En période de forte affluence (comme lors d’une frappe de NFT très demandée ou d’un marché volatil), vos transactions légitimes sont en concurrence avec un déluge de transactions générées par des bots. Cela peut entraîner une augmentation de la latence ou des taux d’échec si vous n’en tenez pas compte. Vos transactions risquent d’être rejetées si elles aboutissent chez un validateur surchargé ou si vous les soumettez via un nœud non mis en jeu lors d’une tempête de spam. Vous devrez peut-être ajouter des frais de priorité pour vous frayer un chemin à travers ce bruit de fond. En substance, l’activité MEV peut encombrer l’autoroute sur laquelle votre transaction tente de circuler ; vous devrez donc vous y préparer (frais plus élevés, nouvelles tentatives, etc.) si vous n’êtes pas protégé.

  • Augmentation du slippage et problèmes d’expérience utilisateur : pour les développeurs de DEX, le MEV peut nuire directement à vos utilisateurs. Un utilisateur peut définir une tolérance de slippage de 1 % sur une transaction, mais en raison du MEV (comme dans le cas d’un « sandwich »), il finit par obtenir un prix inférieur de 1 % à celui initialement prévu. Dans les cas extrêmes, les bots MEV peuvent faire évoluer le prix de telle sorte que la transaction de l’utilisateur échoue (en dépassant la tolérance de slippage) après que le bot a déjà réalisé son profit. Cela peut se traduire par une mauvaise expérience utilisateur : transactions échouées ou taux de change inopinément défavorables. Les utilisateurs risquent alors de rejeter la responsabilité de ces résultats sur le DEX ou la blockchain. Ainsi, ne pas se prémunir contre le MEV peut ébranler la confiance dans votre plateforme. Cela peut également compliquer la tâche de votre bot de trading pour exécuter ses stratégies de manière fiable, car les résultats deviennent moins prévisibles lorsqu’un adversaire peut insérer des transactions qui affectent vos opérations.

En résumé, le MEV sur Solana peut entraîner une augmentation des coûts, une baisse des bénéfices et des frictions au sein du réseau. Les développeurs doivent être conscients de ces risques et envisager des mesures pour les atténuer, en particulier pour toute application dans laquelle l'ordre des transactions a une incidence sur les résultats financiers.

Protection des transactions contre le MEV​

Il existe de nombreux outils permettant de prévenir ou de limiter les effets négatifs du MEV sur vos opérations de trading et vos utilisateurs. Chaque cas de figure étant unique, tous ces outils ne sont pas forcément adaptés à votre situation.

  • Protégez votre transaction : utilisez les modules complémentaires Quicknode. La plateforme Quicknode Marketplace propose plusieurs outils permettant d'augmenter le taux de transaction et de minimiser l'exposition au MEV. Le Lil' JIT - Offres groupées et transactions Jito Cet add-on vous permet de regrouper des transactions pour une exécution séquentielle « fast-landing », qui inclut une protection contre le MEV et les annulations. De plus, la Marketplace offre la possibilité d'ajouter une protection contre le MEV à sendTransaction appelle votre terminal existant, en utilisant le Protection et récupération du MEV sur Solana extension. Cette extension offre non seulement une protection contre le front-running, mais permet également la récupération du MEV (en vous restituant le MEV non malveillant capturé), renforce la confidentialité et garantit une exécution rapide.

  • Se prémunir contre les modifications d'état indésirables : utiliser les « transaction guards ». Phare est un programme Solana d'assertion d'exécution conçu pour faire échouer une transaction lorsqu'il détecte que l'état de la chaîne s'est écarté de l'état attendu. Vous pouvez ajouter des instructions « lighthouse » à votre transaction afin de vous assurer que l’état des comptes spécifiés à la fin de l’exécution de votre transaction correspond à l’état attendu prédéfini (par exemple, si, après cette transaction, le solde d’un jeton donné est inférieur à X, rejeter l’intégralité de la transaction). Cela permet d’effectuer des vérifications de comptes plus complexes que la simple prise de glissement et permet également de définir des assertions sur le Sysvar (slots), qui pourraient être utilisées pour validateurs de liste noire -- cela pourrait être réalisé en utilisant getLeaderSchedule et une liste de validateurs malveillants.

  • Définissez des limites : fixez le glissement et utilisez des ordres à cours limité. Lorsque vous effectuez des swaps, définissez toujours le glissement à un niveau adapté à votre transaction et à votre tolérance au risque. Partez du principe que des acteurs malveillants cherchent à exploiter toute opportunité offerte par votre taux de glissement. Lorsque votre cas d'utilisation le permet, utilisez des ordres à cours limité pour fixer le prix minimum que vous êtes prêt à accepter pour la vente d'un token. Découvrez l'API Metis de Quicknode, qui prend en charge les ordres à cours limité.

  • Évitez l'échec de vos transactions : optimisez-les. Le MEV générant un trafic massif de spams transactionnels sur le réseau, vos transactions doivent être correctement structurées pour garantir leur inclusion dans un bloc donné. En résumé, vous devez demander le nombre adéquat d’unités de calcul, proposer des frais de priorité compétitifs et assembler correctement votre transaction (consultez les « Stratégies pour optimiser les transactions Solana » ou les « Conseils pour améliorer les taux de réussite de Jupiter Swap sur Solana » pour plus de détails). L’API Priority Fee de Quicknode peut vous aider à choisir des frais de priorité compétitifs pour vos transactions.

  • Soyez attentif à votre mise. Connaissez votre validateur. Les différents validateurs et clients de validateur adoptent des approches variées en matière de gestion du MEV. Bien que cela n’ait pas d’impact direct sur vos transactions, votre mise (et celle des autres) peut influencer la santé globale du réseau de validateurs et la gouvernance relative au MEV. Voici quelques ressources : Client de validateur Jito, Marinade : Démocratiser le MEV, Client de validateur Paladin.

  • Participez. Documents d'amélioration de Solana (SIMD). La Fondation Solana gère un dépôt GitHub open source, les « Solana Improvement Documents », où les membres de la communauté peuvent proposer des idées et commenter celles qui existent déjà. Des discussions sont en cours concernant le MEV, les frais et récompenses du réseau, etc. Si vous avez un avis sur la question, n'hésitez pas à vous impliquer !

  • Envisagez les systèmes RFQ et Express Relay. Pour les applications avancées, les systèmes de demande de devis (RFQ) (par exemple, JupiterZ) et Express Relay offrent une protection contre le MEV grâce à des canaux privés de flux d’ordres et à des enchères prioritaires isolées. Ces systèmes relient directement les protocoles aux chercheurs, écartant ainsi les validateurs du processus d’extraction du MEV et permettant une tarification plus efficace. Parmi leurs principaux avantages figurent le routage privé des transactions, la concurrence directe entre les chercheurs et la réduction des coûts d’intégration.

Conclusion​

Le MEV est un facteur important à prendre en compte lors du développement d’applications sur n’importe quelle blockchain, et Solana ne fait pas exception. Nous avons vu que la conception de Solana change la donne, mais le MEV continue de se manifester par le biais de l’arbitrage, des liquidations et des attaques de type « sandwich ». En tant que développeur d’outils DeFi pour Solana, ignorer le MEV pourrait signifier que les utilisateurs de votre application obtiennent des résultats de trading inférieurs à la moyenne ou que votre bot passe à côté de profits. La bonne nouvelle, c’est qu’il existe de nombreux outils pour vous permettre d’atténuer ces problèmes, en vous redonnant le contrôle sur l’ordre des transactions et même en capturant le MEV pour vous-même ou pour vos utilisateurs.

Ressources supplémentaires​

Dernière mise à jour sur
Partager ce guide