Qu'est-ce qu'une liquidité insuffisante sur un DEX ?

Une liquidité insuffisante sur un échange décentralisé signifie que le pool de votre paire de trading ne peut pas fournir une quantité suffisante du token souhaité dans la limite de slippage choisie. Le contrat calcule le résultat attendu, le compare à votre minimum et rejette la transaction lorsque ce seuil ne peut être atteint.

Les automated market makers fixent le prix des transactions en fonction du ratio des tokens détenus dans un pool. Acheter d'un côté modifie ce ratio et fait grimper son prix. Lorsqu'un ordre est important par rapport aux réserves disponibles, le taux peut varier suffisamment pour que la cotation initiale ne soit plus valable. L'interface affiche alors une erreur avant qu'aucun gas ne soit dépensé.

Les paires profondes telles que ETH/USDC sur Uniswap peuvent absorber des swaps à sept chiffres avec seulement une fraction pour cent d'impact sur le prix. Les nouveaux tokens, memecoins et autres actifs à longue traîne sont différents. Leurs pools détiennent souvent moins de 100 000 $, ce qui rend un ordre de 5 000 $ suffisant pour consommer une partie visible d'une réserve.

Causes d'une liquidité insuffisante pour ce trade

Plusieurs conditions peuvent déclencher la même erreur. Des réserves peu profondes sont les plus courantes, bien que la liquidité concentrée, la fragmentation des chaînes, la mécanique des tokens et la logique de hook personnalisée puissent produire un résultat identique.

Comment corriger l'erreur de liquidité insuffisante pour ce trade

Pour effacer l'erreur, donnez plus de marge au contrat pour s'exécuter ou acheminez l'ordre vers des réserves plus profondes. Les quatre méthodes ci-dessous vont de la solution la plus simple à la plus technique.

Solution 1 : Utiliser un agrégateur de DEX

Un agrégateur de DEX tel que 1inch, Jupiter ou KyberSwap vérifie des dizaines de pools au lieu de dépendre d'une seule plateforme. Il peut diviser l'ordre entre plusieurs sources et finaliser le tout en une seule transaction, ce qui résout souvent l'erreur sans modifier vos paramètres.

Suivez ces étapes pour exécuter un swap via un agrégateur :

1. Connecter le wallet : Ouvrez l'interface de l'agrégateur et connectez un crypto wallet en self-custody. Vérifiez que vous vous trouvez sur la blockchain où le token dispose du pool le plus profond.
2. Sélectionner les actifs : Choisissez le token que vous détenez, puis collez l'adresse exacte du contrat pour le token de sortie. Un ticker seul peut correspondre à des tokens usurpés dotés de pools vides.
3. Examiner la répartition : Vérifiez la route d'exécution proposée. Une cotation saine divise souvent l'échange entre plusieurs plateformes ou versions de pool au lieu de l'imposer à travers un seul pool peu profond.
4. Comparer l'impact : Comparez l'impact sur le prix affiché avec la cotation du pool direct. Tout dépassement de 2 % constitue un avertissement indiquant que le token manque de profondeur sur cette blockchain.
5. Définir la tolérance : Conservez le slippage par défaut de l'agrégateur pour les paires majeures. Augmentez-le uniquement par de petits paliers si la simulation signale toujours un déficit de sortie.
6. Confirmer le swap : Signez la transaction, puis comparez le montant reçu avec la sortie minimale affichée avant l'approbation.

Solution 2 : Ajuster les paramètres de tolérance au slippage

Chaque swap inclut une sortie minimale dérivée de votre paramètre de slippage. Si la sortie estimée du pool descend en dessous de ce seuil, le contrat rejette la transaction. Une tolérance plus élevée abaisse le minimum, donnant à un pool volatil ou peu profond plus de marge pour s'exécuter à un pire taux.

Augmentez-le progressivement. Passez de 0,5 % à 1 %, puis à 2 %, et arrêtez-vous dès que la cotation réussit. Chaque point de pourcentage supplémentaire représente de la valeur que vous avez acceptée de perdre et donne aux bots de sandwich plus de latitude pour exploiter la transaction. La documentation de dépannage de PancakeSwap recommande la même approche incrémentielle pour les tokens à frais de transfert.

Solution 3 : Fragmenter la taille totale de votre trade

Diviser un ordre important en plusieurs swaps plus petits réduit le mouvement de prix causé par chaque exécution. Cela donne également le temps aux bots d'arbitrage de rééquilibrer le pool entre les transactions, bien que vous payiez du gas supplémentaire.

Utilisez cette méthode manuelle lorsqu'un agrégateur signale toujours un déficit :

1. Dimensionner les parties : Divisez l'ordre en morceaux ne représentant pas plus de 2 % à 3 % de la valeur totale verrouillée du pool. Cela permet de maintenir l'impact sur le prix par exécution sous les 1 %.
2. Exécuter d'abord : Exécutez le premier morceau et enregistrez la sortie exacte. Surveillez le pool sur DexScreener pour voir à quelle vitesse son prix récupère.
3. Patienter brièvement : Laissez aux bots d'arbitrage quelques blocs pour rééquilibrer la paire avant de placer le trade suivant. Cela prend moins d'une minute sur Ethereum et quelques secondes sur Solana.
4. Répéter les exécutions : Continuez avec des morceaux égaux jusqu'à ce que la position soit complète. Réduisez la taille si l'impact sur le prix lors d'une exécution dépasse votre seuil choisi.
5. Suivre le coût : Additionnez les coûts de gas et les prix réalisés de chaque exécution. Comparez le total avec la cotation du swap unique d'origine, car la fragmentation n'a de sens que lorsque le coût final est inférieur.
6. Automatiser ensuite : Pour les trades récurrents, appliquez la même approche via un ordre programmé ou pondéré dans le temps sur Jupiter ou CoW Swap afin que la division s'effectue sans signature manuelle.

Solution 4 : Trader via une paire intermédiaire liquide

Les pools directs entre deux tokens mineurs sont souvent peu profonds. Les deux actifs peuvent toujours disposer d'une liquidité importante face à ETH, SOL ou USDC. Trader via l'un de ces actifs majeurs utilise deux pools liquides au lieu de forcer l'intégralité de l'ordre à travers une paire directe peu profonde.

Les agrégateurs empruntent déjà cette route automatiquement lorsqu'elle génère une meilleure cotation. Chaque saut ajoute des frais de pool supplémentaires et, sur Ethereum, un coût de gas supplémentaire. La dépense additionnelle est négligeable sur Solana, où Jupiter peut router un ordre de memecoin unique à travers plusieurs pools Raydium, Orca et Meteora lorsque cela produit une meilleure exécution.

Qu'est-ce que le slippage dans la crypto ?

Le slippage est la différence entre le prix coté lorsque vous soumettez un swap et le prix auquel il s'établit finalement onchain. Les blocs ont besoin de temps pour confirmer, d'autres ordres peuvent déplacer le pool avant que le vôtre n'arrive, et votre propre trade modifie le prix au fur et à mesure de son exécution.

L'impact sur le prix désigne spécifiquement le mouvement provoqué par votre ordre. Sa taille dépend de l'échange par rapport à la liquidité disponible. Un swap de 1 000 $ n'affecte pratiquement pas un pool de 10 millions de dollars, tandis que le même ordre peut faire bouger un pool de 50 000 $ de plusieurs pourcents.

La tolérance au slippage définit le pire taux que vous êtes disposé à accepter. Si la sortie finale passe sous ce plancher, le contrat rejette le swap. Des limites strictes protègent le trade mais échouent plus souvent dans les pools minces. Des limites souples améliorent les chances d'exécution tout en exposant davantage de valeur aux bots.

Une liquidité insuffisante peut-elle se produire sur n'importe quel DEX ?

L'erreur provient du modèle de teneur de marché automatisé (automated market maker), où les réserves mises en commun remplacent une contrepartie directe. Les plateformes de carnet d'ordres (order book) ne renvoient pas le même message, bien que des carnets peu profonds puissent tout de même générer des exécutions partielles et des spreads importants.

Les plateformes de carnet d'ordres telles que Hyperliquid confrontent les trades aux limit orders en attente. Un ordre d'achat important au prix du marché (market buy) progresse donc à travers le carnet à des prix moins favorables au lieu d'échouer en raison d'une liquidité de pool insuffisante. Le guide de Datawallet sur les dex (decentralized perpetual exchanges) explique comment ces carnets d'ordres gèrent la profondeur et les spreads en période de forte volatilité.

Pourquoi la liquidité Onchain continue de se fragmenter

Un seul token peut désormais s'échanger sur plusieurs chaînes, versions de pool et paliers de frais. Chaque marché a besoin d'une profondeur indépendante suffisante pour qu'un ordre direct soit exécuté sans déclencher d'erreur de liquidité.

Les hooks d'Uniswap V4 multiplient les pools par paire

Uniswap V4 permet à n'importe qui d'associer un contrat hook à un pool. Les hooks peuvent modifier les frais, restreindre les participants ou changer le comportement de la liquidité lors d'un swap. Chaque hook crée un pool distinct pour la même paire. Un token peut ainsi compter une douzaine de pools V4 en plus de ses marchés V2 et V3, répartissant les réserves sur un plus grand nombre de plateformes.

L'analyse d'Uniswap V4 par Datawallet explique comment le routeur universel compare les prix V2, V3 et V4 au sein d'une seule transaction et peut diviser les ordres entre les différentes versions. Un pool avec hook sélectionné manuellement contourne cette comparaison. C'est pourquoi un swap routé par une interface peut réussir alors qu'un trade sur un pool direct échoue.

Les Layer 2 et les silos de Solana divisent la profondeur par chaîne

Les classements sur 30 jours glissants de DefiLlama au début du mois d'août placent Solana près de 50 milliards de dollars de volume de DEX spot. BNB Chain suit avec 31 milliards de dollars, Ethereum avec 29 milliards de dollars et Base avec 22 milliards de dollars, selon The Defiant. Un token déployé sur quatre chaînes a toujours besoin de quatre pools financés séparément. La plupart des projets concentrent leur liquidité sur une seule chaîne.

La série DEX-to-CEX de The Block a enregistré un volume spot onchain atteignant 24 % du volume des plateformes centralisées en juillet 2026, soit le niveau le plus élevé depuis le début du suivi en 2019. Le volume absolu des DEX a chuté de 26 % au cours du même mois. Avec moins d'arbitragistes actifs pour rétablir l'équilibre après des transactions importantes, un pool déséquilibré peut le rester plus longtemps.

Les tranches (bins) concentrées sortent de la plage

Les pools DLMM de Meteora et CLMM de Raydium placent le capital dans des tranches de prix distinctes sélectionnées à l'avance par les fournisseurs de liquidité. Le slippage est proche de zéro tant que le marché s'échange dans une tranche active. Dès que le prix sort de la plage configurée, cette liquidité cesse de participer aux swaps. Le pool utilisable peut alors s'avérer bien plus petit que ne le suggère sa valeur totale verrouillée (TVL) globale.

Comment éviter les problèmes de liquidité insuffisante

Éviter l'erreur coûte moins cher que de la corriger après la soumission. Les transactions Ethereum échouées consomment toujours du gas, tandis que les swaps réussis avec un slippage excessif perdent de la valeur lors de l'exécution. Les trois pratiques ci-dessous aident à identifier une liquidité superficielle avant de signer.

1. Utiliser des solveurs basés sur les intents au lieu de swaps directs

Les systèmes d'intents tels que CoW Swap, UniswapX et 1inch Fusion fonctionnent différemment des transactions AMM directes. Vous signez un ordre décrivant le résultat souhaité plutôt que de spécifier exactement la manière dont le trade doit s'exécuter.

Les solveurs s'affrontent ensuite pour obtenir l'exécution via des pools publics, des teneurs de marché privés ou des ordres d'utilisateurs opposés. Si aucun ne peut satisfaire votre limite, vous ne payez rien.

Selon TheStreet, CoW traite environ 22 % du volume des agrégateurs sur Ethereum. KyberSwap représente environ 31 % et 1inch près de 15 %, tandis que Jupiter valide près de 95 % du volume des agrégateurs sur Solana. Parce que les solveurs peuvent accéder à une profondeur qu'une seule interface de pool ne peut voir, ils éliminent la plupart des erreurs de liquidité sur les tokens établis.

2. Vérifier la profondeur Onchain avant de signer

Une minute passée à vérifier les données onchain peut indiquer si un pool est capable d'absorber votre ordre. Cela importe particulièrement pour les pools de lancement, les memecoins et les tokens que vous n'avez pas encore échangés sur cette chaîne.

Vérifiez ces chiffres sur DexScreener ou DefiLlama avant d'envoyer un ordre conséquent :

• Pool TVL : Confirmez que le pool spécifique détient au moins dix fois la valeur de votre ordre. Tout montant inférieur peut pousser l'impact sur le prix au-delà de la tolérance utilisée par la plupart des interfaces.
• Répartition des réserves : Inspectez les deux actifs plutôt que de vous fier uniquement à la TVL totale. Un pool affichant 200 000 $ peut toujours contenir 190 000 $ en USDC et presque rien du token que vous souhaitez.
• Ratio de volume : Comparez le volume sur 24 heures avec la TVL. Les pools où le volume quotidien dépasse les réserves de plusieurs fois peuvent fluctuer brusquement et se déséquilibrer entre les cycles d'arbitrage.
• Correspondance de chaîne : Assurez-vous que le pool le plus profond se trouve sur la chaîne connectée à votre wallet, et non sur un autre déploiement où le même token s'échange plus activement.
• Plage active : Avec les pools DLMM et CLMM, confirmez que le prix actuel se trouve à l'intérieur des plages (bins) approvisionnées. Le capital situé en dehors de la plage active ne contribue en rien à votre exécution.
• Audit du token : Ouvrez le contrat dans un explorateur de blocs. Vérifiez la présence de taxes de transfert, de restrictions de vente ou de fonctions de propriétaire qui pourraient rendre un pool apparemment sain impossible à quitter.
• Trades récents : Examinez la dernière douzaine de swap en termes de taille et de direction. Des ventes importantes répétées sans achats correspondants peuvent indiquer un pool susceptible de rejeter votre ordre ou de le pénaliser lourdement.
• Heures de trading : Privilégiez les heures qui se chevauchent entre les États-Unis et l'Europe, lorsque les bots d'arbitrage et les market makers sont les plus actifs et que les réserves ont tendance à se rééquilibrer plus rapidement.

DefiLlama suit la TVL et le volume au niveau des pools sur plus de 500 chaînes. Son tableau de bord DEX est le moyen le plus rapide d'identifier quelle chaîne détient le pool le plus profond pour un token.

3. Diviser les grands ordres avec le TWAP

Un ordre à prix moyen pondéré dans le temps (time-weighted average price) divise une position importante en tranches égales soumises à intervalles fixes. Chaque partie atteint ainsi un pool qui a eu le temps de se rééquilibrer. Les ordres récurrents de Jupiter, le produit TWAP de CoW Swap et plusieurs interfaces de DEX perpetual fournissent cette fonctionnalité sans nécessiter de scripts personnalisés.

Les ordres récurrents de Jupiter font également varier l'intervalle entre les sous-ordres. Cela rend la prochaine exécution plus difficile à prédire pour les bots et réduit la fenêtre de sandwich créée par un calendrier fixe. Pour les ordres dépassant environ 5 % de la profondeur du pool, le TWAP est le seul moyen fiable d'éviter à la fois l'erreur de liquidité et un impact sévère sur le prix.

Explication des messages d'erreur de swap courants

L'avertissement de liquidité insuffisante n'est que l'une des nombreuses erreurs de swap liées aux conditions d'exécution. Identifier le message exact aide à cibler la correction appropriée.

Associez le message affiché sur votre écran à sa cause et à sa solution ci-dessous :

• INSUFFICIENT_OUTPUT_AMOUNT : Le routeur Uniswap V2 ou PancakeSwap a calculé un montant de sortie inférieur à votre minimum. Augmentez légèrement la tolérance ou réduisez la taille de l'ordre, et vérifiez si le token applique une taxe de transfert.
• INSUFFICIENT_LIQUIDITY : Un côté du pool contient trop peu de stock pour fournir le montant demandé à n'importe quel prix. Passez par un agrégateur ou utilisez un intermédiaire en actif majeur.
• Impact trop élevé : L'interface a bloqué un trade qui aurait déplacé le prix au-delà de sa limite de sécurité intégrée. Divisez l'ordre au lieu de contourner l'avertissement.
• Délai expiré : La transaction est restée en attente au-delà de son délai imparti, souvent en raison d'une hausse soudaine du gas. Demandez un nouveau devis et renvoyez-la avec un priority fee légèrement plus élevé.
• TRANSFER_FROM_FAILED : Le contrat du token a refusé de transférer les fonds. Les causes possibles incluent une approbation manquante, une liste noire ou un honeypot. Vérifiez le contrat avant de réessayer.
• Slippage dépassé : Le code d'erreur Solana 0x1771 de Jupiter indique que l'exécution s'est produite en dehors de votre limite. Réessayez en activant le slippage dynamique ou utilisez un réglage fixe légèrement plus large.
• Exécution annulée (Execution reverted) : Il s'agit d'un échec générique sans chaîne de motif, fréquent sur les pools V4 dotés de hooks ou les AMM personnalisés. Essayez la route par défaut de l'interface plutôt que de sélectionner un pool manuellement.
• Aucun devis : L'agrégateur n'a trouvé aucune route disposant de suffisamment de liquidité sur la chaîne actuelle. Vérifiez l'adresse du contrat et regardez si le token s'échange ailleurs.

Gestion des risques en cas de slippage élevé

Augmenter le slippage est le moyen le plus rapide de contourner l'erreur, mais cela peut aussi détruire de la valeur. Une tolérance large donne aux bots de sandwich plus de marge pour tirer profit de votre transaction.

Appliquez ces mesures de protection chaque fois que vous définissez une tolérance supérieure à 1 % :

• Soumission privée : acheminez la transaction via Flashbots Protect ou MEV Blocker. Cela évite qu'elle ne se retrouve dans le mempool public où les bots recherchent les swaps à haute tolérance à attaquer en sandwich.
• Plafond de perte : convertissez le pourcentage de tolérance en dollars avant de signer. Une limite de 5 % sur un swap de 20 000 $ autorise jusqu'à 1 000 $ de perte.
• Enchère par lots : envoyez la même transaction via CoW Swap ou une autre plateforme d'intentions. Le règlement par lots à un prix uniforme supprime l'avantage lié à l'ordre des transactions exploité lors des attaques en sandwich.
• Plafond pour les stablecoins : maintenez le slippage à un niveau inférieur ou égal à 0,1 % pour les paires de stablecoins. Cointelegraph Research a constaté qu'environ 40 % des attaques en sandwich visaient des pools à faible volatilité où les traders ne s'attendent à aucune variation.
• Vérification minimale : concentrez-vous sur le montant minimal reçu plutôt que sur la sortie estimée. Une fois que vous avez signé, le minimum est le seul montant appliqué par le contrat.
• Gestion du gas : évitez les swaps à haute tolérance en période de congestion du réseau. Une annulation sur Ethereum coûte tout de même du gas, et une nouvelle tentative à un pire prix aggrave la perte initiale.
• Délai court : limitez le délai d'expiration de la transaction à quelques minutes. Un ordre bloqué doit expirer plutôt que de s'exécuter plus tard à un prix obsolète.
• Test de swap : commencez par un petit ordre pour mesurer l'impact réel et confirmer que le token peut être revendu. Augmentez la taille de l'ordre uniquement après avoir validé ces deux points.

L'extraction de valeur par attaques en sandwich sur Ethereum est passée de près de 10 millions de dollars par mois fin 2024 à environ 2,5 millions de dollars en octobre 2025, selon le même ensemble de données de Cointelegraph et EigenPhi. Le nombre mensuel d'attaques est resté compris entre 60 000 et 90 000. Les bots sont toujours actifs, mais les traders protégés ont cessé de leur fournir autant de valeur.

Dernières réflexions

L'erreur de liquidité insuffisante pour cette transaction est une mesure de protection. Elle apparaît lorsqu'un pool ne peut pas fournir votre sortie minimale, et traiter cet avertissement comme une information sur le pool est plus sûr que de simplement outrepasser la règle.

Les agrégateurs DEX et les solveurs basés sur les intentions peuvent accéder à une liquidité qu'une interface de pool unique ne peut pas voir. Pour les tokens établis, ils résolvent la plupart des erreurs de liquidité sans nécessiter un slippage plus élevé.

Les actifs à longue traîne nécessitent davantage de vigilance. Vérifiez la profondeur disponible, fragmentez les ordres importants si nécessaire et utilisez la soumission privée pour couvrir le risque d'exécution restant.