Qu'est-ce qu'un Jito Bundle sur Solana ? Exécution Atomique et Protection MEV Expliquée

Si vous avez déjà lancé un token, snipé un listing, ou swappé sur un DEX Solana, vous avez probablement vu un champ intitulé « Jito Tip » quelque part dans l'interface. La plupart des gens tapent un nombre et passent à autre chose sans y penser.

Mais derrière ce petit champ de saisie se trouve l'une des pièces d'infrastructure les plus importantes de Solana — et la comprendre peut faire la différence entre un trade réussi et une perte.

Ce guide couvre tout : ce qu'est un Jito Bundle, comment il fonctionne en interne, et les deux raisons fondamentales de son existence.

Qu'est-ce qu'un Jito Bundle ?

Un Jito Bundle est un groupe de jusqu'à 5 transactions Solana exécutées ensemble comme une seule unité.

Trois garanties :

Séquentiel : Les transactions s'exécutent dans l'ordre exact que vous définissez — d'abord Transaction 1, puis 2, puis 3.
Atomique : Toutes les transactions réussissent, ou aucune n'est commitée dans la blockchain. Si la Transaction 3 échoue, les Transactions 1 et 2 sont annulées comme si elles n'avaient jamais eu lieu.
Même bloc : Chaque transaction du bundle atterrit dans un seul bloc Solana, confirmée au même moment — sans dispersion sur plusieurs blocs ou secondes.

C'est tout. Concept simple, implications massives.

Les Jito Bundles sont construits et maintenus par Jito Labs. En 2025, environ 95% du stake total de Solana exécute le client validateur Jito, ce qui signifie que les bundles sont traités dans presque chaque bloc.

Pourquoi les Jito Bundles existent

Les Jito Bundles résolvent deux problèmes fondamentalement différents : l'exécution atomique séquentielle pour les opérations multi-transactions, et la protection MEV contre les attaques sandwich. Comprendre les deux est la clé pour comprendre pourquoi ils sont partout sur Solana.

1. Exécution Atomique Séquentielle dans un Seul Bloc

Sur Solana, les transactions individuelles sont atomiques — toutes les instructions à l'intérieur d'une seule transaction réussissent ou échouent ensemble. Mais dès que vous avez besoin de plus d'une transaction, vous perdez cette garantie.

Si vous soumettez la Transaction A et la Transaction B séparément :

A peut réussir tandis que B échoue.
B peut s'exécuter avant A.
Elles peuvent atterrir dans des blocs différents à des moments différents.

Pour des swaps de tokens basiques, cela n'a pas d'importance. Mais pour tout ce qui est plus complexe, c'est un problème sérieux.

Lancements de Tokens et Sniping Multi-Wallets

Lors du lancement d'un memecoin sur des plateformes comme Pump.fun, les créateurs veulent typiquement sécuriser l'offre initiale de tokens dans plusieurs wallets avant que quiconque puisse acheter. Bundler le lancement et les premiers achats depuis plusieurs wallets dans un seul Jito Bundle rend cela possible.

Avec un Jito Bundle, le créateur empaquette tout dans une unité atomique :

Transaction 1 : Créer le token
Transaction 2 : Wallet A achète
Transaction 3 : Wallet B achète
Transaction 4 : Wallet C achète

Les quatre transactions atterrissent dans le même bloc, en ordre exact. Parce que le bundle est atomique, aucune transaction externe ne peut être insérée entre la création du token et les premiers achats — les bots snipers ne peuvent pas détecter et front-runner le lancement. Le créateur sécurise l'offre initiale au prix le plus bas, et la pression d'achat à travers plusieurs wallets pousse le prix dès le premier bloc.

Si l'une des transactions d'achat échoue (solde insuffisant, mauvais paramètres), le bundle entier est annulé — y compris la création du token. Rien ne se passe on-chain. Le créateur peut corriger le problème et réessayer sans laisser un token actif sans holders initiaux.

Chaînes de Transactions Multi-Étapes

Les Jito Bundles sont largement utilisés dans les opérations automatisées de bots où plusieurs transactions doivent s'exécuter comme une séquence unique et incassable.

Par exemple, les bots qui augmentent les wallets de trading uniques ou font croître le nombre de holders de tokens opèrent en cyclant à travers une série d'étapes dépendantes dans un bundle :

Transaction 1 : Financer un nouveau wallet avec du SOL
Transaction 2 : Le nouveau wallet achète un token
Transaction 3 : Transférer le token acheté au wallet principal
Transaction 4 : Récupérer le SOL restant du nouveau wallet
Transaction 5 : Payer les frais de service

Chaque étape dépend de la précédente. Sans bundle, un échec à la Transaction 2 laisse le SOL de la Transaction 1 bloqué dans le nouveau wallet, nécessitant une récupération manuelle. Avec un Jito Bundle, soit les cinq transactions réussissent, soit rien ne se passe on-chain.

Achat sur Plusieurs Wallets dans un Seul Bloc

Lors de l'achat d'un token existant avec plusieurs wallets, bundler tous les achats dans un seul bloc garantit qu'aucune transaction externe ne peut s'exécuter entre l'achat de chaque wallet. Sans bundle, d'autres traders ou bots peuvent voir l'achat du premier wallet et réagir avant l'exécution des wallets restants — front-runner les achats restants ou faire monter le prix davantage.

Avec un bundle, toute la séquence est privée et atomique. Tous les wallets achètent en ordre exact dans le même bloc, et les trades apparaissent comme une activité d'achat indépendante depuis des wallets séparés.

2. Protection MEV

La deuxième raison d'existence des Jito Bundles est la protection MEV — spécifiquement, la protection contre les attaques sandwich.

Qu'est-ce que le MEV ?

MEV signifie Maximal Extractable Value. Il désigne le profit qui peut être extrait en réordonnant, insérant ou excluant des transactions au sein d'un bloc.

Sur Solana, la forme la plus courante de MEV affectant les utilisateurs réguliers est l'attaque sandwich.

Comment fonctionne une attaque sandwich

Lorsque vous soumettez une transaction de swap régulière sur Solana, elle entre dans le pipeline de transactions du réseau où elle peut être observée par des bots MEV avant d'être incluse dans un bloc.

Ce qui se passe :

Vous soumettez un swap : Achetez du Token X pour 1 SOL.
Un bot MEV voit votre transaction en attente. Il calcule que votre achat va faire monter le prix du Token X.
Le bot vous front-run : Il achète du Token X avant votre transaction, au prix plus bas.
Votre transaction s'exécute : Vous achetez du Token X à un prix maintenant plus élevé parce que l'achat du bot a déjà fait bouger le prix.
Le bot vous back-run : Il vend immédiatement du Token X après votre transaction, profitant de la différence de prix.

Vous avez eu un moins bon prix. Le bot a empoché la différence. Cela se produit automatiquement, des milliers de fois par bloc, et la victime ne s'en rend généralement jamais compte — elle pense juste « le slippage était élevé. »

Comment les Jito Bundles réduisent le risque

Lorsque vous envoyez une transaction via un Jito Bundle, elle contourne le pipeline public de transactions et va directement au Jito Block Engine — un système privé où les bots MEV ne peuvent pas observer votre transaction. Le chemin va directement de votre application → Block Engine → validateur Jito → exécution on-chain, sans exposition au mempool public à aucun moment.

Puisque l'attaquant ne voit jamais votre transaction, il ne peut pas insérer de trades avant ou après. La grande majorité des attaques sandwich sont effectivement bloquées.

C'est pourquoi les Jito Bundles sont standard pour des opérations comme la vente en masse depuis plusieurs wallets et les bots de market making qui tradent de manière répétée le même token pour générer de l'activité sur le graphique. Dans les deux cas, chaque transaction reste cachée des bots MEV jusqu'à sa confirmation on-chain.

Jito fournit aussi des contre-mesures additionnelles comme le mécanisme jitodontfront, qui force votre transaction à apparaître en premier dans tout bundle dans lequel elle est incluse — ajoutant une couche supplémentaire de protection contre le front-running.

Router les swaps via Jito Bundles est bien plus sûr que de soumettre des transactions via un RPC régulier, et c'est la protection MEV la plus adoptée sur Solana aujourd'hui.

Jito Bundle vs. Transaction Régulière

Le tableau suivant résume les différences clés :

	Transaction Régulière	Jito Bundle
Max transactions	1	Jusqu'à 5
Ordre d'exécution	Non garanti	Séquentiel garanti
Atomicité	Tx individuelle uniquement	Tout-ou-rien sur tous les txs
Protection MEV	Aucune — visible dans le mempool	Contourne le mempool, attaque bien plus difficile
Mécanisme de priorité	Frais de priorité	Jito Tip (enchère)
Coût du bundle échoué	Gas payé quoi qu'il arrive	Tip payé uniquement si atterri
Couverture validateurs	Tous les validateurs	~95% du stake Solana

Pour toute opération impliquant plusieurs transactions ou nécessitant une protection contre le MEV, les Jito Bundles sont le standard sur Solana.

Comment fonctionne le système Jito

Ce qui se passe en coulisses :

Étape 1 : Création du Bundle : Votre application crée jusqu'à 5 transactions signées et les empaquette dans un bundle, avec un tip attaché.
Étape 2 : Block Engine : Le bundle est envoyé au Block Engine de Jito — pas à un RPC Solana régulier. Le Block Engine collecte des bundles de milliers d'utilisateurs simultanément.
Étape 3 : Simulation : Le Block Engine simule chaque transaction de votre bundle. Si une transaction devait échouer, le bundle entier est rejeté avant de toucher la blockchain. Vous ne payez rien.
Étape 4 : Enchère : Toutes les ~200 millisecondes, le Block Engine lance une enchère. Les bundles sont en compétition selon leur montant de tip. Plus le tip est élevé = plus la priorité est haute. Les bundles gagnants sont transmis au validateur Jito actuel.
Étape 5 : Exécution : Le validateur Jito exécute les bundles gagnants de manière atomique. Toutes les transactions réussissent et sont commitées, ou le bundle est entièrement rejeté.

Que sont les Jito Tips ?

Un Jito Tip est un petit paiement en SOL attaché à votre bundle. C'est le coût de soumission de votre bundle au Jito Block Engine — payé aux validateurs comme incitation à inclure votre bundle dans le prochain bloc.

Minimum : 1 000 lamports (0,000001 SOL)
Payé uniquement si votre bundle atterrit on-chain. Les simulations échouées ou les enchères perdues ne coûtent rien.
Le tip est payé par bundle, pas par transaction — un bundle avec 5 transactions paie le même tip qu'un bundle avec 1.

Comment aborder le tipping

Une plateforme bien construite construit les transactions correctement, utilise une simulation adéquate et gère les tentatives en interne — ce qui signifie que même le tip minimum est souvent suffisant pour faire atterrir votre bundle avec succès dans des conditions réseau normales. Si vous avez besoin de tips élevés juste pour faire passer des opérations basiques, le problème vient plus probablement de la construction des transactions de la plateforme que du montant du tip.

Commencez avec le tip le plus bas possible et n'augmentez que quand c'est nécessaire :

Scénario	Tip de Départ Suggéré
Conditions normales	0,000001 SOL (minimum)
Congestion modérée	0,0001 – 0,0005 SOL
Lancement de token compétitif	0,001 – 0,005 SOL
Snipe extrêmement disputé	0,005+ SOL

L'objectif est de payer le minimum nécessaire pour que votre bundle atterrisse. Surpayer les tips est du SOL gaspillé.

Résumé

Les Jito Bundles servent deux objectifs :

Exécution atomique séquentielle — Regrouper plusieurs transactions dans un paquet tout-ou-rien. Utilisé pour les lancements de tokens avec achats multi-wallets, la génération d'activité de trading on-chain dans un seul bloc, et toute opération multi-étapes où l'échec partiel est inacceptable.
Protection MEV — Contourner le pipeline public de transactions pour que les bots MEV ne puissent pas observer vos swaps. Bloque la grande majorité des attaques sandwich en gardant vos transactions cachées jusqu'à leur confirmation on-chain.

Les deux fonctionnalités sont alimentées par le Jito Block Engine et les Jito Tips, avec ~95% des validateurs Solana supportant le traitement des bundles.