Entre 370 et 500 millions de dollars. C’est la fourchette que l’entreprise JTX avance pour les sommes extraites des traders Solana par des robots de sandwich MEV sur une période de seize mois, selon une étude publiée le 3 août 2026 (source JTX). Sur une seule semaine observée, les chercheurs ont compté 7 008 attaques de ce type. Face à ce problème structurel, trois acteurs se disputent le rôle de bouclier : Jito, qui a lancé en septembre 2026 son Block Assembly Marketplace (BAM), bloXroute, qui vend sa Trader API sur un argument de vitesse pure, et Helius, partenaire de distribution plus discret mais central dans l’écosystème. Ce comparatif détaille leurs mécanismes techniques, leurs chiffres d’adoption, leurs frais et leurs limites, pour aider développeurs et traders Solana à choisir la bonne infrastructure en 2026.
Le sujet dépasse la simple curiosité technique. Un trader qui swap 10 000 dollars sur un DEX Solana sans protection peut perdre plusieurs centaines de dollars en une seule transaction si un bot de sandwich repère son ordre dans le mempool. À l’échelle du réseau, cette ponction répétée pèse sur la confiance des utilisateurs et sur l’image de Solana comme chaîne rapide et bon marché. D’où l’enjeu de ce comparatif : identifier, sur la base de données vérifiables, laquelle de ces trois infrastructures réduit réellement ce risque, et laquelle se contente de vendre de la vitesse sans garantie sérieuse.
Qu’est-ce que le MEV sur Solana et pourquoi il coûte cher aux traders
Le MEV, ou valeur extractible maximale, désigne le profit qu’un acteur peut tirer en réordonnant, insérant ou retardant des transactions dans un bloc. Sur Ethereum, ce marché génère environ 180 millions de dollars par mois selon le guide 2026 d’arbitragescanner.io. Sur Solana, la même source évalue le volume mensuel autour de 45 millions de dollars, un montant plus faible mais en croissance rapide (arbitragescanner.io). La différence tient à l’architecture du réseau : Solana traite les transactions beaucoup plus vite qu’Ethereum, ce qui change la nature des attaques possibles.
Le format d’attaque dominant sur Solana reste le sandwich. Un bot repère une transaction d’achat en attente, place son propre ordre juste avant pour faire grimper le prix, laisse l’utilisateur acheter plus cher, puis revend immédiatement après pour capter l’écart. Contrairement à l’arbitrage, qui corrige des inefficacités de marché sans nuire directement à un utilisateur précis, le sandwich prélève une perte nette sur chaque victime. C’est ce qui a poussé les infrastructures de validation à proposer des mécanismes de protection, plutôt que de laisser le marché libre gérer le problème.
Ce qui rend le sandwich particulièrement difficile à combattre sur Solana, c’est la vitesse du réseau lui-même. Les blocs se produisent en quelques centaines de millisecondes, ce qui laisse aux bots une fenêtre extrêmement courte pour détecter une transaction, calculer leur contre-offre et l’insérer avant elle. Cette contrainte technique a orienté les solutions de protection vers le niveau le plus bas possible de la pile, celui du relais et du client validateur, plutôt que vers des mécanismes d’enchère au niveau applicatif comme sur Ethereum. C’est précisément ce terrain que Jito, bloXroute et Helius occupent chacun à leur manière.
Sur Ethereum, la réponse est passée par des systèmes d’enchères comme MEV Blocker et Flashbots Protect, ou par des agrégateurs anti-MEV comme CoW Swap, 1inch Fusion et UniswapX. Sur Solana, le modèle est différent : la protection passe directement par le client validateur et par les relais qui acheminent les transactions jusqu’aux block builders. C’est pour cela que Jito, bloXroute et Helius occupent une place centrale, puisqu’ils contrôlent une partie du chemin que suit chaque transaction avant son inclusion dans un bloc.
Jito Block Engine et BAM : l’infrastructure qui verrouille le réseau
Jito Labs domine l’infrastructure MEV de Solana depuis plusieurs années. Son client validateur, une version modifiée d’Agave, fait tourner un Block Engine qui organise des enchères hors chaîne entre chercheurs (searchers) et regroupe leurs offres en bundles exécutés de façon atomique. Selon une recherche publiée par CoinDesk le 12 mai 2026 et mise à jour le 6 octobre 2026, 97,61 % des validateurs Solana font tourner le client Jito (CoinDesk Research). Le Block Engine prélève des frais de 6 % sur les récompenses MEV captées via l’ordonnancement des transactions, d’après SolanaCompass.
Le 9 septembre 2026, Jito a lancé BAM, le Block Assembly Marketplace, une étape qui change la donne. Ce nouveau marché de préconfirmations couvrait, au lancement, 34,1 % du stake total de Solana répartis sur 383 des 665 validateurs actifs, selon des chiffres de SolanaFloor repris par SolanaCompass. BAM introduit un partage de revenus en trois parts : 35 % reversés aux validateurs participants au prorata de leur stake, 35 % au trésor de la DAO Jito, et 30 % aux fournisseurs d’infrastructure, une catégorie qui inclut des partenaires de distribution comme Helius (SolanaCompass, citant CryptoBriefing).
Pour la protection anti-sandwich concrète, Jito propose un mécanisme simple nommé jitodontfront. Un développeur ajoute une clé publique commençant par “jitodontfront” comme compte en lecture seule dans sa transaction, puis l’envoie via l’endpoint du Block Engine plutôt que via un RPC standard. Le moteur impose alors que cette transaction occupe la première position du bundle, ce qui empêche qu’une autre transaction s’insère avant elle dans ce lot précis (documentation Chainstack). C’est une garantie limitée au bundle en question, pas une immunité totale contre toute forme de MEV sur le réseau.
bloXroute Trader API : la vitesse comme argument de vente
bloXroute aborde le problème sous un angle différent. Plutôt que de contrôler la construction des blocs comme Jito, l’entreprise vend un réseau de diffusion à très faible latence baptisé BDN (Blockchain Distribution Network), décliné en Solana Trader API. L’argument commercial repose sur la rapidité d’atterrissage des transactions plutôt que sur un pouvoir de marché validé par le stake. Dans un test publié sur son propre site, bloXroute affirme que 83 % des transactions envoyées via la Trader API, combinée à des frais de priorité et à une protection anti-frontrunning, atterrissent en première position face à des RPC publics classiques (bloXroute). Ce chiffre vient d’un test interne sans méthodologie publique détaillée, ce qui invite à le traiter comme un argument marketing plutôt qu’un benchmark indépendant.
La proposition de valeur de bloXroute cible surtout les traders à haute fréquence et les équipes d’arbitrage qui ont besoin de gagner quelques millisecondes sur l’accès au mempool Solana. Contrairement à Jito, bloXroute ne dépend pas d’un contrôle direct sur une part du stake des validateurs : son avantage vient de son infrastructure réseau propre, avec des nœuds positionnés pour réduire le trajet physique des paquets. Cette approche la rend complémentaire à Jito plutôt que strictement concurrente, puisque de nombreux traders combinent les deux services pour maximiser leurs chances d’inclusion rapide.
Helius Sender et Atlas : le partenaire de distribution discret
Helius occupe une place particulière dans cet écosystème. L’entreprise fournit une infrastructure RPC et des outils de développement pour Solana, mais son rôle dans la protection MEV passe surtout par son statut de partenaire de distribution du programme BAM de Jito. Les sources consultées situent Helius dans la catégorie des fournisseurs d’infrastructure qui touchent une part des 30 % alloués par BAM, aux côtés d’acteurs comme Triton (Figment).
Concrètement, Helius expose des endpoints Sender et Atlas qui acheminent les transactions des développeurs vers le réseau Jito dans de bonnes conditions, sans que l’entreprise opère elle-même un mécanisme de protection anti-sandwich distinct. Son blog technique présente d’ailleurs le MEV sur Solana comme un sujet d’introduction pour les développeurs plutôt que comme un produit autonome de protection (Helius). Pour une équipe qui construit une application Solana, Helius représente donc moins un concurrent direct de Jito et bloXroute qu’une porte d’entrée pratique vers leur infrastructure, avec une couche de documentation et de support que les deux autres acteurs ne proposent pas au même niveau.
BAM et le risque de concentration : la face cachée du succès de Jito
Un chiffre revient dans presque toutes les sources consultées pour ce comparatif : 97,61 % des validateurs Solana font tourner le client Jito. Ce niveau d’adoption, confirmé par CoinDesk Research, pose une question que peu d’articles marketing abordent de front. Quand une infrastructure unique contrôle la quasi-totalité de l’ordonnancement des blocs d’un réseau, elle devient de facto un point de passage obligé, avec tout ce que cela implique en matière de résilience et de gouvernance.
Le lancement de BAM amplifie encore cette dynamique plutôt que de la corriger. En ouvrant le marché des préconfirmations à des fournisseurs tiers comme Helius ou Triton, Jito élargit son écosystème de partenaires, mais la clé de répartition à 35/35/30 reste pilotée depuis son propre protocole. Autrement dit, BAM distribue davantage de revenus autour de Jito sans réduire la dépendance structurelle du réseau envers ce client unique. Les 383 validateurs qui ont rejoint BAM dès son lancement représentaient déjà 34,1 % du stake total, un rythme d’adoption qui traduit la confiance du marché, mais aussi l’absence d’alternative crédible à court terme.
Pour un développeur ou un fonds qui bâtit une stratégie à long terme sur Solana, ce constat change la façon d’évaluer le risque. Choisir Jito, c’est accepter de dépendre d’un acteur qui façonne une part croissante de l’économie du réseau, bloXroute et Helius inclus puisque ce dernier perçoit une partie des revenus BAM. La diversification reste possible techniquement, par exemple en répartissant l’envoi de transactions entre plusieurs canaux, mais elle ne change rien au fait que la majorité des blocs Solana passe, à un moment ou un autre, par une infrastructure Jito.
Tableau comparatif technique : Jito, bloXroute et Helius face à face
Le tableau suivant synthétise les caractéristiques techniques des trois acteurs à partir des données disponibles publiquement en octobre 2026. Certaines cases restent vides lorsque l’information n’est pas publiée ou pas comparable entre les trois produits.
| Caractéristique | Jito (Block Engine / BAM) | bloXroute (Trader API) | Helius (Sender / Atlas) |
|---|---|---|---|
| Type d’infrastructure | Client validateur + marché d’enchères | Réseau de diffusion à faible latence (BDN) | RPC et partenaire de distribution |
| Mécanisme anti-sandwich | jitodontfront + bundles atomiques | Frontrunning protection (interne, non détaillée) | Relais vers l’infrastructure Jito |
| Dernière mise à jour majeure | Lancement de BAM, 9 septembre 2026 | Trader API (mise à jour continue) | Partenariat BAM actif en 2026 |
| Part du stake Solana couverte | 97,61 % (client Jito) / 34,1 % (BAM au lancement) | Non publiée (dépend des routes réseau) | Non applicable (pas un validateur) |
| Validateurs concernés | 383 sur 665 validateurs actifs (BAM) | Non applicable | Non applicable |
| Frais sur récompenses MEV | 6 % (Block Engine classique) | Abonnement, montants non publiés | Part des 30 % versés aux fournisseurs BAM |
| Modèle de revenus BAM | 35 % validateurs / 35 % DAO / 30 % infrastructure | Non concerné par BAM | Bénéficiaire de la part “infrastructure” (30 %) |
| API de trading dédiée | Oui, via Block Engine | Oui, Solana Trader API | Oui, Sender et Atlas |
| Cible principale | Validateurs et traders de détail | Market makers et arbitragistes HFT | Développeurs d’applications Solana |
| Documentation publique | Détaillée (docs.jito.wtf, Chainstack) | Détaillée (docs.bloxroute.com) | Détaillée (helius.dev) |
| Revenus trimestriels protocole | 1,28 M$ au T2 2026 (-45 % sur un trimestre) | Non publiés | Non publiés |
Benchmarks : vitesse, taux d’atterrissage et parts de marché
Comparer des benchmarks venant de trois sources différentes impose de la prudence, car chacune mesure une chose légèrement différente. bloXroute publie son propre chiffre de 83 % de transactions “atterries en premier” avec sa Trader API couplée à des frais de priorité, contre des RPC publics (bloXroute). Ce chiffre mesure la vitesse d’inclusion, pas directement la protection contre le sandwich.
Pour Jito, SolanaCompass rapporte qu’au T2 2026, les revenus du protocole ont chuté de 45 % pour atteindre 1,28 million de dollars, pendant que BAM passait de 340 à 378 validateurs et atteignait 33 % du stake, avec environ 10,6 milliards de dollars de SOL délégué fin juin, selon un rapport de Blockworks Advisory (SolanaCompass). Ce recul de revenu, pendant une phase de montée en puissance de BAM, illustre une transition de modèle économique plutôt qu’un recul d’usage du réseau.
Le site rpcfast.com, dans sa comparaison des clients validateurs Solana, indique que Jito a atteint un pic de plus de 89 % du stake total cumulé entre les variantes Jito-Agave et Jito-Firedancer, et que les validateurs Jito gagnaient en moyenne 0,044 SOL par bloc en janvier 2026, soit environ 13 % de plus que la moyenne du réseau (rpcfast.com). Côté dommages subis par les utilisateurs, JTX chiffre entre 370 et 500 millions de dollars les pertes liées au sandwich sur seize mois, avec un pic de 7 008 attaques recensées sur une semaine (JTX). Ces trois sources, prises ensemble, dessinent un réseau où Jito contrôle la majorité de l’infrastructure de validation, où bloXroute gagne sur la vitesse brute, et où les pertes utilisateurs restent élevées malgré les deux mécanismes.
| Indicateur | Valeur rapportée | Source | Date |
|---|---|---|---|
| Transactions atterries en premier (Trader API + anti-frontrunning) | 83 % | bloXroute | Test publié, repris oct. 2026 |
| Validateurs sous client Jito | 97,61 % | CoinDesk Research | Mai 2026, maj oct. 2026 |
| Stake couvert par BAM au lancement | 34,1 % (383/665 validateurs) | SolanaFloor via SolanaCompass | 9 sept. 2026 |
| Pic historique de stake Jito (Agave + Firedancer) | +89 % | rpcfast.com | 2026 |
| Rendement validateur Jito vs moyenne réseau | 0,044 SOL/bloc (+13 %) | rpcfast.com | Janvier 2026 |
| Pertes sandwich cumulées | 370-500 M$ sur 16 mois | JTX | Août 2026 |
| Pic hebdomadaire d’attaques sandwich | 7 008 attaques / semaine | JTX | 2026 |
Ce tableau met en évidence une limite méthodologique importante : chaque fournisseur ou observateur mesure un angle différent du même problème. Le chiffre de bloXroute porte sur la vitesse d’inclusion, ceux de CoinDesk et SolanaCompass sur la part de réseau contrôlée, et celui de JTX sur le préjudice final subi par les utilisateurs. Aucune source ne propose une mesure unique et indépendante qui permettrait de trancher objectivement laquelle des trois infrastructures protège le mieux un utilisateur donné.
Tarifs et modèles économiques : qui paie quoi
Les trois acteurs ne facturent pas de la même manière, et aucun ne publie une grille tarifaire aussi lisible qu’un service cloud classique. Jito prélève 6 % sur les récompenses MEV captées via son Block Engine classique. Avec BAM, le modèle change : les revenus des préconfirmations se répartissent en 35 % pour les validateurs participants, 35 % pour le trésor de la DAO, et 30 % pour les fournisseurs d’infrastructure, une catégorie qui inclut Helius et d’autres partenaires de distribution.
| Service | Frais ou part de revenu | Qui paie / qui reçoit | Source |
|---|---|---|---|
| Jito Block Engine | 6 % des récompenses MEV captées | Chercheurs (searchers) payent, validateurs reçoivent | SolanaCompass |
| Jito BAM | 35 % / 35 % / 30 % | Validateurs / DAO Jito / fournisseurs d’infrastructure | SolanaCompass, citant CryptoBriefing |
| bloXroute Trader API | Abonnement par plan, montants non publiés | Traders et market makers | bloXroute (grille non détaillée publiquement) |
| Helius (part BAM) | Partage de la quote-part de 30 % | Reçue en tant que fournisseur de distribution | Figment, SolanaCompass |
bloXroute ne publie pas de grille tarifaire précise pour sa Trader API sur ses pages produit accessibles publiquement, les plans étant généralement négociés selon le volume de transactions et les besoins en capacité. Il en va de même pour les offres d’API de Helius, dont les conditions commerciales dépendent du niveau de service choisi. Cette opacité tarifaire reste courante dans l’infrastructure MEV, où les plus gros clients négocient des conditions individuelles plutôt que de payer un tarif catalogue.
Cinq cas réels qui montrent où la protection MEV tient ses promesses
Le lancement de BAM le 9 septembre 2026 constitue le cas le plus documenté de l’année. En quelques jours, 383 validateurs représentant 34,1 % du stake total ont rejoint le nouveau marché de préconfirmations, un démarrage rapide pour une infrastructure qui change le partage des revenus entre validateurs et fournisseurs tiers.
Deuxième cas : la chute de 45 % des revenus du protocole Jito au T2 2026, à 1,28 million de dollars, pendant que BAM montait en puissance. Ce paradoxe apparent montre qu’un protocole peut perdre des revenus sur son ancien modèle tout en gagnant du terrain sur son nouveau produit, une dynamique classique de transition technologique.
Troisième cas : le test de performance publié par bloXroute, avec son chiffre de 83 % de transactions atterries en première position. Même sans méthodologie publique détaillée, ce test reste la référence commerciale la plus citée pour comparer la vitesse d’inclusion entre un RPC protégé et un RPC public classique.
Quatrième cas : l’étude JTX d’août 2026, qui documente entre 370 et 500 millions de dollars de pertes liées au sandwich sur Solana en seize mois, avec un pic ponctuel de 7 008 attaques en une seule semaine. Ce chiffre rappelle qu’aucune des trois infrastructures comparées n’a éliminé le problème à la racine, elles le réduisent sans le supprimer.
Cinquième cas : le mécanisme jitodontfront documenté par Chainstack, une solution technique concrète que les développeurs peuvent implémenter en trois lignes de code pour imposer la position d’une transaction dans un bundle. C’est l’exemple le plus directement actionnable pour une équipe qui veut tester une protection anti-frontrunning sans changer tout son stack d’infrastructure.
Guide de migration : passer d’un RPC public à une protection MEV active
Pour une équipe qui envoie encore ses transactions via un RPC public classique, la migration vers une infrastructure protégée suit généralement les mêmes grandes étapes, quel que soit le fournisseur choisi.
- Identifier le profil de risque réel : un bot d’arbitrage haute fréquence a des besoins différents d’une application grand public qui exécute des swaps occasionnels pour ses utilisateurs.
- Tester chaque fournisseur sur devnet avant tout déploiement en production, en mesurant le taux d’inclusion et la latence réelle observée depuis l’infrastructure de l’équipe.
- Mettre à jour l’URL de l’endpoint RPC dans le code client, en remplaçant le point d’entrée public par celui du Block Engine, de la Trader API ou du relais Sender selon le choix retenu.
- Ajouter la protection anti-sandwich au niveau transaction, par exemple avec le compte jitodontfront pour les intégrations Jito.
- Surveiller en continu le taux d’atterrissage et les frais de priorité réellement payés, car ces paramètres évoluent avec la congestion du réseau.
- Prévoir un mécanisme de repli (fallback) vers un second fournisseur en cas d’indisponibilité, pour ne pas bloquer les transactions critiques d’une application en production.
Chacune de ces étapes mérite d’être testée isolément plutôt que déployée en bloc. Une équipe qui change à la fois d’endpoint RPC et de logique de protection anti-sandwich perd la capacité d’isoler la cause si le taux d’inclusion se dégrade après la migration. Il est plus sûr de migrer d’abord l’endpoint, de mesurer son effet sur une semaine de trafic réel, puis d’ajouter la couche de protection transaction par transaction, en comparant les métriques avant et après chaque changement.
Voici un exemple simplifié illustrant le principe du mécanisme jitodontfront, tel que décrit dans la documentation Chainstack et celle de Solana.
// Étape 1 : ajouter la clé jitodontfront en lecture seule
const dontFrontKey = new PublicKey(
"jitodontfront111111111111111111111111111111"
);
transaction.add(
new TransactionInstruction({
keys: [{ pubkey: dontFrontKey, isSigner: false, isWritable: false }],
programId: SystemProgram.programId,
data: Buffer.alloc(0),
})
);
// Étape 2 : envoyer via l'endpoint Block Engine, pas un RPC standard
const response = await jitoBlockEngineClient.sendBundle([transaction]);
// Étape 3 : le moteur impose la position 0 du bundle pour cette transaction
Cette approche fonctionne au niveau d’un bundle précis. Elle ne protège pas une transaction envoyée en dehors du circuit Jito, ce qui explique pourquoi certaines équipes combinent plusieurs fournisseurs plutôt que de dépendre d’un seul canal d’envoi.
Avantages et inconvénients de chaque solution
Jito profite d’un avantage structurel : sa domination sur le stake validé lui donne un pouvoir de négociation qu’aucun concurrent ne peut reproduire rapidement. L’inconvénient principal tient à la concentration qu’elle crée, avec 97,61 % des validateurs dépendants d’un seul client logiciel, un point régulièrement soulevé par les observateurs du réseau qui s’inquiètent d’un risque de point de défaillance unique.
Jito (Block Engine / BAM). L’adoption quasi universelle du client reste son principal atout : un développeur qui s’appuie sur Jito profite d’un mécanisme anti-sandwich documenté et déjà testé à grande échelle. Le nouveau modèle BAM ajoute une source de revenu pour les validateurs participants et pour les fournisseurs tiers comme Helius. En face, la concentration du réseau sur un seul client pose un risque de résilience à long terme, les revenus du protocole restent volatils (-45 % au T2 2026), et la protection jitodontfront ne couvre que le périmètre d’un bundle donné, pas l’ensemble du trajet d’une transaction.
bloXroute (Trader API). Son atout principal tient à la latence réseau, avec un chiffre de performance revendiqué de 83 % de transactions atterries en premier, un argument qui parle directement aux market makers. Le service se positionne aussi comme complémentaire à Jito plutôt que concurrent frontal. À l’inverse, la méthodologie de son benchmark n’est pas publiée dans le détail, sa tarification reste opaque pour un lecteur externe, et bloXroute ne dispose d’aucun contrôle direct sur l’ordonnancement des blocs, contrairement à Jito.
Helius (Sender / Atlas). La force de Helius réside dans sa documentation développeur et la simplicité d’intégration pour les équipes déjà clientes de son infrastructure RPC, avec en prime une part de revenu issue du programme BAM. Sa limite est symétrique à cet avantage : Helius ne propose pas de mécanisme de protection anti-sandwich qui lui soit propre, et dépend entièrement de l’infrastructure Jito pour l’essentiel de la protection MEV qu’il relaie à ses clients.
Quelle solution choisir selon votre profil de trading ou de développement
Un trader de détail qui exécute des swaps occasionnels sur un DEX gagnera à utiliser un wallet ou une application qui intègre déjà la protection Jito par défaut, sans configuration technique supplémentaire à gérer.
Un market maker ou une équipe d’arbitrage à haute fréquence privilégiera bloXroute pour sa latence réseau, tout en gardant un canal Jito en parallèle pour sécuriser l’inclusion des transactions les plus sensibles au prix.
Un validateur institutionnel qui cherche à maximiser ses revenus tout en limitant son exposition réglementaire regardera de près le programme BAM, dont le partage à 35 % offre une source de revenu complémentaire au staking classique.
Une équipe de développement qui construit une application Solana grand public, sans ressources dédiées à l’infrastructure MEV, tirera parti de Helius pour sa documentation et son support, en laissant le fournisseur gérer la relation technique avec Jito en arrière-plan.
Un fonds ou un desk de trading qui déplace des volumes importants en une seule transaction aura intérêt à combiner les trois approches : Jito pour l’ordonnancement protégé, bloXroute pour la vitesse de diffusion, et une surveillance active des taux d’atterrissage pour ajuster la stratégie en temps réel.
Un protocole DeFi qui lance une nouvelle pool de liquidité et redoute un sandwich massif au moment du lancement gagnera à activer une protection anti-frontrunning dès la première transaction de mise en liquidité, plutôt que d’attendre un premier incident pour agir. Les équipes qui gèrent des trésoreries DAO, elles, devraient documenter publiquement leur choix d’infrastructure MEV au même titre que leurs autres décisions de sécurité, pour que leur communauté puisse évaluer le risque en toute transparence.
Enfin, un projet qui gère des flux financiers transfrontaliers ou des reversements soumis à des obligations de conformité devra documenter le choix de son infrastructure MEV au même titre que ses audits de sécurité, à l’image des pratiques déjà exigées pour les audits de smart contracts chez CertiK, OpenZeppelin ou Trail of Bits.
MEV sur Solana contre MEV sur Ethereum : deux batailles différentes
La comparaison avec Ethereum aide à comprendre pourquoi Solana a développé des outils si différents. Sur Ethereum, le volume MEV mensuel atteint environ 180 millions de dollars, quatre fois plus que sur Solana selon arbitragescanner.io. Mais la réponse technique y passe surtout par des enchères au niveau de l’ordre d’exécution, via des systèmes comme MEV Blocker et Flashbots Protect, ou par des agrégateurs qui regroupent les ordres avant exécution comme CoW Swap, 1inch Fusion et UniswapX.
Sur Solana, la rapidité du réseau rend ce type d’enchère moins pertinent, car les blocs se produisent en quelques centaines de millisecondes. La protection se joue donc plus tôt dans la chaîne, au niveau du relais et du client validateur, ce qui explique le poids pris par Jito, bloXroute et Helius plutôt que par des agrégateurs de type DEX. Cette différence d’architecture a aussi une conséquence pour les enquêteurs blockchain : tracer les flux issus du sandwich MEV demande des outils adaptés à la vitesse de Solana, un terrain sur lequel des sociétés comme celles comparées dans notre article sur Chainalysis, TRM Labs et Elliptic développent des capacités spécifiques.
Cette divergence a aussi une traduction économique directe. Les 180 millions de dollars mensuels captés sur Ethereum se répartissent entre un grand nombre de constructeurs de blocs et d’opérateurs de relais, dans un marché plus fragmenté. Les 45 millions de dollars mensuels estimés sur Solana se concentrent, eux, sur une poignée d’acteurs, Jito en tête, ce qui rend chaque décision prise par cette infrastructure beaucoup plus visible sur l’ensemble du réseau. Un changement de politique tarifaire chez Jito a ainsi un effet immédiat sur l’économie MEV de Solana, alors qu’une décision équivalente chez un seul relais Ethereum ne modifierait qu’une fraction marginale du marché.
Le verdict 2026 : qui protège vraiment les traders Solana
Sur la base des données disponibles en octobre 2026, Jito reste l’infrastructure de référence par son poids sur le réseau. Avec 97,61 % des validateurs qui font tourner son client et un nouveau programme BAM qui a déjà rallié 34,1 % du stake en quelques jours, aucun concurrent n’approche ce niveau de couverture. Son mécanisme jitodontfront offre une protection documentée et simple à implémenter, même si elle reste limitée au périmètre d’un bundle.
bloXroute garde un rôle utile pour les acteurs qui ont besoin de vitesse brute, avec son chiffre revendiqué de 83 % de transactions atterries en premier, mais son opacité sur la méthodologie et les tarifs limite la comparaison directe avec les chiffres publics de Jito. Helius, de son côté, joue un rôle de facilitateur plus que de protecteur autonome, utile pour les équipes qui veulent accéder à l’écosystème Jito sans gérer elles-mêmes l’infrastructure bas niveau.
Le chiffre qui résume le mieux l’état du marché reste celui de JTX : entre 370 et 500 millions de dollars volés aux traders Solana en seize mois, malgré la présence de ces trois infrastructures. La protection MEV progresse, mais elle n’a pas encore fait disparaître le problème qu’elle prétend résoudre.
Foire aux questions
Qu’est-ce que le MEV sur Solana ?
Le MEV désigne les profits tirés en réordonnant, insérant ou retardant des transactions dans un bloc. Sur Solana, l’attaque la plus fréquente est le sandwich, où un bot encadre la transaction d’un trader pour capter la différence de prix.
Jito est-il gratuit à utiliser ?
Non. Le Block Engine classique prélève 6 % sur les récompenses MEV captées. Le programme BAM applique un partage différent, avec 35 % pour les validateurs, 35 % pour la DAO Jito, et 30 % pour les fournisseurs d’infrastructure.
bloXroute protège-t-il réellement contre le sandwich ?
bloXroute propose une option de protection contre le frontrunning intégrée à sa Trader API, mais l’entreprise n’a pas publié de méthodologie indépendante pour son chiffre de 83 % de transactions atterries en premier. Ce chiffre mesure la vitesse d’inclusion plus que l’absence de sandwich.
Quel est le rôle d’Helius dans la protection MEV ?
Helius agit comme partenaire de distribution du programme BAM de Jito et fournit des endpoints Sender et Atlas qui relaient les transactions des développeurs vers l’infrastructure Jito. L’entreprise ne propose pas de mécanisme anti-sandwich qui lui soit propre.
Qu’est-ce que le mécanisme jitodontfront ?
C’est une méthode qui consiste à ajouter une clé publique spécifique comme compte en lecture seule dans une transaction, envoyée ensuite via l’endpoint du Block Engine de Jito. Le moteur impose alors que cette transaction occupe la première position du bundle, ce qui bloque l’insertion d’une transaction concurrente devant elle dans ce lot.
Combien d’argent les traders Solana perdent-ils au MEV chaque année ?
Selon JTX, les bots de sandwich ont extrait entre 370 et 500 millions de dollars sur seize mois, avec un pic de 7 008 attaques recensées sur une seule semaine. Le marché MEV global sur Solana est estimé à environ 45 millions de dollars par mois par arbitragescanner.io.
Peut-on combiner Jito, bloXroute et Helius ?
Oui. De nombreuses équipes utilisent Jito pour l’ordonnancement protégé, bloXroute pour la vitesse de diffusion réseau, et Helius pour la couche RPC et la documentation développeur, sans que ces trois usages se contredisent techniquement.
Le risque de concentration autour de Jito est-il préoccupant ?
Avec 97,61 % des validateurs qui font tourner son client, Jito représente un point de concentration technique important pour Solana. Ce niveau d’adoption soulève des questions de résilience réseau, même si aucune défaillance majeure liée à cette concentration n’a été documentée dans les sources consultées pour cet article.
Qu’est-ce que le Block Assembly Marketplace (BAM) de Jito ?
BAM est un marché de préconfirmations lancé par Jito le 9 septembre 2026. Il permet à des validateurs et à des fournisseurs d’infrastructure tiers, comme Helius, de participer à un nouveau modèle de revenus partagés à hauteur de 35 % pour les validateurs, 35 % pour la DAO Jito, et 30 % pour les fournisseurs d’infrastructure.
Faut-il choisir un seul fournisseur de protection MEV ou en combiner plusieurs ?
La plupart des équipes avancées combinent plusieurs canaux d’envoi de transactions plutôt que de dépendre d’un seul. Jito pour l’ordonnancement protégé et bloXroute pour la vitesse de diffusion répondent à des besoins différents, et les utiliser en parallèle réduit le risque de dépendre d’un point de défaillance unique si l’un des deux services connaît une interruption.
