Routage et MEV

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Primer sur la répartition du routage

​

Implémentation gloutonne

remaining = X
routes    = []
step      = X / 1000     // taille de la tranche
while remaining > 0:
    best_pool = argmax over i of f'_i(current_x_i + step)
    x_i += step
    routes.append((best_pool, step))
    remaining -= step

​

Implémentation par optimisation convexe

• Constant-product (CPMM / AMM v4) : f'(x) = y * R_y / (R_x + x)^2 où R_x, R_y sont les réserves et y = R_x * R_y / (R_x + x) - R_y … (dérivation plus simple : le prix marginal est R_y / (R_x + x), donc la répartition pour égaliser les prix marginaux est une recherche 1D).
• CLMM : lisse par morceaux — dans un tick, f'(x) est une fonction rationnelle de sqrt_price ; à travers un tick, il change discrètement. Répartissez avec un solveur petit-step ou traitez chaque tick contigu comme son propre « pool ».

​

Quand la répartition aide

​

Routes multi-hop

tokenA → tokenHub → tokenB

• Son propre slippage bound (plus bas sur les hops directs ; par-hop sur les multi-hop).
• Ses propres frais.
• Son propre impact de prix.

​

Attaques sandwich

​

Mécanisme

1. Front-run : le bot achète le même token avant vous, poussant le prix du pool à la hausse.
2. Tx victime : vous swappez à un prix pire.
3. Back-run : le bot vend au prix élevé, capturant le spread.

​

Atténuations

​

Bundles Jito

​

Comment les bundles fonctionnent

• Connectez-vous à un endpoint Jito block engine (ex. https://mainnet.block-engine.jito.wtf).
• Soumettez un bundle de 1–5 transactions plus un tip à l’un des comptes tip Jito.
• Si le leader actuel exécute Jito, votre bundle est considéré. Le gagnant de l’enchère pour ce slot (bundle avec le plus haut tip-par-CU) atterrit ; les autres sont abandonnés.

​

Taille du tip

const tipRes = await fetch("https://worker.jito.wtf/api/v1/bundles/tip_floor");
const tips   = await tipRes.json();
// { ema_landed_tips_25th_percentile, 50th, 75th, 95th, 99th }

// Un swap user-facing un jour normal — le 50e percentile suffit.
const tipSol = tips.ema_landed_tips_50th_percentile_lamports / 1e9;

// Un trade bot critique en temps lors de congestion — 75–95e percentile.

​

Construire un bundle

import { SearcherClient } from "jito-ts";

const client = new SearcherClient("https://mainnet.block-engine.jito.wtf");

const tipIx = SystemProgram.transfer({
  fromPubkey: user.publicKey,
  toPubkey:   JITO_TIP_ACCOUNTS[Math.floor(Math.random() * 8)],  // 8 tip accts
  lamports:   tipLamports,
});

const tx1 = new VersionedTransaction(...);  // le swap
tx1.sign([user]);

const bundleUuid = await client.sendBundle([tx1], tipLamports);
// Optionnel : await confirmation via client.getBundleStatuses([bundleUuid])

• Le tip doit être dans le bundle. Incluez le SystemProgram.transfer à un compte tip Jito comme instruction dans l’une des transactions du bundle (généralement la dernière). Un tip tx séparé qui ne fait pas partie du bundle est ignoré.
• Le leader n’est pas Jito-activé. ~75% des leaders exécutent Jito ; ~25% ne le font pas. Les bundles envoyés quand un leader non-Jito tient le slot sont abandonnés. Le client renverra automatiquement.
• Expiry. Les bundles utilisent le même modèle d’expiry blockhash que les txs régulières. Assemblez et envoyez rapidement ; fenêtre ~60s.

​

Bundles vs frais de priorité

​

MEV-share / RPC révert-protégé

• Helius — connexions staked avec support bundle.
• QuickNode — endpoint « Revert Protect » ; forme automatiquement des bundles autour des txs soumises.
• Triton — tier private-flow.

​

Gestion de la congestion

• Les txs restent unconfirmed pendant 60+ secondes, puis expirent avec « blockhash not found ».
• Les frais de priorité qui fonctionnaient hier sont insuffisants aujourd’hui.
• La simulation réussit mais l’exécution n’atterrit jamais.

1. Retry agressif en cas d’expiry. Sur TransactionExpiredBlockheightExceeded, rebâtissez avec un nouveau blockhash et renvoyez. N’essayez pas de renvoyez en cas de revert — les reverts sont déterministes.
2. Broadcast multi-RPC. Soumettez la même tx à plusieurs RPC en parallèle ; celui qui atteint un leader en premier gagne.
3. Ramping des frais de priorité. Commencez au 50e percentile ; si la première tentative expire, renvoyez au 75e, puis au 95e.
4. Bundles Jito comme fallback. Les leaders Jito tendent à être moins congestionnés parce que le block engine trie les bundles par tip-par-CU ; les bundles haute-tip obtiennent la priorité.
5. Simulez moins. En congestion, simulez une fois en avant ; ne re-simulez pas en envoi puisque l’état du pool aura changé de toute façon. La re-simulation en congestion échoue souvent spurieusement.

​

Considérations MEV par-produit

​

Liste de vérification

• Slippage par défaut ≤0,5% sur les paires normales ; utilisateur peut overrider.
• Soumission de bundle Jito activée par défaut pour les swaps >$1k USD.
• Frais de priorité sourced d’une estimation live (pas hard-coded).
• Logique de retry distingue revert (ne renvoyez pas) d’expiry (renvoyez avec nouveau blockhash).
• Routes multi-hop définissent les minimums par-hop, pas de bout-en-bout.
• Routage réparti actif pour les trades >1% du TVL de tout pool unique.
• Fraîcheur du pool : re-fetch l’état immédiatement avant soumission ; re-quote si stale.
• Sandwich-résistant sur les pools peu profonds : soit Jito-seulement, soit rejet si slippage >1%.

​

Pointeurs

• integration-guides/aggregator — découverte pool, quoting, assemblage de transaction.
• integration-guides/priority-fee-tuning — dimensionnement CU et frais de priorité.
• integration-guides/cpi-integration — composition multi-hop single-slippage-gate.
• algorithms/slippage-and-price-impact — définitions formelles.

• Jito docs
• Solana validator docs on priority fees
• jito-ts — client bundle TypeScript.