---
title: "Front-running on-chain"
description: "Le front-running on-chain exploite les informations d'une transaction en attente pour faire exécuter une autre transaction avant elle et en tirer profit. Cette fiche explique le rôle du pool public, de l'ordonnancement, du MEV, du slippage et de l'envoi privé."
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.
# Front-running on-chain
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Le front-running on-chain se produit lorsqu'une personne découvre une transaction en attente et fait exécuter une autre transaction avant elle afin d'en extraire de la valeur. Elle peut copier un appel rentable, acheter avant un ordre connu ou disputer une occasion rare sur la blockchain. Le front-running est une forme de valeur maximale extractible (MEV), mais ne désigne pas toutes les stratégies MEV.
Cette possibilité existe parce qu'une transaction Ethereum soumise est normalement diffusée et conservée dans des pools de transactions avant son inclusion dans un bloc par un validateur. Les searchers peuvent examiner les transactions en attente, simuler les résultats, puis envoyer leurs propres transactions ou bundles. L'ordre final dépend de la construction du bloc : une commission de priorité plus élevée peut favoriser l'inclusion sans garantir une position précise.
Pour l'utilisateur, il faut déterminer si la transaction révèle une intention précieuse avant son exécution, si ses limites laissent une marge d'extraction et qui peut agir sur l'ordre. Les swaps DEX à slippage large, les demandes publiques utilisant un secret réutilisable, les liquidations, les enchères et les émissions limitées peuvent attirer la concurrence.
## Fonctionnement
Dans une transaction sandwich, un searcher repère un achat DEX en attente, achète le même actif juste avant, puis le revend juste après. L'achat de l'utilisateur fait monter le prix du pool entre les deux opérations du searcher. La stratégie ne réussit que si le montant minimal reçu par l'utilisateur permet encore l'exécution malgré ce mouvement supplémentaire et si le gain couvre tous les frais.
Les front-runners généralisés visent les appels dont la valeur peut être copiée. Si une transaction révèle une réponse ou une autorisation qui n'est pas liée au destinataire prévu, un autre compte peut reproduire l'appel et tenter de passer en premier. Le contrat peut recourir à un mécanisme de commit-reveal et lier la demande à un destinataire précis ; demander simplement plus de frais ne protège pas une information exposée.
Les champs de frais Ethereum comme `maxPriorityFeePerGas` et `maxFeePerGas` déterminent ce que l'expéditeur accepte de payer. Ils ne rendent pas le contenu privé, et les builders peuvent évaluer des bundles plutôt que trier chaque transaction selon un seul champ. Le front-running est donc un problème d'information et d'ordonnancement, pas seulement une course au prix du Gas.
## Exemple
Supposons qu'un pool AMM contienne 100 ETH et 200,000 USDC. Un utilisateur envoie publiquement une transaction pour acheter des ETH avec 10,000 USDC et une tolérance de slippage de 5%. La transaction en attente révèle le sens, le montant et la sortie minimale acceptée.
Un searcher simule le swap et soumet un achat pour passer avant, puis une vente pour passer après. Si les deux encadrent la transaction de l'utilisateur, celui-ci reçoit moins d'ETH que sans sandwich tout en restant dans la limite de 5% ; le searcher conserve l'écart après déduction des frais.
Le résultat n'est pas garanti. La concurrence, les frais du pool, les variations de prix, l'absence d'inclusion ou le contrôle de sortie minimale peuvent rendre la stratégie déficitaire ou faire échouer la séquence. Une grosse transaction normale provoque aussi un impact de prix : il faut examiner les traces et l'état du pool avant d'attribuer tout slippage à une attaque.
## Risques et mesures d'atténuation
Aucun réglage n'élimine tout risque d'ordonnancement. L'objectif utile consiste à réduire les fuites d'information inutiles et à plafonner la perte que la transaction peut accepter.
- Définir une sortie minimale ou une limite de prix justifiable selon la profondeur du pool et le marché ; ne pas élargir le slippage dans le seul but de forcer l'exécution.
- Vérifier avant signature l'impact de prix, la liquidité, les règles de transfert du jeton et l'itinéraire, surtout pour une grosse opération dans un pool peu profond.
- Utiliser, lorsque c'est pertinent, un service réputé d'envoi privé ou de protection MEV, après examen de sa couverture des builders, de son comportement en cas d'échec, de sa politique de confidentialité et de ses hypothèses de confiance.
- Lors de la conception d'un protocole, ne pas placer de secret attribué au premier arrivé dans les données ; employer une liaison au destinataire, un commit-reveal, des enchères par lots ou un mécanisme adapté.
L'envoi privé peut masquer une transaction au pool public, sans constituer une garantie universelle. L'utilisateur doit faire confiance au service et aux builders pour ne pas la divulguer ni l'exploiter ; changer de route RPC avant la confirmation peut la rendre publique. Elle peut aussi être retardée ou ne jamais être incluse.
## Idées reçues
### Idée reçue 1 : Payer plus de Gas empêche le front-running
Une commission de priorité supérieure peut améliorer les chances d'inclusion, mais ne cache pas l'opération. Searchers et builders peuvent soumettre un ordre ou un bundle plus rentable : les enchères de frais ne suffisent pas à protéger l'utilisateur.
### Idée reçue 2 : Toute exécution défavorable est une attaque sandwich
Les gros ordres déplacent eux-mêmes les prix AMM, et le marché peut évoluer pendant l'attente. Les frais de routage, les taxes de transfert et la concurrence normale peuvent également détériorer l'exécution.
### Idée reçue 3 : Un slippage nul est toujours le choix le plus sûr
Une limite trop stricte peut refuser un mouvement de prix ordinaire et consommer quand même du Gas si la transaction publique est annulée. La limite adaptée dépend de la liquidité, de la taille, de l'urgence et de la perte maximale acceptable.
## Sujets connexes
- [DEX](/fr/crypto/dex/)
- [Frais de Gas](/fr/crypto/gas-fee/)
- [MEV](/fr/crypto/mev/)
- [Attaques Sybil](/fr/crypto/sybil-attack/)
- [Yield farming](/fr/crypto/yield-farming/)
## Sources
- [Transactions](https://ethereum.org/developers/docs/transactions/) - ethereum.org (consulté le : 2026-08-20)
- [Maximal extractable value (MEV)](https://ethereum.org/developers/docs/mev/) - ethereum.org (consulté le : 2026-08-20)
- [Flashbots Protect Quick Start](https://docs.flashbots.net/flashbots-protect/quick-start) - Flashbots (consulté le : 2026-08-20)
Source: https://wiki.fcontext.com/fr/crypto/front-running/index.mdx