--- title: "Bourse décentralisée (DEX) : swaps depuis un portefeuille, routage et risque d’exécution" description: "Découvrez comment une bourse décentralisée route et règle des opérations sur cryptoactifs autorisées depuis un portefeuille, les différences entre AMM et carnets d’ordres, et comment maîtriser les risques de slippage, d’approbation, de gas, de MEV et de token." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Bourse décentralisée (DEX) : swaps depuis un portefeuille, routage et risque d’exécution > À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Les opérations sur DEX peuvent perdre de la valeur en raison des mouvements de prix, d’une mauvaise exécution, de tokens malveillants, d’approbations, de la MEV ou d’une défaillance de contrat. ## Réponse directe Une bourse décentralisée (`DEX`) est un protocole ou un système de marché qui permet d’échanger des cryptoactifs sans les déposer au préalable sur un compte de négociation contrôlé par un opérateur. En général, l’utilisateur connecte un portefeuille dont il conserve le contrôle, obtient un devis, autorise le token requis et signe une transaction ou un ordre. Le règlement s’effectue ensuite par des contrats intelligents et des transferts on-chain. DEX désigne un modèle d’accès et de règlement, et non un mécanisme de tarification particulier. Certains DEX utilisent des teneurs de marché automatisés (`AMMs`) et des pools de liquidité ; d’autres recourent à des carnets d’ordres on-chain, à des enchères ou à des intentions signées exécutées par des parties concurrentes. Un agrégateur ou un routeur peut comparer les pools, les niveaux de frais et les tokens intermédiaires, puis fractionner ou combiner les routes afin d’améliorer la sortie attendue. L’auto-conservation réduit le risque lié à la garde par une bourse, mais transfère à l’utilisateur la responsabilité de la vérification et de l’exécution. Une interface web, un routeur, un solver, un oracle, un séquenceur, un processus de gouvernance ou un administrateur de mise à niveau peuvent toujours introduire des points de contrôle ou de défaillance. Le terme « décentralisé » ne prouve pas que chaque composant est sans permission, immuable, audité ou sûr. ## Fonctionnement 1. **Définir l’opération.** Fixez la blockchain, les adresses des contrats des tokens d’entrée et de sortie, le montant et le portefeuille. Un symbole ou un nom de token n’est pas unique. Vérifiez le domaine officiel de l’application ainsi que le contrat de routage ou de règlement avant de vous connecter ou de signer. 2. **Obtenir et examiner un devis.** L’interface interroge une ou plusieurs sources de liquidité. Vérifiez l’entrée exacte, la sortie estimée, la route, le niveau de frais, l’impact sur le prix, les frais de réseau, l’expiration du devis et si la route utilise un token intermédiaire, un solver, un bridge ou un contrat inconnu. 3. **Fixer des limites d’exécution.** Pour un swap à entrée exacte, la transaction doit imposer un montant minimal en sortie (`minOut`) ; pour un swap à sortie exacte, elle doit imposer un montant maximal en entrée. La tolérance au slippage définit cette limite d’exécution. Elle n’améliore pas le prix du devis. 4. **Autoriser et exécuter.** Un swap ERC-20 peut nécessiter une approbation ou un permit signé avant le swap. Privilégiez l’autorisation pratique la plus restreinte et confirmez l’adresse autorisée à dépenser, le montant, l’échéance, le nonce, la blockchain, les calldata et la valeur native. La signature du portefeuille autorise ce qui est encodé, et non ce que l’interface affirme en langage courant. 5. **Vérifier le règlement.** Une transaction soumise ou en attente n’est pas un swap achevé. Après confirmation, vérifiez son statut, les variations des soldes de tokens, le montant réellement reçu, le gas payé, les événements et l’autorisation restante. Révoquez une autorisation lorsque la commodité de la conserver ne justifie plus l’exposition. Dans un pool à produit constant sur toute la plage de prix, les réserves `x` et `y` suivent la relation élémentaire `x * y = k`. Avec des frais d’entrée `f`, une entrée exacte `deltaX` produit généralement : `deltaY = y * (1 - f) * deltaX / (x + (1 - f) * deltaX)` Le rapport des réserves fournit un prix marginal, mais une opération de taille finie se déplace le long de la courbe. Son prix d’exécution moyen est donc moins favorable que le prix marginal initial, et l’écart augmente à mesure que la taille de l’opération devient importante par rapport à la liquidité active. Les pools à liquidité concentrée appliquent une logique de courbe similaire dans des fourchettes de prix choisies ; lorsqu’une position sort de sa fourchette, elle devient inactive, se compose entièrement d’un seul actif et ne perçoit plus les frais de swap de la plage active. ## Exemple détaillé Supposons qu’un pool à produit constant détienne `100 ETH` et `200,000 USDC` ; son prix de réserve initial est donc de `2,000 USDC/ETH`. Un trader envoie `20,000 USDC` pour acheter de l’ETH, et le pool prélève des frais d’entrée de `0.30%`. L’entrée effective est de `19,940 USDC` : `ETH out = 100 * 19,940 / (200,000 + 19,940) = 9.066109 ETH` Le trader paie en moyenne environ `2,206.02 USDC/ETH` en montant brut, avant le gas. Avec une tolérance au slippage de `0.50%`, la sortie minimale correspondante serait d’environ `9.020778 ETH`. Cette tolérance permet un règlement jusqu’au minimum ; elle ne garantit pas les `9.066109 ETH` annoncés. Supposons maintenant qu’un routeur estime qu’une opération de `50,000 USDC` rapporte des actifs d’une valeur de `47,000 USD` via un seul pool direct, mais `48,200 USD` si `60%` empruntent le pool direct et `40%` suivent une route à deux sauts, d’abord `USDC/ETH`, puis `ETH/Token A`. La route fractionnée améliore la sortie annoncée de `1,200 USD`, mais ajoute également des appels de contrats, du gas, une exposition au token intermédiaire et davantage de points de défaillance possibles. Pour un ordre plus petit, ces coûts supplémentaires peuvent dépasser l’économie réalisée sur l’impact de prix. ## Risques et mesures de contrôle - **Actif erroné ou malveillant :** N’importe qui peut créer un token portant un nom ou un symbole connu. Vérifiez la blockchain et l’adresse du contrat à l’aide de sources officielles indépendantes ; testez un actif et une route inconnus avec un faible montant. - **Pertes liées aux approbations et aux signatures :** Une approbation illimitée, un permit malveillant, une interface compromise ou une signature trompeuse peuvent autoriser davantage que le swap prévu. Lisez l’adresse autorisée à dépenser et la portée, évitez de signer à l’aveugle et contrôlez les autorisations après utilisation. - **Pertes d’exécution :** Une liquidité faible, des devis obsolètes, des prix volatils, des tokens taxant les transferts et des transactions en attente publiques peuvent réduire la sortie ou provoquer un échec. Comparez la profondeur active et les routes, définissez délibérément `minOut` et l’échéance, et n’augmentez pas la tolérance simplement pour forcer l’exécution. - **MEV :** Des chercheurs ou des validateurs peuvent réordonner les transactions ou placer des opérations autour d’un swap visible. Cela peut dégrader l’exécution même si le résultat reste dans les limites de tolérance de l’utilisateur. Envisagez, selon le cas, des ordres plus petits, des pools plus profonds, un routage protégé ou une exécution de type ordre à cours limité. - **Gas et transactions échouées :** L’approbation, le swap, les sauts de la route et la révocation d’une autorisation peuvent chacun entraîner des frais de réseau. Une transaction qui échoue consomme normalement quand même du gas. Conservez suffisamment de monnaie native pour l’ensemble du processus et vérifiez la blockchain avant de signer. - **Défaillance du protocole et de l’infrastructure :** Les bogues de contrats, les mises à niveau non sûres, les clés d’administration, les hooks, les oracles, les bridges, les services RPC, les séquenceurs et les interfaces peuvent tomber en panne ou être compromis. Vérifiez les contrats déployés exacts, les audits, les pouvoirs de mise à niveau et de pause, l’historique des incidents et la chaîne de dépendances. - **Irréversibilité et conservation des données :** Un swap confirmé ne peut généralement pas être annulé par le service client. Conservez le devis, le hash de transaction, les adresses des tokens, les variations du solde du portefeuille et le coût de revient ; examinez tout résultat inattendu avant de signer une autre transaction. ## Idées reçues courantes ### Mythe 1 : Un token disponible sur un DEX a passé un contrôle d’admission De nombreux pools sont sans permission, et n’importe qui peut créer un token du même nom ou fournir la liquidité initiale d’un pool. La disponibilité ne vaut pas approbation ; vérifiez l’adresse du contrat et la liquidité réelle. ### Mythe 2 : L’auto-conservation rend une transaction réversible L’utilisateur contrôle la signature, mais une transaction valide et confirmée est normalement définitive. Un token, une blockchain, une approbation ou un destinataire erronés restent sous la responsabilité de l’utilisateur. ### Mythe 3 : Une tolérance au slippage plus élevée donne un meilleur prix Une tolérance plus élevée ne fait qu’élargir la plage des résultats acceptables et réduire le risque d’échec lié au slippage. Elle peut permettre une exécution moins favorable et une extraction de MEV plus importante. ### Mythe 4 : Le solde du pool correspond au montant négociable au prix actuel Le solde affiché est réparti sur une courbe ou des fourchettes de prix. Une opération importante consomme de la liquidité à des prix progressivement différents ; le volume exécutable doit donc être évalué d’après la profondeur active, les frais, la route et `minOut`. ## Sujets associés - [Bourse centralisée (CEX)](/fr/crypto/cex/) - [Finance décentralisée (DeFi)](/fr/crypto/defi/) - [Frais de gas](/fr/crypto/gas-fee/) - [Pool de liquidité](/fr/crypto/liquidity-pool/) ## Sources - [How Uniswap Works](https://developers.uniswap.org/docs/get-started/concepts/how-uniswap-works) - Uniswap Labs (consulté : 2026-08-20) - [Uniswap v2 Core](https://docs.uniswap.org/whitepaper.pdf) - Uniswap Labs (consulté : 2026-08-20) - [Uniswap v3 Core](https://app.uniswap.org/whitepaper-v3.pdf) - Uniswap Labs (consulté : 2026-08-20) - [AMM vs UniswapX Routing](https://developers.uniswap.org/docs/trading/swapping-api/amm-vs-uniswapx-routing) - Uniswap Labs (consulté : 2026-08-20) Source: https://wiki.fcontext.com/fr/crypto/dex/index.mdx