Le slippage : pourquoi tu paies plus que prévu

L’idée en une phrase

Le slippage est l'écart entre le prix que tu attendais et le prix que tu obtiens vraiment.

Il a deux causes. Ton échange déplace lui-même le prix du pool : c'est l'impact sur le prix. Et d'autres transactions peuvent passer avant la tienne entre le moment où tu signes et celui où elle entre dans un bloc. La tolérance de slippage de ton interface sert à fixer la limite au-delà de laquelle tu préfères que l'échange échoue.

La démo

Sans JavaScript, prends un pool fictif de 1 000 ETH et 3 000 000 USDC, avec un prix illustratif de 3 000 USDC et 0,3 % de frais. Pour 30 000 USDC, tu espères 10 ETH et tu en reçois 9,872, soit 3 039,03 USDC par ETH et 1,3 % de surcoût. Avec 1 % de tolérance, un robot peut placer environ 15 211 USDC devant toi et gagner environ 210 USDC avant gas.

Pourquoi ça compte

Tu achètes un petit jeton pour l'équivalent de 30 000 USDC. L'interface annonce un prix, tu valides, et tu reçois nettement moins que ce que ce prix laissait prévoir. Personne ne t'a volé : le pool était simplement petit par rapport à ton ordre.

Le même achat sur un pool cent fois plus profond n'aurait presque rien coûté. Comprendre ce rapport entre taille et liquidité évite deux erreurs opposées : perdre de l'argent sur un ordre trop gros pour le marché, ou régler une tolérance si large qu'un robot peut s'en servir contre toi.

Le code

Ce code reproduit les calculs de la démo, attaque comprise. Change tolerance à 0.001 puis à 0.03 et compare le gain du robot, ou divise les réserves par dix.

Clique sur Lancer pour exécuter ce code dans ton navigateur.

Ce qui se passe vraiment

Lis d'abord les deux premières cases. Le prix affiché promet 10 ETH, le pool en donne 9,872. Le surcoût de 1,3 % vient de deux sources presque additives : 0,3 % de frais et 1 % d'impact sur le prix. Ce n'est pas un hasard : dans un pool x·y=k, sans frais, ton surcoût sur le prix moyen vaut exactement dx/x, ton montant divisé par la réserve. Tu apportes 1 % de la réserve d'USDC, tu paies 1 % de plus.

La case suivante surprend souvent. Le prix du pool monte d'environ 2 %, le double de ton surcoût. Ton prix moyen se situe à peu près à mi-chemin entre le prix de départ et le prix d'arrivée. Sur le graphique, la courbe du surcoût part de 0,3 %, le niveau des frais, et celle du prix du pool part de zéro, mais monte environ deux fois plus vite.

Bouge maintenant le curseur de réserve. Sur un pool de 30 000 000 USDC, le même achat coûte 0,4 %, dont 0,3 % de frais. Sur un pool de 300 000 USDC, le surcoût dépasse 10 %. La relation est linéaire : dix fois moins de liquidité, dix fois plus d'impact. À 20 % de la réserve, le surcoût atteint environ 20,3 %.

Passe ensuite au bouton d'attaque. Le minimum accepté vaut 9,773 ETH : c'est le montant reçu moins ta tolérance. Le robot calcule combien il peut acheter avant toi sans faire passer ton résultat sous cette ligne, puis revend juste après toi, sur un prix que tu as toi-même poussé. Avec 1 %, il gagne environ 210 USDC. Avec 0,1 %, il tombe à environ 21 USDC. Son gain suit ta tolérance presque en ligne droite.

La démo simplifie : elle ignore le gas du robot, qui peut annuler les petits gains, et sa concurrence avec d'autres robots. Elle suppose aussi qu'il dispose de tout le capital voulu.

Dans la vraie vie

Ta tolérance se traduit par un paramètre très concret : le montant minimum reçu, envoyé au contrat dans ta transaction. Si le résultat tombe en dessous, la transaction échoue et le pool ne bouge pas. Tu perds alors seulement le gas. Une tolérance basse protège mieux mais fait échouer plus souvent. Il n'existe pas de valeur universelle : elle dépend de la profondeur du pool et de l'agitation du marché.

Pour un gros montant, plusieurs solutions existent. Fractionner l'ordre en plusieurs échanges réduit l'impact si les arbitragistes ont le temps de remettre le pool à niveau entre deux. Passer par un agrégateur répartit l'ordre entre plusieurs pools. Une transaction envoyée par un canal privé échappe au mempool public, ce qui prive les robots de la vue préalable. Chacune de ces solutions ajoute ses propres frais ou sa propre confiance.

Ce mécanisme explique aussi pourquoi la profondeur compte plus que le volume annoncé. La liquidité d'un jeton peut paraître suffisante à l'achat et disparaître à la revente, surtout si le pool est petit ou si ses fournisseurs se retirent. Le calcul présenté ici vaut pour un pool à produit constant. Sur une liquidité concentrée, l'impact dépend de la quantité déposée autour du prix actuel.

Ce qui peut mal tourner

• Tolérance réglée au maximum. Mettre 10 % ou plus pour « que ça passe » offre cette marge aux robots. Sur un jeton illiquide, tu peux réellement perdre cette somme.
• Confondre tolérance et coût. L'impact sur le prix est certain, la tolérance est un plafond. Une tolérance de 1 % ne signifie pas que tu paies 1 %, et n'empêche pas un impact de 5 % déjà inclus dans le devis.
• Taxe cachée d'un jeton. Certains tokens prélèvent un pourcentage à chaque transfert. L'échange échoue alors à faible tolérance, et une interface suggère de monter le curseur : ce signal mérite une vérification, pas un clic.
• Devis périmé. Une interface restée ouverte peut montrer un prix ancien. Relis le montant minimum au moment de signer, c'est lui qui compte.
• Échange trop gros pour le pool. Le surcoût suit la formule dx/x. Compare toujours ton montant à la réserve avant de valider, surtout sur un token récent. Le simulateur de swap fait ce calcul à partir des réserves que tu saisis.

Teste-toi