Si vous pensez encore qu'un trade sur un exchange se résume à cliquer sur le bouton « Buy » et à laisser la magie opérer, j'ai une mauvaise nouvelle pour vous. À l'échelle de la microseconde et de la milliseconde, le marché est un véritable champ de bataille où la liquidité bascule d'un état à un autre en continu. Là-bas, c'est votre vitesse d'exécution et l'anatomie du pool qui décident si vous encaissez des profits ou si vous casquez pour le glissement de prix (slippage) et le flux toxique.
Dans le trading centralisé (TradFi et CEX), l'Order Book est roi. Côté DeFi, l'AMM s'est imposé comme le standard absolu. Mais dès qu'on descend au niveau du trading haute fréquence (HFT), la différence entre les deux dépasse la simple couche technique : elle bouleverse fondamentalement la mécanique de formation des prix, d'arbitrage et d'exécution des ordres.
Ouvrons le capot pour disséquer la mécanique de liquidité de ces deux systèmes, repérer où se nient les coûts cachés et voir comment exploiter tout ça concrètement sur le terrain.
1. Anatomie du carnet L2/L3 : À quoi ressemble vraiment la liquidité
La plupart des traders retail ne voient que le carnet L2 : des volumes agrégés à chaque niveau de prix. Mais les algos HFT et les institutionnels tournent en L3 (Order-by-Order) — un flux de données brut où chaque événement possède son propre identifiant unique (order_id), son horodatage à la nanoseconde près et sa position exacte dans la file d'attente.

Le principe de Price-Time Priority (FIFO)
Dans un matching engine classique, l'exécution des ordres suit une priorité stricte :
- Le prix (le meilleur prix passe toujours en premier).
- Le temps (à prix égal, le premier arrivé dans le carnet est le premier servi).
Cette file d'attente temporelle génère deux effets majeurs sur la microstructure du marché :
Adverse Selection (Sélection adverse) : Si votre ordre limite d'achat se fait dépiler instantanément, il y a de fortes chances qu'un gros vendeur venait d'envoyer un flux agressif (toxic flow). Résultat : le cours a toutes les chances de continuer à se casser la gueule.
Queue Position Value : La place tout en haut de la file d'attente sur un niveau de prix a une valeur intrinsèque. Les bots HFT annulent et repassent leurs ordres en boucle (via des mécaniques de Spoofing/Layering ou de la gestion adaptive de liquidité) pour squatter cette priorité sans se manger un risque d'inventaire disproportionné.
2. AMM : Du Constant Product classique à la liquidité concentrée
Le fonctionnement d'un AMM n'a rien à voir avec un carnet d'ordres : ici, pas de file d'attente. Le prix est déterminé par une fonction mathématique invariante.
Constant Product (v2) : x · y = k
Sur un modèle Uniswap v2 classique, la liquidité est étalée de zéro jusqu'à l'infini.
Quand vous envoyez un trade d'un volume Δx, vous retirez du pool une quantité Δy, calculée en intégrant les frais γ = (1 - fee) :
Δy = (y · Δx · γ) / (x + Δx · γ)
Le prix d'exécution n'est pas fixe : il « glisse » le long de la courbe au moment même où la transaction est traitée.
Concentrated Liquidity (v3 / Tick-based)
Uniswap v3 a rapproché l'AMM d'un carnet d'ordres en permettant aux apporteurs de liquidité (LP) de définir des plages de prix spécifiques [Pa, Pb].
Le cours est découpé en ticks, où chaque tick correspond à une variation de prix de 0,01 % (1 bps) :
P(i) = 1.0001i
La liquidité L au sein d'une plage fonctionne comme un invariant « virtuel ». En revanche, dès qu'un franchissement de tick a lieu, la liquidité active change brutalement. Pour un arbitrageur HFT, cela implique une chose : le carnet d'un AMM v3 est discret, et sa profondeur évolue par paliers au rythme des cassures de ticks.
3. Analyse comparative : Microstructure Matrix
| Paramètre | Order Book (CEX/TradFi) | AMM (Uniswap v2) | Concentrated AMM (v3) |
|---|---|---|---|
| Priorité d'exécution | Price-Time (FIFO) / Pro-Rata | Prix du gaz / MEV (Priority Fee) | Prix du gaz / MEV (Priority Fee) |
| Latence | Microsecondes / Nanosecondes | Temps de bloc (ou slotted latency) | Temps de bloc / Mempool P2P |
| Formation du prix | Enchère continue (Continuous Double Auction) | Dynamique selon le volume (x · y = k) | Dynamique au sein du tick actif |
| Coûts de liquidité | Pas d'Impermanent Loss (mais risque d'inventaire) | Impermanent Loss (IL) | Loss-Versus-Rebalancing (LVR) |
| Transparence du flux | Flux de données L3 (Pitch, ITCH, FIX) | Mempool (avant le bloc) / On-chain (après) | Mempool (avant le bloc) / On-chain (après) |
4. Les mécaniques cachées : MEV, LVR et Toxic Flow
Sur un carnet d'ordres CEX, un acteur HFT se bat pour gratter des nanosecondes de latence réseau physique (colocation dans le data center de l'exchange, fibre optique, cartes FPGA).
Côté DeFi, la notion de temps est complètement tordue : c'est la structuration du bloc qui prend le dessus.
MEV (Maximal Extractable Value)
Sur les AMM, l'ordonnancement des transactions dans un bloc est orchestré par des Searchers et des Block Builders. Cela donne naissance à des stratégies HFT bien spécifiques :
- Front-running / Back-running : Interception de transactions dans le mempool en envoyant un pourboire de priorité plus élevé (Priority Fee).
- Sandwich Attacks : Achat juste avant une grosse transaction d'un utilisateur pour faire monter artificiellement le cours, puis revente immédiate dans la foulée.
LVR (Loss-Versus-Rebalancing)
Tout le monde a l'habitude de calculer les risques d'un LP via l'Impermanent Loss (IL). Sauf qu'à haute fréquence, c'est le LVR qu'il faut regarder — une métrique théorisée par des chercheurs de Columbia et de chez Paradigm.
Le LVR (Loss-Versus-Rebalancing) représente la perte systématique subie par un LP sur AMM par rapport à un portefeuille identique rééquilibré en continu sur un CEX en s'appuyant sur les prix externes.
La cause du LVR ? L'arbitrage de volatilité. Quand le prix s'envole sur CEX, le pool AMM accuse un temps de retard (stale price). L'arbitrageur HFT repère ce spread, vient siphonner la liquidité bon marché de l'AMM et se couvre instantanément sur le CEX. L'apporteur de liquidité AMM se fait donc systématiquement exécuter au pire prix face à un flux informé (toxic flow).
LVR ≈ (σ² / 8) · ∫0T St · Lt dt
Où σ représente la volatilité de l'actif, St le prix et Lt la liquidité active. Le constat est simple : Plus le marché est volatil, plus les LP rince les arbitrageurs HFT.
5. En pratique : Script Python de cotation AMM v3 vs Profondeur L2
Passons au code. Développons un outil fonctionnel pour calculer le prix d'exécution réel (incluant le slippage) d'un ordre donné, en comparant la profondeur d'un carnet L2 et un pool AMM Constant Product.
Le script est écrit en pure Python, sans dépendre de gros frameworks externes.
from __future__ import annotations
from dataclasses import dataclass
from enum import Enum
from typing import List
class FeeMode(Enum):
QUOTE = "quote" # La commission est déduite de l'USDT entrant
BASE = "base" # La commission est déduite de l'ETH reçu
@dataclass
class AskLevel:
price: float
volume: float
class OrderBookL2:
"""
Carnet d'ordres L2 (Côté Vente / Ask).
Exemple pour la paire ETH/USDT :
price = USDT pour 1 ETH
volume = Quantité d'ETH
"""
def __init__(
self,
asks: List[tuple[float, float]],
taker_fee: float = 0.001,
) -> None:
if not (0 <= taker_fee < 1):
raise ValueError("taker_fee doit être compris dans l'intervalle [0, 1)")
self.taker_fee = float(taker_fee)
self.asks: List[AskLevel] = []
for price, volume in asks:
if price <= 0:
raise ValueError("Le prix doit être > 0")
if volume <= 0:
raise ValueError("Le volume doit être > 0")
self.asks.append(
AskLevel(
price=float(price),
volume=float(volume),
)
)
self.asks.sort(key=lambda x: x.price)
def best_ask(self) -> float:
if not self.asks:
raise ValueError("Le carnet d'ordres est vide")
return self.asks[0].price
def spot_price(self) -> float:
return self.best_ask()
def total_liquidity_quote(self) -> float:
return sum(
level.price * level.volume
for level in self.asks
)
def total_liquidity_base(self) -> float:
return sum(
level.volume
for level in self.asks
)
def simulate_buy(
self,
amount_in_quote: float,
mutate: bool = True,
fee_mode: FeeMode = FeeMode.QUOTE,
) -> tuple[float, float]:
"""
Achat d'actif de base en utilisant amount_in_quote.
Retourne :
(
actif_de_base_reçu,
prix_moyen_effectif
)
"""
if amount_in_quote <= 0:
raise ValueError(
"amount_in_quote doit être > 0"
)
if fee_mode == FeeMode.QUOTE:
quote_for_trade = (
amount_in_quote *
(1.0 - self.taker_fee)
)
else:
quote_for_trade = amount_in_quote
remaining_quote = quote_for_trade
total_base_bought = 0.0
new_levels: List[AskLevel] = []
for level in self.asks:
if remaining_quote <= 0:
new_levels.append(level)
continue
level_cost = (
level.price *
level.volume
)
if remaining_quote >= level_cost:
total_base_bought += level.volume
remaining_quote -= level_cost
else:
base_from_level = (
remaining_quote /
level.price
)
total_base_bought += base_from_level
remaining_volume = (
level.volume -
base_from_level
)
if remaining_volume > 1e-12:
new_levels.append(
AskLevel(
level.price,
remaining_volume,
)
)
remaining_quote = 0.0
if remaining_quote > 1e-9:
raise ValueError(
"Liquidité insuffisante dans le carnet d'ordres"
)
if fee_mode == FeeMode.BASE:
total_base_bought *= (
1.0 - self.taker_fee
)
if total_base_bought <= 0:
raise ValueError(
"Le volume obtenu est égal à zéro"
)
avg_price = (
amount_in_quote /
total_base_bought
)
if mutate:
self.asks = new_levels
return total_base_bought, avg_price
class ConstantProductAMM:
"""
AMM de style Uniswap V2
x = ETH
y = USDT
spot = y / x
"""
def __init__(
self,
reserve_x: float,
reserve_y: float,
fee: float = 0.003,
) -> None:
if reserve_x <= 0:
raise ValueError(
"reserve_x doit être > 0"
)
if reserve_y <= 0:
raise ValueError(
"reserve_y doit être > 0"
)
if not (0 <= fee < 1):
raise ValueError(
"fee doit être compris dans l'intervalle [0, 1)"
)
self.x = float(reserve_x)
self.y = float(reserve_y)
self.fee = float(fee)
def spot_price(self) -> float:
return self.y / self.x
def invariant(self) -> float:
return self.x * self.y
def simulate_buy(
self,
amount_y_in: float,
mutate: bool = True,
) -> tuple[float, float]:
"""
Achat d'ETH contre de l'USDT.
Retourne :
(
ETH_reçu,
prix_moyen
)
"""
if amount_y_in <= 0:
raise ValueError(
"amount_y_in doit être > 0"
)
y_effective = (
amount_y_in *
(1.0 - self.fee)
)
x_out = (
self.x *
y_effective
) / (
self.y +
y_effective
)
if x_out <= 0:
raise ValueError(
"Le volume obtenu est égal à zéro"
)
if x_out >= self.x:
raise ValueError(
"Liquidité insuffisante dans le pool"
)
avg_price = (
amount_y_in /
x_out
)
if mutate:
self.x -= x_out
self.y += amount_y_in
return x_out, avg_price
def print_trade_result(
title: str,
received: float,
avg_price: float,
spot_price: float,
) -> None:
slippage = (
(avg_price - spot_price)
/ spot_price
) * 100
print(
f"{title:<12}"
f" Reçu : {received:.6f}"
f" | Prix moyen : {avg_price:,.4f}"
f" | Glissement (slippage) : {slippage:.4f}%"
)
def main() -> None:
asks = [
(3000.0, 1.5),
(3001.0, 2.0),
(3002.5, 5.0),
(3005.0, 10.0),
(3010.0, 25.0),
]
orderbook = OrderBookL2(
asks=asks,
taker_fee=0.001,
)
amm = ConstantProductAMM(
reserve_x=1000.0,
reserve_y=3_000_000.0,
fee=0.003,
)
trade_size = 15_000.0
ob_spot = orderbook.spot_price()
amm_spot = amm.spot_price()
ob_received, ob_avg = orderbook.simulate_buy(
amount_in_quote=trade_size,
mutate=True,
fee_mode=FeeMode.QUOTE,
)
amm_received, amm_avg = amm.simulate_buy(
amount_y_in=trade_size,
mutate=True,
)
print(
f"\n=== Comparaison d'exécution d'ordre "
f"de {trade_size:,.2f} USDT ===\n"
)
print_trade_result(
"ORDERBOOK",
ob_received,
ob_avg,
ob_spot,
)
print_trade_result(
"AMM V2",
amm_received,
amm_avg,
amm_spot,
)
print("\n=== État après la transaction ===\n")
if orderbook.asks:
print(
f"Meilleur Ask : "
f"{orderbook.best_ask():,.4f}"
)
else:
print("Le carnet d'ordres est entièrement vidé")
print(
f"Prix Spot AMM : "
f"{amm.spot_price():,.4f}"
)
print(
f"Réserves AMM : "
f"{amm.x:.6f} ETH | "
f"{amm.y:.2f} USDT"
)
if __name__ == "__main__":
main()Comment interpréter ces résultats
Sur des pools AMM profonds, les petits ordres passent sans slippage perceptible. En revanche, dès qu'on monte en volume, le prix grimpe le long d'une courbe convexe. Côté carnet d'ordres, tout dépend de la présence de « murs de liquidité » (liquidity walls). Si le carnet est peu profond, vous allez défoncer plusieurs niveaux de prix et essuyer un décalage bien pire que sur un AMM.
6. Modèles hybrides : Comment les DEX intègrent l'Order Book et pourquoi les CEX lorgnent sur les AMM
La frontière entre carnet d'ordres et AMM s'estompe à vue d'œil. Les traders HFT et les institutionnels ont très vite atteint les limites de ce que proposait un Uniswap v2 classique : une efficacité du capital dans le rouge et l'impossibilité de placer des ordres limit avancés (Stop-loss, Take-profit, Iceberg) rendaient les DEX carrément invivables pour du market making actif.
Résultat ? Un vrai virage évolutif avec l'émergence d'architectures hybrides.
1. Carnets d'ordres On-Chain et L2 (dYdX, Hyperliquid, Vertex)
L'arrivée de L1/L2 ultra-performants (Aptos, Sui, Arbitrum) et d'AppChains dédiées a enfin rendu possible le déploiement de véritables carnets d'ordres directement sur la blockchain.
Off-chain matching + On-chain settlement : Les moteurs d’appariement tournent hors-chaîne à toute allure (pour aller chercher un temps de réponse < 10 ms), tandis que l'exécution finale et la gestion du prêt/marge sont verrouillées par des smart contracts.
Fully On-chain (Hyperliquid, Serum/Ellipsis) : Ici, le carnet d'ordres vit à 100 % au cœur du consensus de la blockchain. Le défi ultime ? Encaisser un volume de requêtes dantesque : en HFT, la modification et l'annulation d'ordres (Cancel/Replace) représentent jusqu'à 95 à 98 % des transactions entrantes.
2. Architecture basée sur les Intentions (Intent-Based) et RFQ (Request for Quote)
Le modèle par « Intents » (Uniswap X, 1inch Fusion, CoW Protocol) remet au goût du jour la logique d'exécution propre aux institutionnels.
Le trader ne signe plus une transaction qui interagit brutalement avec une pool spécifique, mais exprime une intention (ex. : « Je veux échanger 100 ETH contre au moins 300 000 USDC »). Derrière, tout un réseau d'acteurs tiers (Fillers / Solvers) entre en compétition pour exécuter cet ordre en piochant dans n'importe quelle source de liquidité : CEX, inventaire privé de market makers ou DEX.

Pour le trader au quotidien, c'est le privilège de dire adieu au slippage et aux sandwich attacks du MEV : le Solver prend l'intégralité du risque d'exécution et de décalage de prix sur ses épaules, en se rémunérant sur de l'arbitrage cross-asset.
7. En pratique : Script d'arbitrage avancé entre carnet d'ordres CEX L2 et AMM v2
Sur le terrain, les bots HFT traquent sans relâche les écarts de prix entre CEX et AMM. Dès qu'un achat massif fait grimper le cours d'un actif sur un CEX, la pool AMM se retrouve temporairement « à la traîne » (stale). L'arbitrageur vient alors acheter sur l'AMM pour réaligner son cours avec celui du CEX, tout en revendant la quantité obtenue dans la foulée sur le CEX.
Voici un script Python prêt pour la prod qui calcule en temps réel la taille optimale de l'ordre d'arbitrage (dx) en intégrant les frais de l'AMM, la profondeur du carnet d'ordres du CEX et la structure de fees maker/taker.
from __future__ import annotations
from dataclasses import dataclass
from typing import List, Dict, Any
@dataclass
class BidLevel:
price: float
volume: float
class OrderBookSide:
"""
Côté Bid du carnet d'ordres.
price = prix d'achat
volume = volume de l'actif de base
"""
def __init__(self, bids: List[tuple[float, float]]):
self.bids: List[BidLevel] = []
for price, volume in bids:
if price <= 0:
raise ValueError("Le prix doit être > 0")
if volume <= 0:
raise ValueError("Le volume doit être > 0")
self.bids.append(
BidLevel(
float(price),
float(volume)
)
)
self.bids.sort(
key=lambda x: x.price,
reverse=True
)
def is_empty(self) -> bool:
return len(self.bids) == 0
def best_bid(self) -> float:
if self.is_empty():
raise ValueError("Le carnet d'ordres est vide")
return self.bids[0].price
def cumulative_levels(self) -> List[tuple[float, float]]:
"""
Renvoie les points de rupture de liquidité.
[
(2 ETH, VWAP jusqu'à 2 ETH),
(7 ETH, VWAP jusqu'à 7 ETH),
...
]
"""
result = []
cumulative_x = 0.0
cumulative_y = 0.0
for level in self.bids:
cumulative_x += level.volume
cumulative_y += level.volume * level.price
result.append(
(
cumulative_x,
cumulative_y
)
)
return result
def execute_sell(
self,
amount_x: float
) -> tuple[float, float]:
"""
Vente de amount_x dans le carnet d'ordres.
Renvoie :
(
USDT_reçus,
VWAP
)
"""
if amount_x <= 0:
raise ValueError(
"amount_x doit être > 0"
)
remaining_x = amount_x
received_y = 0.0
for level in self.bids:
if remaining_x <= 0:
break
executed = min(
remaining_x,
level.volume
)
received_y += (
executed *
level.price
)
remaining_x -= executed
if remaining_x > 1e-9:
raise ValueError(
"Liquidité insuffisante dans le carnet d'ordres"
)
vwap = received_y / amount_x
return received_y, vwap
class AMMPool:
"""
AMM Constant Product
x = ETH
y = USDT
"""
def __init__(
self,
reserve_x: float,
reserve_y: float,
fee: float = 0.003
):
if reserve_x <= 0:
raise ValueError(
"reserve_x doit être > 0"
)
if reserve_y <= 0:
raise ValueError(
"reserve_y doit être > 0"
)
if not (0 <= fee < 1):
raise ValueError(
"fee doit être dans l'intervalle [0,1)"
)
self.x = float(reserve_x)
self.y = float(reserve_y)
self.fee = float(fee)
def spot_price(self) -> float:
return self.y / self.x
def calculate_out_x(
self,
amount_y_in: float
) -> float:
if amount_y_in <= 0:
raise ValueError(
"amount_y_in doit être > 0"
)
y_effective = (
amount_y_in *
(1.0 - self.fee)
)
x_out = (
self.x *
y_effective
) / (
self.y +
y_effective
)
return x_out
def calculate_required_y_for_x(
self,
target_x_out: float
) -> float:
"""
Inversion de la formule AMM.
Détermine le montant d'USDT à déposer
pour obtenir target_x_out.
"""
if target_x_out <= 0:
raise ValueError(
"target_x_out doit être > 0"
)
if target_x_out >= self.x:
raise ValueError(
"Impossible de vider l'intégralité de la réserve"
)
y_effective = (
target_x_out *
self.y
) / (
self.x -
target_x_out
)
amount_y_in = (
y_effective /
(1.0 - self.fee)
)
return amount_y_in
def find_optimal_arbitrage(
amm: AMMPool,
cex_bids: OrderBookSide,
cex_fee: float = 0.001
) -> Dict[str, Any]:
if not (0 <= cex_fee < 1):
raise ValueError(
"cex_fee doit être dans l'intervalle [0,1)"
)
if cex_bids.is_empty():
return {
"opportunity": False,
"reason": "Carnet d'ordres CEX vide"
}
best_bid = cex_bids.best_bid()
if (
best_bid *
(1.0 - cex_fee)
<=
amm.spot_price()
):
return {
"opportunity": False,
"reason": "Absence de spread"
}
best_result = None
best_profit = float("-inf")
cumulative = cex_bids.cumulative_levels()
for cumulative_x, cumulative_y in cumulative:
try:
required_usdt = (
amm.calculate_required_y_for_x(
cumulative_x
)
)
gross_usdt = cumulative_y
net_usdt = (
gross_usdt *
(1.0 - cex_fee)
)
profit = (
net_usdt -
required_usdt
)
if profit > best_profit:
avg_buy_price = (
required_usdt /
cumulative_x
)
avg_sell_price = (
gross_usdt /
cumulative_x
)
amm_spot = (
amm.spot_price()
)
impact_pct = (
(
avg_buy_price -
amm_spot
)
/
amm_spot
) * 100
roi_pct = (
profit /
required_usdt
) * 100
best_profit = profit
best_result = {
"opportunity": True,
"input_usdt_amm": required_usdt,
"bought_x": cumulative_x,
"gross_usdt_cex": gross_usdt,
"net_usdt_cex": net_usdt,
"net_profit_usdt": profit,
"roi_pct": roi_pct,
"amm_spot_price": amm_spot,
"amm_avg_buy_price": avg_buy_price,
"amm_price_impact_pct": impact_pct,
"cex_vwap": avg_sell_price,
}
except ValueError:
continue
if best_result is None:
return {
"opportunity": False,
"reason": "Liquidité insuffisante"
}
if best_result["net_profit_usdt"] <= 0:
return {
"opportunity": False,
"reason": "Le slippage détruit le profit"
}
return best_result
def main():
amm = AMMPool(
reserve_x=1000.0,
reserve_y=3_000_000.0,
fee=0.003
)
cex = OrderBookSide([
(3050.0, 2.0),
(3048.0, 5.0),
(3045.0, 10.0),
(3040.0, 20.0),
(3030.0, 50.0),
])
result = find_optimal_arbitrage(
amm,
cex,
cex_fee=0.0005
)
print(
"\n=== Résultat de la recherche d'arbitrage ===\n"
)
if not result["opportunity"]:
print(
f"Statut : ANNULÉ\n"
f"Raison : {result['reason']}"
)
return
print("Statut : OPPORTUNITÉ DÉTECTÉE")
print()
print(
f"Capital engagé AMM : "
f"${result['input_usdt_amm']:,.2f}"
)
print(
f"ETH achetés : "
f"{result['bought_x']:.6f}"
)
print(
f"Revenu brut CEX : "
f"${result['gross_usdt_cex']:,.2f}"
)
print(
f"Revenu net CEX : "
f"${result['net_usdt_cex']:,.2f}"
)
print(
f"Profit net : "
f"${result['net_profit_usdt']:,.2f}"
)
print(
f"ROI : "
f"{result['roi_pct']:.4f}%"
)
print(
f"Prix Spot AMM : "
f"{result['amm_spot_price']:.4f}"
)
print(
f"Prix d'achat moyen AMM : "
f"{result['amm_avg_buy_price']:.4f}"
)
print(
f"Impact Prix AMM : "
f"{result['amm_price_impact_pct']:.4f}%"
)
print(
f"VWAP CEX : "
f"{result['cex_vwap']:.4f}"
)
if __name__ == "__main__":
main()8. Enseignements pratiques pour le trader : Comment éviter la « taxe d'ignorance »
Maîtriser la microstructure de marché n'a rien d'un exercice académique stérile. C'est l'outil indispensable pour éviter que votre capital ne s'évapore en fuites invisibles.
- Adaptez le type d'ordre à la dynamique du marché : Sur un CEX, balayer le marché avec un Market Order volumineux va dépiler le carnet d'ordres niveau par niveau, garantissant un slippage dévastateur. Si l'urgence prime, privilégiez des ordres IOC (Immediate-or-Cancel) ou FOK (Fill-or-Kill) en fixant une limite de prix acceptable.
- Analysez la profondeur réelle, pas le simple spread : Un spread minuscule sur un L2 (0,01 $) est parfois un pur trompe-l'œil. Si le meilleur Bid/Ask ne propose que 100 $ de liquidité, poser un ordre de 50 000 $ va traverser le carnet jusqu'à des niveaux de prix catastrophiques.
- Anticipez le toxic flow dans les AMM : Si vous fournissez de la liquidité sur Uniswap v3 sur une plage très étroite en pleine annonce macroéconomique ou forte volatilité, vous devenez la cible parfaite des bots d'arbitrage HFT. La métrique LVR (Loss-Versus-Rebalancing) aura balayé le rendement de vos frais en un clin d'œil.
- Protégez-vous du MEV sur les DEX : Pour vos transactions sur AMM, serrez systématiquement votre paramètre de Slippage Tolerance (pas plus de 0,1 à 0,3 %) ou passez par des relais RPC privés (type Flashbots Protect / MEV-Blocker) afin d'isoler vos transactions du mempool public et d'esquiver les sandwich attacks.
Partagez dans les commentaires le niveau de slippage auquel vous faites le plus souvent face lors de l'exécution de gros volumes, et quelle architecture (Order Book CEX ou AMM DEX) conserve votre préférence au quotidien !