Qu'est-ce que la liquidité insuffisante sur un DEX ?

Une liquidité insuffisante sur une plateforme d'échange décentralisée signifie que la pool de votre paire de trading ne peut pas fournir assez du jeton souhaité dans la limite de slippage que vous avez choisie. Le contrat calcule le montant attendu, le compare à votre minimum et rejette la transaction lorsque ce seuil ne peut pas être atteint.

Les teneurs de marché automatisés fixent les prix des transactions à partir du ratio de jetons détenus dans un pool. Acheter un côté modifie ce ratio et fait monter son prix. Lorsqu'un ordre est important par rapport aux réserves disponibles, le taux peut évoluer au point que la cotation initiale ne tient plus. L'interface affiche alors une erreur avant que du gas ne soit dépensé.

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

Causes d'une liquidité insuffisante pour cette transaction

Plusieurs causes peuvent provoquer la même erreur. Le manque de réserves est la plus fréquente, mais une liquidité concentrée, la fragmentation des chaînes, la mécanique des jetons et une logique de hook personnalisée peuvent produire un résultat identique.

Comment corriger l'erreur de liquidité insuffisante pour cette transaction

Pour résoudre l'erreur, laissez au contrat plus de marge d'exécution 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 DEX

Un agrégateur de DEX comme 1inch, Jupiter ou KyberSwap examine des dizaines de pools au lieu de dépendre d'une seule place de marché. Il peut répartir l'ordre entre plusieurs sources et tout régler 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. Connectez votre wallet : ouvrez l'interface de l'agrégateur et connectez un wallet crypto en auto-conservation. Vérifiez que vous êtes sur la chaîne où le jeton dispose de son pool le plus profond.
2. Sélectionnez les actifs : choisissez le jeton que vous détenez, puis collez l'adresse exacte du contrat du jeton de sortie. Un simple ticker peut correspondre à des jetons imitateurs dont les pools sont vides.
3. Vérification : examinez la route d'exécution proposée. Une cotation saine répartit souvent l'opération entre plusieurs places ou versions de pools plutôt que de la forcer via un seul pool peu profond.
4. Comparez l'impact : comparez l'impact sur le prix affiché avec la cotation directe du pool. Tout niveau supérieur à 2 % indique que le jeton manque de profondeur sur cette chaîne.
5. Définissez la tolérance : Conservez le slippage par défaut de l'agrégateur pour les principales paires. Ne l'augmentez que par petits paliers si la simulation signale encore un déficit de montant reçu.
6. Confirmer le swap : signez la transaction, puis comparez le montant reçu avec le minimum affiché avant l'approbation.

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

Chaque swap comprend un montant minimum reçu, calculé à partir de votre réglage de slippage. Si le montant projeté du pool tombe sous ce seuil, le contrat rejette la transaction. Une tolérance plus élevée abaisse ce minimum et laisse à un pool volatil ou peu profond plus de marge pour exécuter à un taux moins favorable.

Augmentez-la progressivement. Passez de 0,5 à 1 % à 2 %, en vous arrêtant dès que la cotation aboutit. Chaque point de pourcentage supplémentaire représente une valeur que vous acceptez de perdre et laisse aux bots sandwich plus de marge pour exploiter la transaction. La documentation de dépannage de PancakeSwap recommande la même approche progressive pour les jetons avec frais de transfert.

Solution 3 : fractionner la taille totale de votre transaction

Fractionner un gros ordre en plusieurs swaps plus petits réduit le mouvement de prix causé par chaque exécution. Cela laisse aussi aux bots d'arbitrage le temps de rééquilibrer le pool entre deux transactions, même si vous payez des frais de gas supplémentaires.

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

1. Fractionnez les ordres : divisez l'ordre en tranches ne dépassant pas 2 à 3 % de la valeur totale verrouillée du pool. Cela maintient l'impact sur le prix par exécution sous 1 %.
2. Exécutez d'abord : lancez la première tranche et notez le résultat exact. Surveillez le pool sur DexScreener pour voir à quelle vitesse son prix se rétablit.
3. Patientez brièvement : laissez aux bots d'arbitrage quelques blocs pour rééquilibrer la paire avant de passer l'ordre suivant. Cela prend moins d'une minute sur Ethereum et quelques secondes sur Solana.
4. Répétez les exécutions : poursuivez avec des tranches égales jusqu'à ce que la position soit complète. Réduisez la taille si l'impact sur le prix d'une exécution dépasse le seuil que vous avez choisi.
5. Suivez le coût : additionnez les frais de gas et les prix réalisés de chaque exécution. Comparez le total avec la cotation initiale d'un swap unique, car le fractionnement n'a de sens que si le coût final est inférieur.
6. Automatiser plus tard : pour les opérations récurrentes, appliquez la même approche via un ordre programmé ou pondéré dans le temps sur Jupiter ou CoW Swap, afin que le fractionnement se fasse sans signature manuelle.

Solution 4 : passer par une paire d'intermédiaires liquides

Les pools directs entre deux jetons mineurs sont souvent peu profonds. Les deux actifs peuvent néanmoins avoir une liquidité importante face à ETH, SOL ou USDC. Passer par l'un de ces actifs majeurs mobilise deux pools liquides au lieu de forcer tout l'ordre dans une paire directe peu profonde.

Les agrégateurs empruntent déjà ce chemin automatiquement lorsqu'il produit une meilleure cotation. Chaque saut ajoute des frais de pool et, sur Ethereum, un coût de gas supplémentaire. Le surcoût est négligeable sur Solana, où Jupiter peut router un seul ordre de memecoin à travers plusieurs pools Raydium, Orca et Meteora lorsque cela donne une meilleure exécution.

Qu'est-ce que le slippage en crypto ?

Le slippage est l'écart entre le prix indiqué lorsque vous soumettez un swap et le prix auquel il est finalement réglé onchain. Les blocs ont besoin de temps pour être confirmés, d'autres ordres peuvent déplacer le pool avant le vôtre, et votre propre transaction 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. Son ampleur dépend de la taille de la transaction par rapport à la liquidité disponible. Un swap de 1 000 $ affecte à peine un pool de 10 millions de dollars, alors que le même ordre peut faire bouger de plusieurs pour cent un pool de 50 000 $.

La tolérance de slippage définit le pire taux que vous acceptez. Si le montant final passe sous ce seuil, le contrat rejette le swap. Des limites serrées protègent la transaction mais échouent plus souvent dans les pools peu profonds. Des limites larges augmentent les chances d'exécution mais exposent davantage de valeur aux bots.

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

L'erreur provient du modèle de teneur de marché automatisé, où des réserves mutualisées remplacent une contrepartie en direct. Les plateformes à carnet d'ordres ne renvoient pas le même message, même si des carnets peu profonds peuvent tout de même produire des exécutions partielles et des écarts importants.

Les plateformes à carnet d'ordres comme Hyperliquid exécutent les transactions face à des ordres à cours limité en attente. Un gros achat au marché progresse donc dans le carnet à des prix de plus en plus défavorables au lieu d'échouer faute de liquidité dans un pool. Le guide de Datawallet sur les plateformes d'échange décentralisées de contrats perpétuels explique comment ces carnets d'ordres gèrent la profondeur et les spreads en période de volatilité.

Pourquoi la liquidité Onchain continue de se fragmenter

Un même jeton peut désormais s'échanger sur plusieurs chaînes, versions de pools et niveaux de frais. Chaque marché a besoin d'une profondeur indépendante suffisante pour qu'un ordre direct s'exécute sans déclencher d'erreur de liquidité.

Uniswap V4 : les hooks multiplient les pools par paire

Uniswap V4 permet à quiconque d'associer un contrat hook à un pool. Les hooks peuvent modifier les frais, restreindre qui peut négocier ou changer le comportement de la liquidité autour d'un swap. Chaque hook crée un pool distinct pour la même paire. Un jeton peut donc avoir une douzaine de pools V4 en plus de ses marchés V2 et V3, dispersant les réserves sur davantage de lieux d'échange.

L'analyse de Datawallet sur Uniswap V4 explique comment le Universal Router compare les prix de V2, V3 et V4 au sein d'une même transaction et peut répartir les ordres entre les versions. Un pool à hook sélectionné manuellement ignore cette comparaison. C'est pourquoi un swap routé par l'interface peut réussir alors qu'une transaction directe sur un pool échoue.

Layer 2 et silos Solana : la profondeur se répartit par chaîne

Les classements sur 30 jours glissants de DefiLlama, début août, plaçaient Solana à près de 50 milliards de dollars de volume DEX spot. BNB Chain suivait avec 31 milliards de dollars, Ethereum avec 29 milliards de dollars et Base avec 22 milliards de dollars, selon The Defiant. Un jeton déployé sur quatre chaînes nécessite tout de même quatre pools financés séparément. La plupart des projets concentrent leur liquidité sur une seule.

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

Les bins concentrés sortent de la plage

Les pools DLMM de Meteora et CLMM de Raydium placent le capital dans des intervalles de prix discrets, choisis à l'avance par les fournisseurs de liquidité. Le slippage est proche de zéro tant que le marché évolue dans un intervalle actif. Dès que le prix sort de la plage alimentée, cette liquidité cesse de participer aux swaps. Le pool réellement utilisable peut alors être bien plus petit que ne le suggère sa valeur totale verrouillée affichée.

Comment éviter les problèmes de liquidité insuffisante

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

1. Utilisez des solveurs basés sur l'intention plutôt que des swaps directs

Les systèmes d'intention 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 préciser exactement comment la transaction doit être exécutée.

Les solveurs se font ensuite concurrence pour trouver l'exécution auprès de pools publics, de teneurs de marché privés ou d'ordres d'utilisateurs opposés. Si aucun ne peut respecter votre limite, vous ne payez rien.

Selon TheStreet, CoW traite environ 22 % du volume des agrégateurs sur Ethereum. KyberSwap en représente environ 31 % et 1inch environ 15 %, tandis que Jupiter exécute près de 95 % du volume des agrégateurs sur Solana. Comme les solveurs peuvent accéder à une profondeur qu'une interface à pool unique ne voit pas, ils éliminent la plupart des erreurs de liquidité sur les jetons établis.

2. Vérifiez la profondeur Onchain avant de signer

Une minute passée à vérifier les données onchain peut montrer si un pool est capable d'absorber votre ordre. Cela compte surtout pour les pools de lancement, les memecoins et les jetons que vous n'avez encore jamais négociés sur cette chaîne.

Vérifiez ces chiffres sur DexScreener ou DefiLlama avant de passer un ordre important :

• TVL du pool : vérifiez que le pool concerné détient au moins dix fois la valeur de votre ordre. Un ratio plus faible 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 : examinez les deux actifs plutôt que de vous fier à la TVL totale. Un pool affichant 200 000 $ peut encore contenir 190 000 $ en USDC et presque aucun jeton de celui que vous souhaitez.
• Ratio de volume : comparez le volume sur 24 heures à la valeur totale verrouillée. Les pools dont le volume quotidien dépasse plusieurs fois les réserves peuvent fluctuer fortement et se déséquilibrer entre deux cycles d'arbitrage.
• Correspondance de la chaîne : vérifiez 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 jeton s'échange plus activement.
• Fourchette active : avec les pools DLMM et CLMM, vérifiez que le prix actuel se situe dans des bins alimentés. Le capital hors de la fourchette active ne contribue en rien à l'exécution de votre ordre.
• Audit du jeton : Ouvrez le contrat dans un explorateur de blocs. Vérifiez les taxes sur les transferts, les restrictions de vente ou les fonctions du propriétaire qui pourraient rendre impossible la sortie d'un pool apparemment sain.
• Transactions récentes : examinez la taille et le sens des douze derniers swaps. Des ventes importantes répétées sans achats correspondants peuvent signaler un pool susceptible de rejeter votre ordre ou de le pénaliser fortement.
• Horaires de trading : privilégiez les heures où les horaires américains et européens se chevauchent, lorsque les bots d'arbitrage et les teneurs de marché sont les plus actifs et que les réserves tendent à se rééquilibrer plus vite.

DefiLlama suit le TVL et le volume par pool sur plus de 500 chaînes. Son tableau de bord DEX est le moyen le plus rapide d'identifier la chaîne qui détient le pool le plus profond pour un jeton.

3. Fractionner les gros ordres avec TWAP

Un ordre au prix moyen pondéré dans le temps divise une grande position en tranches égales envoyées à intervalles fixes. Chaque tranche 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 DEX de contrats perpétuels offrent cette fonctionnalité sans nécessiter de scripts personnalisés.

Les ordres récurrents de Jupiter font aussi varier l'intervalle entre les sous-ordres. Cela rend la prochaine exécution plus difficile à prévoir 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 de prix sévère.

Messages d'erreur courants lors d'un swap expliqués

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

Associez le message affiché à l'é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 jeton applique une taxe sur les transferts.
• INSUFFICIENT_LIQUIDITY : un côté du pool contient trop peu d'inventaire pour fournir le montant demandé, quel que soit le prix. Passez par un agrégateur ou utilisez un intermédiaire sur un actif majeur.
• Impact trop élevé : l'interface a bloqué une transaction qui aurait déplacé le prix au-delà de sa limite de sécurité intégrée. Fractionnez l'ordre plutôt que d'ignorer l'avertissement.
• Délai expiré : la transaction est restée en attente au-delà de son délai, souvent à cause d'un pic de gas. Demandez un nouveau devis et renvoyez-la avec des frais de priorité légèrement plus élevés.
• TRANSFER_FROM_FAILED : le contrat du jeton 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 de Jupiter 0x1771 indique que l'exécution s'est située en dehors de votre limite. Réessayez avec le slippage dynamique activé ou utilisez un réglage fixe légèrement plus large.
• Exécution annulée : il s'agit d'un échec générique sans message d'explication, fréquent sur les pools V4 avec hooks ou les AMM personnalisés. Essayez l'itinéraire par défaut de l'interface plutôt que de sélectionner un pool manuellement.
• Aucune cotation : L'agrégateur n'a trouvé aucun itinéraire avec une liquidité suffisante sur la chaîne actuelle. Vérifiez l'adresse du contrat et regardez si le jeton s'échange ailleurs.

Gérer les 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 élevée laisse aux bots sandwich plus de marge pour tirer profit de votre transaction.

Appliquez ces garde-fous chaque fois que vous fixez une tolérance supérieure à 1 % :

• Soumission privée : faites passer la transaction par Flashbots Protect ou MEV Blocker. Cela la tient à l'écart du mempool public, où des bots recherchent des swaps à forte tolérance pour les « sandwicher ».
• Plafond de perte : convertissez la tolérance en pourcentage 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 à prix uniforme supprime l'avantage lié à l'ordre des transactions exploité dans les attaques sandwich.
• Plafond pour les stablecoins : maintenez le slippage à 0,1 % ou moins pour les paires de stablecoins. Cointelegraph Research a constaté qu'environ 40 % des attaques sandwich visaient des pools à faible volatilité, où les traders n'en attendent aucune.
• Vérification du minimum : concentrez-vous sur le montant minimum reçu plutôt que sur le montant estimé. Une fois que vous avez signé, le minimum est le seul montant garanti par le contrat.
• Moment du gas : évitez les swaps à forte tolérance lors des congestions du réseau. Une transaction Ethereum annulée coûte quand même du gas, et réessayer à un prix moins favorable aggrave la perte initiale.
• Délai court : limitez le délai de la transaction à quelques minutes. Un ordre bloqué doit expirer plutôt que de s'exécuter plus tard à un prix périmé.
• Swap de test : Commencez par un petit ordre pour mesurer l'impact réel et vérifier que le jeton peut être revendu. Augmentez uniquement après avoir validé ces deux contrôles.

L'extraction par 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 jeu de données de Cointelegraph et EigenPhi. Le nombre mensuel d'attaques est resté entre 60 000 et 90 000. Les bots sont toujours actifs, mais les traders protégés ne leur fournissent plus autant de valeur.

Conclusion

L'erreur de liquidité insuffisante pour cette transaction est une protection. Elle apparaît lorsqu'un pool ne peut pas fournir votre sortie minimale, et il est plus prudent de traiter cet avertissement comme une information sur le pool que de simplement le contourner.

Les agrégateurs de DEX et les solveurs basés sur l'intention peuvent accéder à une liquidité qu'une interface de pool unique ne voit pas. Sur les jetons établis, ils résolvent la plupart des erreurs de liquidité sans exiger un slippage plus large.

Les actifs à faible capitalisation demandent plus de soin. Vérifiez la profondeur disponible, fractionnez les gros ordres si nécessaire et utilisez la soumission privée pour couvrir le risque d'exécution restant.