Slippage et impact de prix

​

Deux concepts distincts

• L’impact de prix est une propriété déterministe d’un échange contre un état de pool spécifique. Étant donné (Δin, reserves), l’impact de prix est entièrement calculable avant la soumission de l’échange.
• Le slippage est la différence réalisée entre le prix que vous attendiez au moment du devis et le prix que vous avez réellement obtenu à l’exécution. C’est une fonction de la latence, des transactions concurrentes et de l’ordre d’inclusion des blocs — pas des mathématiques du pool.

​

Définitions formelles

​

Impact de prix

p_before = pool.spot_price()
p_after  = pool.spot_price_if_trade(Δin) applied
impact   = (p_before − p_after) / p_before       // peut être signé

​

Slippage réalisé

quoted_out = amount_out calculé au moment du devis
actual_out = amount_out observé on-chain
slippage   = (quoted_out − actual_out) / quoted_out

​

Dimensionnement de minAmountOut et maxAmountIn

• SwapBaseInput(amount_in, min_amount_out) — entrée exacte, limite inférieure de la sortie.
• SwapBaseOutput(max_amount_in, amount_out) — sortie exacte, limite supérieure de l’entrée.

// AMM v4 — le seul module avec une méthode littéralement appelée computeAmountOut
const computed = raydium.liquidity.computeAmountOut({
  poolInfo,            // nécessite baseReserve/quoteReserve/version/status intégrés
  amountIn,            // BN
  mintIn,
  mintOut,
  slippage: 0.005,     // tolérance de 0,5 %, un nombre simple
});
// -> { amountOut, minAmountOut, currentPrice, executionPrice, priceImpact, fee }
//    tous les montants sont des BNs simples

// CPMM
const { computePoolInfo } = await raydium.cpmm.getPoolInfoFromRpc(POOL_ID);
const cpmmQuote = raydium.cpmm.computeSwapAmount({
  pool: computePoolInfo, amountIn, outputMint: mintOut, slippage: 0.005,
});
// -> { amountIn, amountOut, minAmountOut, fee, executionPrice, priceImpact, swapResult, allTrade }

// CLMM — une statique PoolUtils, et elle a besoin de l'extension bitmap + un timestamp de bloc
const clmmQuote = PoolUtils.computeAmountOutFormat({
  poolInfo: computeClmmPoolInfo, tickarrayBitmapExtension, tickArrayCache,
  amountIn, tokenOut, slippage: 0.005,
  epochInfo: await raydium.fetchEpochInfo(),
  blockTimestamp: Math.floor(Date.now() / 1000),
});
// -> { amountOut, minAmountOut, fee, priceImpact, remainingAccounts, ... }

​

Tolérances de slippage recommandées

1. Stabilité de la paire. Les pools stablecoin-stablecoin peuvent utiliser en toute sécurité 0,1 %. Les pools de paires meme volatiles ont souvent besoin de 3–5 % juste pour atterrir de manière fiable.
2. Taille de l’échange. Les échanges plus importants ont des impacts de prix plus importants, donc la tolérance doit s’adapter à eux pour éviter une annulation. Les valeurs par défaut de slippage automatique du SDK tournent autour de max(0.5%, 2 × price_impact) pour cette raison.
3. Latence d’inclusion de bloc. Les transactions qui restent dans le mempool pendant plusieurs blocs sont exposées à plus d’échanges concurrents. Les bundles Jito et les frais de priorité réduisent cela.

​

Différences selon les types d’AMM

​

CPMM

​

AMM v4

• Cotez sur les soldes de coffre bruts. Il n’y a pas de composant on-book à ajouter — Initialize2 écrit AmmInfo.open_orders = Pubkey::default() sur chaque nouveau pool, et aucune instruction ne lit un compte OpenOrders.
• Soustrayez le PnL de protocole accumulé (state_data.need_take_pnl_coin / need_take_pnl_pc) des soldes de coffre pour obtenir les réserves que l’invariant utilise réellement.
• Il n’y a pas de crank à pré-exécuter : MonitorStep panique maintenant avec unimplemented! et ne doit pas être envoyé.

​

CLMM

​

Courbe LaunchLab

​

Considérations MEV

1. minAmountOut serré. Les limites de slippage agressives causent l’annulation de la transaction victime si elle est fortement sandwichée, protégeant les fonds (mais gaspillant du gaz). Sur Solana, c’est une pratique standard — le rejet est bon marché.
2. Bundles Jito. Soumettre via Jito avec un pourboire groupé exclut les intermédiaires de réorganiser votre tx. Les bundles atterrissent comme des blocs atomiques.
3. Frais de priorité. Un frais de priorité élevé augmente la chance que votre échange atterrisse dans le bloc du leader actuel avant qu’un sandwicher puisse réagir. Moins robuste que les bundles, plus standard.
4. RPC privé. Soumettre via un RPC privé (ou via un endpoint direct du validateur) réduit la fenêtre pendant laquelle un sandwicher mempool peut observer votre transaction.

​

Slippage pour les routes multi-hop

// Mauvais : 0,5 % appliqué à la fin seulement, donc tout hop intermédiaire glissant échoue le deuxième hop.
const finalMin = finalAmount * (1 - 0.005);

// Mieux : chaque hop applique sa propre limite.
const hop1Min  = hop1Amount * (1 - 0.005);
const hop2Min  = hop2Amount * (1 - 0.005);
// De bout en bout, c'est plus serré (composé), mais atomique — si l'un ou l'autre hop se dégrade, la tx s'annule tôt.

​

Rapport aux utilisateurs

• Affichez à la fois l’impact de prix attendu et la tolérance de slippage séparément.
• Mettez en évidence quand l’impact de prix dépasse ~2 % — avertissement « impact élevé ».
• Mettez en évidence quand l’impact de prix dépasse la tolérance — la transaction est presque certaine d’être annulée.
• Pour les paires volatiles, offrez un « mode slippage élevé » qui assouplit la limite et affiche un avertissement plus fort.

​

Pointeurs

• products/cpmm/math, products/amm-v4/math, products/clmm/math — dérivations d’impact par type de pool.
• integration-guides/routing-and-mev — routage multi-hop + défenses MEV.
• integration-guides/priority-fee-tuning — dimensionnement des frais de priorité pour réduire le slippage.

• Implémentation du slippage / impact du SDK Raydium v2.
• Flashbots / Jito sur Solana MEV.