AMM et liquidité¶
Le problème que résout un pool¶
Sur une bourse traditionnelle, échanger suppose une contrepartie : pour que vous achetiez, quelqu'un doit vendre au même moment, au même prix. Le carnet d'ordres est la liste de toutes les offres d'achat et de vente en attente. Quand personne n'attend en face, la transaction n'a pas lieu.
Ce modèle fonctionne mal on-chain. Chaque ajout, modification ou annulation d'ordre serait une transaction payante, et un teneur de marché doit en émettre des milliers par jour.
Intuition
Un pool de liquidité remplace la file d'attente par un stock. Au lieu de chercher une contrepartie, vous échangez avec une réserve commune : vous y déposez des dollars, vous en retirez des SOL. Le stock est toujours là, donc la transaction a toujours lieu — au prix que le stock impose.
Un pool est un contrat intelligent contenant deux actifs, appelés une paire (par exemple SOL/USDC). Le glossaire de LP Army le décrit comme « un pot commun de tokens verrouillés dans un contrat intelligent », une sorte de bureau de change communautaire.
L'AMM : la règle qui fixe le prix¶
Un AMM (Automated Market Maker, teneur de marché automatisé) est la formule qui décide du prix en fonction des quantités présentes dans le pool.
Le modèle historique, dit à produit constant, impose :
| Symbole | Signification | Unité |
|---|---|---|
| \(x\) | Quantité du premier token dans le pool | tokens |
| \(y\) | Quantité du second token dans le pool | tokens |
| \(k\) | Constante du pool, inchangée par les swaps | tokens² |
Le prix instantané du premier token exprimé dans le second vaut \(y/x\).
Conséquence directe : acheter du token \(x\) diminue \(x\) et augmente \(y\), donc fait monter le prix. C'est ce qu'on appelle l'impact de prix. Plus le pool est petit, plus une transaction donnée déplace le prix.
Vérifier numériquement l'impact de prix
Prenons un pool contenant \(x = 1000\) SOL et \(y = 100\,000\) USDC. Alors \(k = 10^8\) et le prix vaut \(100\,000/1000 = 100\) USDC par SOL.
Un acheteur retire 10 SOL. Il reste \(x = 990\). Pour conserver \(k = 10^8\), il faut \(y = 10^8/990 \approx 101\,010{,}1\) USDC. L'acheteur a donc versé environ 1 010,1 USDC pour 10 SOL, soit 101,01 USDC l'unité au lieu de 100. L'écart de 1 % est l'impact de prix.
Le nouveau prix affiché devient \(101\,010{,}1/990 \approx 102{,}03\) USDC.
Le fournisseur de liquidité¶
Le fournisseur de liquidité (LP) est celui qui alimente le stock. Il dépose les deux tokens de la paire et reçoit en échange une preuve de dépôt : un jeton LP dans les modèles classiques, un NFT de position dans les modèles récents de Meteora.
Sa rémunération est le frais de swap : un pourcentage prélevé sur chaque transaction traversant le pool, réparti entre les fournisseurs au prorata de leur part de liquidité.
À retenir
Un fournisseur de liquidité est un commerçant, pas un investisseur : il ne parie pas sur la hausse d'un actif, il vend un service — la disponibilité immédiate d'une contrepartie — et se fait payer à la transaction.
Son revenu dépend donc du volume, pas de la direction du prix. C'est la raison pour laquelle toutes les leçons de LP Army répètent « Volume is king ».
Les trois briques de l'infrastructure Solana¶
L'academy consacre son niveau Basics à trois notions dont un fournisseur ne peut pas faire l'économie.
DEX contre CEX¶
Un CEX (bourse centralisée) détient vos clés : vous lui confiez vos fonds. Un DEX (bourse décentralisée) ne les détient pas : vous signez chaque opération depuis votre portefeuille. Meteora est un DEX. La conséquence est double — personne ne peut geler vos fonds, et personne ne peut vous les rendre si vous vous trompez.
L'agrégateur¶
Un agrégateur comme Jupiter ne détient pas de liquidité : il route chaque swap vers le ou les DEX offrant le meilleur prix. Pour un fournisseur, c'est déterminant : un pool bien placé reçoit du volume routé par Jupiter sans que son créateur ait rien à faire.
Le RPC¶
Un RPC (Remote Procedure Call) est le point d'entrée qui relie votre portefeuille aux validateurs du réseau. L'academy en fait un point de vigilance concret : un RPC saturé fait échouer vos transactions au pire moment, c'est-à-dire quand la volatilité est maximale et que vous voulez sortir.
Erreur fréquente
Croire que l'échec d'une transaction est sans conséquence. Sur une position à plage serrée pendant un mouvement violent, quinze secondes de retard suffisent à faire sortir le prix de votre plage. La leçon DLMM Operations recommande explicitement de configurer son RPC et ses frais de priorité avant d'en avoir besoin.
Ce que ce chapitre pose¶
| Notion | Définition courte |
|---|---|
| Pool | Réserve de deux tokens permettant l'échange sans contrepartie directe |
| AMM | Formule fixant le prix à partir des quantités du pool |
| Impact de prix | Déplacement du prix causé par une transaction |
| Slippage | Écart entre le prix attendu et le prix obtenu |
| LP | Celui qui dépose dans le pool et perçoit les frais |
| Frais de swap | Prélèvement sur chaque transaction, revenu du LP |
Le chapitre suivant montre pourquoi ce modèle simple gaspille du capital, et ce que la liquidité concentrée y change.