Frais AMM v4

Les frais de trading de 0,25 %, leur répartition LP / protocole, la génération de PnL à partir des remplissages OpenBook, et comment l’admin récupère les frais de protocole accumulés.

Cette page est traduite automatiquement par IA. La version anglaise fait foi.

Voir la version anglaise →

​

Le seul palier publié

Contrairement à CPMM et CLMM, AMM v4 n’a pas de compte AmmConfig. Les frais sont stockés directement dans la structure AmmInfo.fees de chaque pool et sont fixes à la création du pool. Les valeurs par défaut qui couvrent essentiellement tous les pools AMM v4 actifs :

Champ on-chain	Défaut	Signification
swap_fee_numerator / swap_fee_denominator	25 / 10_000	Frais de trading bruts sur les swaps par le chemin AMM : 0,25 % du volume d’entrée.
trade_fee_numerator / trade_fee_denominator	25 / 10_000	Vestigial après la suppression d’OpenBook (historiquement utilisé pour la tarification des ordres limités). Identique à swap_fee par défaut : 0,25 %.
pnl_numerator / pnl_denominator	12 / 100	Part du protocole dans les frais de swap : 12 % — c’est-à-dire 0,25 % × 12 % = 0,03 % du volume. S’accumule dans les compteurs need_take_pnl_*.
min_separate_numerator / min_separate_denominator	5 / 10_000	Seuil de précision interne utilisé par la logique d’arrondi de répartition des frais.

Notez que pnl_numerator / pnl_denominator est une fraction des frais de swap, et non du volume de trading — une confusion courante. La part LP est le complément (88 % des frais = 0,22 % du volume) et est implicite ; il n’y a pas de numérateur séparé pour la « part LP ».

Un petit nombre de pools anciens ont été créés avec des numérateurs différents ; lisez toujours AmmInfo.fees avant de citer.

Il n’y a pas de frais de fonds et pas de frais de créateur : ce sont des inventions de CPMM/CLMM qui n’existaient pas dans le modèle de frais original d’AMM v4.

​

Comment la répartition est calculée

À chaque swap, le pool prélève les frais de trading bruts sur le montant d’entrée, puis répartit :

gross_fee   = ceil(amount_in * swap_fee_numerator / swap_fee_denominator)        // 0.25% of amount_in
pnl_portion = gross_fee * pnl_numerator / pnl_denominator                        // 12% of gross_fee
lp_portion  = gross_fee − pnl_portion                                            // 88% of gross_fee

• lp_portion reste dans le coffre et contribue au prochain k. Les LP le capturent en rachetant les tokens LP plus tard.
• pnl_portion incrémente AmmInfo.state_data.need_take_pnl_coin ou need_take_pnl_pc selon le côté d’entrée du swap.

Même astuce de préservation d’invariant que CPMM : le montant PnL se trouve physiquement dans le coffre mais est soustrait des réserves utilisées dans la courbe, donc TakePnl déplace les tokens sans décaler le prix.

​

PnL d’OpenBook (historique)

Supprimé. L’intégration OpenBook a été supprimée du programme, donc le deuxième flux de PnL décrit dans cette section n’est plus généré. Les compteurs total_pnl_{coin,pc} sont maintenant des champs dépréciés — ils conservent des valeurs historiques figées et ne sont jamais mis à jour. Le chemin des frais de protocole de 0,03 % (ci-dessus) n’est pas affecté et reste actif.

Historiquement, AMM v4 avait un deuxième flux de revenus de type frais : quand ses ordres limités sur OpenBook étaient remplis, le pool pouvait être du côté preneur du remplissage et gagner ou payer l’écart maker/taker du marché. Ces événements PnL se réglaient dans les coffres du pool pendant MonitorStep et le programme les créditait à state_data.total_pnl_{coin,pc} comme compteurs informationnels.

• Quand la grille affichée du pool était correctement calibrée autour du prix de la courbe, les remplissages OpenBook tendaient à être positifs en frais pour le pool — l’AMM faisait effectivement du market-making sur OpenBook et gagnait des remises maker.
• Quand OpenBook s’arrêtait ou que la file d’attente d’événements se remplissait, le pool pouvait rester sur des ordres obsolètes qui se remplissaient à des prix désavantageux, produisant un PnL négatif. Ce couplage opérationnel était l’une des motivations pour s’éloigner de la conception hybride.

Ce PnL OpenBook n’était pas identique aux frais de protocole de 0,03 %. Le PnL OpenBook gonflait directement les réserves du pool (bénéficiant aux LP + protocole proportionnellement à la répartition des frais), tandis que les frais de protocole de 0,03 % étaient marqués spécifiquement pour la récupération par l’admin. Avec le côté OpenBook désactivé, le seul accrual de frais aujourd’hui est le 0,25 % sur les swaps AMM et sa répartition 22/3.

​

Collecte

L’admin (multisig Raydium) appelle WithdrawPnl pour récupérer need_take_pnl_* dans les comptes « propriétaire PnL » au niveau du pool configurés sur l’AmmConfig du programme (une config différente, scoped au programme — pas l’AmmConfig par pool de style CPMM). La récupération :

1. Transfère need_take_pnl_coin / need_take_pnl_pc des coffres du pool vers la destination PnL.
2. Remet les compteurs à zéro.

Il n’y a plus d’étape de règlement OpenBook. Si le solde du coffre est insuffisant pour couvrir le PnL accumulé, l’instruction retourne maintenant TakePnlError directement. L’opération ne déplace pas la courbe — les LP ne devraient voir aucun changement de prix lors d’un appel WithdrawPnl. Notez que la disposition du compte WithdrawPnl a changé dans la mise à jour 2026-07 (voir instructions).

​

Rachat des frais LP

Il n’y a pas d’instruction dédiée « collecter les frais LP ». Les frais LP s’accumulent dans les coffres et gonflent k au fil du temps ; les LP les réalisent en brûlant les tokens LP via Withdraw. La valeur d’un token LP augmente de manière monotone à mesure que (coin_reserve_effective, pc_reserve_effective) augmentent.

​

Visualisation : où vont 1 000 USDC de volume

Sur un swap lourd en USDC de $1 000 contre un pool avec paramètres par défaut :

Frais de trading bruts (0,25 %) :   $2,50
  Part LP   (0,22 %) :       $2,20   → reste dans le pool, augmente k
  Part PnL  (0,03 %) :       $0,30   → need_take_pnl_pc, récupérée par TakePnl
Reste envoyé à l'utilisateur :   $997,50   (moins l'impact de prix lié à la courbe)

Comparez à CPMM AmmConfig[0] (palier 0,25 %, pas de frais de créateur) : LP obtient $2,10, protocole $0,30, fonds $0,10. CPMM introduit la ligne des fonds en la prélevant sur ce qui aurait été la part LP dans le palier équivalent d’AMM v4.

​

Tableau de comparaison

	AMM v4	CPMM index=0	CLMM index=2
Frais de trading	0,25 %	0,25 %	0,25 %
LP	0,22 %	0,21 %	Varie selon les émissions
Protocole	0,03 %	0,03 %	Par palier
Fonds	N/A	0,01 %	Par palier
Créateur (optionnel)	N/A	0 par défaut	N/A
Où les frais se situent	Coffre du pool + need_take_pnl_*	Coffre du pool + protocol_fees_* + fund_fees_*	Global + par tick + par position

Matrice complète dans reference/fee-comparison.

​

Notes pour les intégrateurs

• Cotation. Récupérez AmmInfo via le SDK ou api-v3.raydium.io/pools/info/ids. Les réserves sont maintenant limitées au coffre, vous pouvez donc coter directement par rapport aux soldes du coffre — n’oubliez pas de soustraire need_take_pnl_* (le PnL accumulé est détenu dans le coffre mais exclu de la courbe).
• Paramètres de frais obsolètes. En principe SetParams pourrait changer swap_fee_numerator, mais en pratique le multisig Raydium n’a pas changé les valeurs par défaut pour aucun pool actif. Néanmoins, lisez toujours l’état on-chain plutôt que de coder en dur.
• Pas de récompenses. AMM v4 ne supporte pas les émissions de récompenses au niveau du pool. Les fermes écosystème héritées (Farm v3 / v5 / v6) sont l’équivalent de la couche de staking — voir products/farm-staking.

​

Où aller ensuite

• products/amm-v4/math — la dérivation des frais de trading dans la courbe.
• products/amm-v4/instructions — listes de comptes pour WithdrawPnl / SetParams.
• reference/fee-comparison — matrice côte à côte.

Sources :

• Programme Raydium AMM — raydium-io/raydium-amm
• Champs numérateur/dénominateur des frais AMM v4 on-chain (vérifiés par rapport aux comptes AmmInfo du mainnet).