--- title: "Attaque sandwich" description: "Comment un searcher place des transactions autour d'un swap en attente, dégrade l'exécution de l'utilisateur et extrait de la valeur de l'ordre des transactions." 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. # Attaque sandwich > À des fins éducatives uniquement ; ceci ne constitue pas un conseil de sécurité ou d'investissement. Les limites de slippage et le routage privé peuvent réduire l'exposition aux attaques sandwich, sans garantir la qualité d'exécution, l'inclusion, la finalité ni le recouvrement des pertes. ## Réponse directe Une attaque sandwich est une forme nuisible de valeur maximale extractible dans laquelle un attaquant place une transaction juste avant le swap d'un utilisateur et une autre juste après. La première opération déplace le prix du pool au détriment de l'utilisateur, son swap s'exécute à un taux moins favorable, puis la dernière opération clôt la position de l'attaquant au prix en partie créé par l'ordre de l'utilisateur. L'attaque suppose une visibilité anticipée ou un pouvoir privilégié sur l'ordre de l'intention de l'utilisateur, un impact de prix suffisant et des limites d'exécution qui permettent encore au swap de réussir. Elle concerne surtout les swaps de teneurs de marché automatisés, mais le risque général couvre tout changement d'état prévisible dont l'ordonnancement permet à un tiers d'extraire de la valeur. ## Fonctionnement Un utilisateur signe et diffuse un swap. Si ses détails atteignent un pool public de transactions ou un autre canal observable avant l'inclusion, un searcher peut décoder les actifs, la taille, la route, la sortie minimale et l'échéance, puis simuler différents ordres de transactions. Pour un achat dans un pool AMM, le searcher achète d'abord. Ce front-run modifie les réserves et augmente le prix d'exécution de l'utilisateur. Celui-ci reçoit ensuite moins de jetons de sortie que dans le devis initial, tant que le résultat respecte sa condition de sortie minimale. Le searcher revend après l'utilisateur dans un back-run et capte une partie du mouvement de prix. Les recettes brutes ne sont pas le bénéfice. L'attaquant doit couvrir les frais des deux swaps, le Gas ou les paiements au builder, les tentatives échouées et le risque d'inventaire. La concurrence, d'autres opérations, la réversion du swap visé ou un changement d'ordre du bloc peuvent rendre la séquence déficitaire ; un sandwich n'est ni automatiquement atomique ni garanti. La protection contre le slippage limite la pire sortie acceptée sans empêcher l'ordonnancement. Une tolérance très large laisse davantage de place à une exécution défavorable, tandis qu'une tolérance très stricte peut faire réverter un swap légitime en période volatile. Les applications et contrats intégrateurs doivent imposer une sortie minimale actuelle approuvée par l'utilisateur et une échéance adaptée, plutôt que zéro ou une valeur fixe périmée. La soumission privée, le flux d'ordres protégé, les enchères par lots, l'exécution fondée sur des intentions et le fractionnement des ordres peuvent réduire l'exposition dans certains systèmes. Leur efficacité dépend des intermédiaires qui voient l'ordre, de la couverture des builders, du comportement de repli, de la liquidité, des frais et de l'implémentation ; les mentions « privé » ou « protégé contre le MEV » ne sont pas des garanties universelles. ## Exemple Un utilisateur envoie un swap visible pour acheter le Jeton B avec le Jeton A dans un pool AMM. Un searcher simule que l'ordre est assez grand pour déplacer le prix du pool et que la sortie minimale laisse encore le swap s'exécuter après un mouvement défavorable. Le searcher achète d'abord le Jeton B, le swap de l'utilisateur achète ensuite à un taux dégradé, puis le searcher revend immédiatement le Jeton B. L'utilisateur reçoit au moins le minimum signé, mais moins que dans le devis précédent ; le searcher ne conserve que le solde après frais de swap, paiements d'ordonnancement et coûts d'exécution. ## Risques Le préjudice direct pour l'utilisateur est une exécution moins favorable et un slippage effectif accru. Le swap peut aussi réverter après avoir consommé du Gas lorsque la chaîne et la conception facturent les exécutions échouées. Une liquidité faible, les gros ordres visibles, des limites souples, les marchés volatils et les routes prévisibles peuvent augmenter l'exposition, mais aucun seuil unique ne prouve qu'une attaque aura lieu. Les mesures d'atténuation comportent des compromis. De petits ordres peuvent augmenter les frais totaux ou révéler une stratégie répétée ; des limites strictes peuvent multiplier les réversions ; les routes privées soulèvent des questions de confiance, censure, journalisation et repli ; les interfaces protégées peuvent ne couvrir que certaines chaînes ou routes. Vérifiez la sortie minimale signée, l'échéance, la route, la politique de l'endpoint, le reçu et la finalité requise, au lieu de vous fier à un badge de protection. ## Idées reçues - **Tout mouvement de prix défavorable est une attaque sandwich.** L'impact normal, le marché, un changement de route ou l'arbitrage peuvent aussi écarter l'exécution du devis ; l'attribution exige des preuves sur l'ordre des transactions. - **L'attaquant vole simplement les jetons du portefeuille.** Un sandwich typique modifie l'état du pool autour d'un swap autorisé ; la transaction de l'attaquant n'a pas besoin de transférer directement les actifs du portefeuille de l'utilisateur. - **Toute tolérance de slippage empêche l'attaque.** La sortie minimale borne la dégradation acceptée, mais un searcher peut optimiser le sandwich pour que le swap réussisse près de cette limite. - **La soumission privée supprime le MEV.** Elle peut cacher l'ordre au pool public, mais opérateurs RPC, relais, builders, solveurs ou repli public peuvent encore l'observer ou l'influencer. - **Un reçu réussi prouve une exécution équitable.** Le succès prouve seulement que les conditions du contrat sont satisfaites, pas que l'utilisateur a obtenu le meilleur prix ou évité un ordre nuisible. ## Sujets associés - [Teneurs de marché automatisés](/fr/crypto/amm/) - [Front-running](/fr/crypto/front-running/) - [Valeur maximale extractible](/fr/crypto/mev/) - [RPC de transaction privée](/fr/crypto/private-transaction-rpc/) - [Plateformes d'échange décentralisées](/fr/crypto/dex/) ## Sources - [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/) - Ethereum.org (accessed: 2026-08-21) - [What is a sandwich attack?](https://support.uniswap.org/hc/en-us/articles/19387081481741-What-is-a-sandwich-attack) - Uniswap Labs (accessed: 2026-08-21) - [SCWE-090: Missing Slippage Protection in Automated Token Swaps](https://scs.owasp.org/SCWE/SCSVS-CODE/SCWE-090/) - OWASP Smart Contract Security (accessed: 2026-08-21) Source: https://wiki.fcontext.com/fr/crypto/sandwich-attack/index.mdx