Avant cela, nous avions déjà réglé la surveillance du marché (Scout) et le modèle mathématique (AMM Math). Maintenant, le moment crucial arrive — la couche stratégie (Strategy). C’est le cerveau du robot d’arbitrage, qui doit répondre en quelques millisecondes à trois questions clés :

Y a-t-il de l’argent à gagner ? La différence de prix couvre-t-elle suffisamment les frais de gas et le slippage ? Quelle opération effectuer ? Acheter à bas prix dans le pool A, vendre à prix élevé dans le pool B, ou faire l’inverse ? Comment garantir que le profit est réellement réalisé ? En verrouillant l’exécution via des transactions atomiques et le regroupement (Bundle).

Dans cet épisode, nous allons analyser la logique algorithmique de l’arbitrage cross-DEX sur Solana et les défis techniques concrets.

**Du polling à l’événementiel**

L’environnement haute performance de Solana impose une architecture réactive pour l’arbitrage. Dès qu’un état de pool est mis à jour, le robot entre immédiatement en action : déclenchement de l’état → calcul du prix local → comparaison des écarts → vérification si le seuil est dépassé → si oui, détermination de la direction et de la taille → construction de la transaction atomique → envoi via Jito Bundle. Inversement, si l’écart n’atteint pas le seuil, il abandonne et attend la prochaine opportunité.

Ce type d’architecture réduit le délai entre la surveillance et l’émission de la transaction à quelques millisecondes, d’une rapidité inimaginable. Ce n’est pas du polling de l’état du pool, ni une attente passive, mais une véritable architecture événementielle.

**Pourquoi utiliser Jito Bundle**

Dans l’écosystème Solana, même votre transaction la plus rapide doit faire la queue. Le rôle de Jito Bundle est de briser cette logique de file d’attente. Le robot peut regrouper plusieurs transactions en une seule opération atomique envoyée au validateur, garantissant ainsi l’ordre d’exécution et l’atomicité. Une fois dans le Bundle, c’est tout ou rien : tout doit réussir ou tout échouer, sans état intermédiaire. C’est crucial pour l’arbitrage — vous ne pouvez pas accepter qu’une transaction réussisse et une autre échoue.

**Le cœur de la logique décisionnelle**

La détection d’écart de prix est la première étape. Le robot doit calculer en temps réel toutes les voies possibles d’arbitrage (deux pools, trois pools, voire plus), puis sélectionner celle avec la plus grande différence. Mais attention : la transaction elle-même génère du slippage, les frais de gas sont fixes, et en période de congestion, le coût du Bundle peut exploser. Il faut donc tout prendre en compte dans le calcul pour s’assurer que le profit final reste positif.

Ensuite, la décision de direction. Si l’écart USDC/SOL apparaît, le robot doit déterminer dans quel pool acheter et dans lequel vendre. Cela implique la profondeur de liquidité, les limites de volume, et la variation dynamique du slippage. Un volume trop faible ne rapporte rien, un volume trop élevé peut manger la marge via le slippage. Il faut trouver le point critique.

Ce cycle complet tourne en boucle continue, de la détection d’opportunité à l’exécution, avec presque aucun délai.