Frais CPMM

​

Deux frais indépendants, quatre destinations

1. Frais de trading — prélevés à AmmConfig.trade_fee_rate et répartis entre trois destinations :
   • Part LP — reste dans le coffre et augmente k. Réclamée implicitement en brûlant les tokens LP.
   • Part protocole — accumulée dans PoolState.protocol_fees_token* ; collectée par le protocol_owner via CollectProtocolFee.
   • Part fonds — accumulée dans PoolState.fund_fees_token* ; collectée par le fund_owner via CollectFundFee.
2. Frais créateur (optionnel, par pool) — prélevés à AmmConfig.creator_fee_rate indépendamment du frais de trading et accumulés dans PoolState.creator_fees_token*. Le créateur peut les collecter via CollectCreatorFee, ou n’importe quel payeur peut déclencher le chemin contraint CollectCreatorFeePermissionless. Actif uniquement si le pool a été créé avec enable_creator_fee = true. Depuis la mise à jour du 2026-09-19, le frais créateur accumulé est à nouveau réparti au moment de la collecte : une part configurable est déplacée vers le bucket protocole du pool et seul le reste atteint le créateur — voir Part protocole du frais créateur.

​

Taux et unités

• trade_fee_rate est une fraction du volume de swap. 2500 ⇒ 0,25 % du côté pertinent (entrée ou sortie, selon creator_fee_on — voir « De quel côté du trade les frais sont prélevés » ci-dessous).
• creator_fee_rate est une fraction du volume de swap, prélevée séparément du frais de trading. 1000 ⇒ 0,10 % du côté pertinent.
• protocol_fee_rate et fund_fee_rate sont des fractions du frais de trading, pas du volume. 120_000 ⇒ 12 % du frais de trading.
• creator_fee_share_rate est une fraction du frais créateur accumulé, pas du volume ni du frais de trading. 200_000 ⇒ 20 % de ce qui se trouve dans creator_fees_token* au moment de sa collecte. 0 (la valeur par défaut) laisse tout le frais créateur au créateur.

​

La répartition, en code

// Paraphrased from raydium-cp-swap/programs/cp-swap/src/curve/{calculator,fees}.rs.
// The actual code branches on `is_creator_fee_on_input`; both branches preserve the
// invariant that creator_fee is its own rate, never a slice of trade_fee.

const FEE_RATE_DENOMINATOR_VALUE: u64 = 1_000_000;

pub struct FeeBreakdown {
    pub amount_in_after_fees: u64,    // input minus all fees taken on the input side
    pub amount_out_after_fees: u64,   // output minus any creator fee taken on the output side
    pub trade_fee:    u64,            // → split into LP / protocol / fund buckets below
    pub protocol_fee: u64,            // share of trade_fee
    pub fund_fee:     u64,            // share of trade_fee
    pub creator_fee:  u64,            // independent bucket (input or output side)
}

fn take_fees_on_input(
    amount_in: u64,
    trade_rate: u64,
    creator_rate: u64,
    protocol_rate: u64,
    fund_rate: u64,
) -> (u64 /* trade_fee */, u64 /* creator_fee */, u64 /* amount_in_after_fees */) {
    // The two rates are added so we round once on the combined fee, then split
    // proportionally — this is purely a rounding/efficiency trick. The split
    // honours the rates exactly: creator_fee/trade_fee == creator_rate/trade_rate.
    let total_fee = ((amount_in as u128) * ((trade_rate + creator_rate) as u128))
        .div_ceil(FEE_RATE_DENOMINATOR_VALUE as u128) as u64;

    let creator_fee = ((total_fee as u128) * (creator_rate as u128)
                       / ((trade_rate + creator_rate) as u128)) as u64;
    let trade_fee   = total_fee - creator_fee;

    (trade_fee, creator_fee, amount_in - total_fee)
}

fn take_creator_fee_on_output(amount_out_swapped: u64, creator_rate: u64) -> (u64, u64) {
    // When creator_fee_on routes the creator fee to the output side,
    // trade_fee is taken on input as a single rate, and creator_fee
    // is computed against the curve output.
    let creator_fee = ((amount_out_swapped as u128) * (creator_rate as u128))
        .div_ceil(FEE_RATE_DENOMINATOR_VALUE as u128) as u64;
    (amount_out_swapped - creator_fee, creator_fee)
}

fn split_trade_fee(
    trade_fee: u64,
    protocol_rate: u64,
    fund_rate: u64,
) -> (u64 /* protocol_fee */, u64 /* fund_fee */) {
    let protocol_fee = (trade_fee as u128 * protocol_rate as u128
                        / FEE_RATE_DENOMINATOR_VALUE as u128) as u64;
    let fund_fee     = (trade_fee as u128 * fund_rate as u128
                        / FEE_RATE_DENOMINATOR_VALUE as u128) as u64;
    (protocol_fee, fund_fee)
}

• Le frais total sur l’entrée arrondit vers le haut pour que le pool ne sous-facture jamais.
• Les sous-répartitions de trade_fee (protocole, fonds) arrondissent vers le bas pour que leur somme ne dépasse jamais trade_fee ; le reste est la part LP.
• lp_share = trade_fee − protocol_fee − fund_fee (creator_fee n’est pas soustrait ici car c’est son propre bucket).
• Le frais créateur est prélevé sur l’entrée ou la sortie selon PoolState.creator_fee_on (voir la section suivante). Le taux reste inchangé de toute façon.

​

De quel côté du trade les frais sont prélevés

​

Comment les frais « accumulés » interagissent avec la courbe

raw_vault_0_balance = getTokenAccountBalance(vault_0).amount
                    = lp_entitled + protocol_fees_token0
                      + fund_fees_token0 + creator_fees_token0

curve_x = raw_vault_0_balance − (protocol_fees_token0
                                  + fund_fees_token0
                                  + creator_fees_token0)

• Faire un devis sur les soldes bruts est faux. Si vous construisez un quoteur sur getTokenAccountBalance, vous surévaluerez systématiquement le prix que le pool honorera. Soustrayez toujours les frais accumulés, ou simulez via SwapBaseInput / l’API.
• CollectProtocolFee ne déplace pas le prix. Il déplace les tokens hors du coffre et met à zéro les compteurs protocol_fees_token*, donc curve_x et curve_y restent inchangés.
• Les frais LP ne s’accumulent pas dans un compteur. Ils sont implicites dans le solde du coffre. Le droit des LP aux frais LP accumulés est exercé en brûlant les tokens LP (c.-à-d., via Withdraw) — il n’y a pas de CollectLpFee.

​

Interaction avec les frais de transfert Token-2022

1. Le frais de transfert du mint d’entrée sur amount_in (à l’autorité de frais du mint).
2. Le trade_fee du pool sur le reste (réparti comme ci-dessus).
3. Le frais de transfert du mint de sortie sur amount_out (à l’autorité de frais du mint).

​

Frais créateur

• Activé à la création du pool. Initialize définit enable_creator_fee = false par défaut ; les pools créés via InitializeWithPermission (utilisés par les graduations LaunchLab et autres chemins contrôlés) peuvent passer enable_creator_fee = true et choisir creator_fee_on.
• Le taux est partagé avec le niveau de frais. Le taux lui-même est AmmConfig.creator_fee_rate, la même valeur sur chaque pool lié à cette config. Chaque pool décide alors s’il faut le facturer (enable_creator_fee) et de quel côté du swap le facturer (creator_fee_on). Quand enable_creator_fee = false, le taux de frais créateur effectif du pool est zéro indépendamment de la valeur de config (voir PoolState::adjust_creator_fee_rate dans la source).
• Indépendant du frais de trading. Le frais créateur ne réduit jamais les parts LP / protocole / fonds — c’est son propre taux, appliqué séparément, accumulé dans ses propres compteurs.
• Collecté via CollectCreatorFee ou CollectCreatorFeePermissionless. Le chemin original nécessite que PoolState.pool_creator signe. Le chemin sans permission permet à n’importe quel payeur de déclencher la collecte mais fixe les deux destinations aux ATA canoniques du créateur. Les deux chemins règlent d’abord la part du protocole — voir la section suivante.
• Ne peut pas être réactivé ou réacheminer après la création. Un pool initialisé avec enable_creator_fee = false ne facturera jamais de frais créateur ; un initialisé avec un creator_fee_on particulier ne peut pas changer de côté.

​

Part protocole du frais créateur

​

D’où vient le taux

1. PDA CreatorFeeShare — seeds ["creator_fee_share", creator, amm_config]. Quand ce compte existe et est possédé par CPMM, son share_rate gagne. Cela permet au protocole de négocier un taux par créateur sur un niveau de frais donné sans toucher au niveau lui-même.
2. AmmConfig.creator_fee_share_rate — la valeur par défaut pour chaque créateur sur ce niveau de frais. Utilisée chaque fois que le PDA n’existe pas.

​

Ce que fait la répartition

// programs/cp-swap/src/states/creator_fee_share.rs
shared_amount  = floor(creator_fee * share_rate / 1_000_000);   // to the protocol
creator_amount = creator_fee - shared_amount;                   // to the creator

• creator_amount_{0,1} est transféré hors des coffres vers les comptes de tokens du créateur.
• shared_amount_{0,1} est ajouté à protocol_fees_token_{0,1} et reste dans le coffre jusqu’à ce que le propriétaire du protocole le balaye avec CollectProtocolFee. Il n’y a pas d’instruction séparée ni de compteur séparé pour cela.
• creator_fees_token_{0,1} sont mis à zéro, exactement comme avant.

• L’arrondi favorise le créateur. La part protocole arrondit vers le bas, donc la poussière reste avec le créateur — la même direction que protocol_fee et fund_fee, qui carvent également une part d’un frais déjà accumulé.
• La valeur est conservée. creator_amount + shared_amount == creator_fee pour chaque taux et chaque frais, y compris u64::MAX.
• share_rate = 0 est une no-op. À la fois la valeur de config par défaut et l’absence d’un PDA CreatorFeeShare laissent tout le frais créateur au créateur, ce qui est le comportement pré-mise à jour.

​

Ce que cela signifie pour les intégrateurs

• Les LP et les devis ne sont pas affectés. Le montant partagé se déplace entre deux compteurs qui sont tous les deux déjà exclus de la vue de la courbe du coffre (vault_amount_without_fee), donc curve_x et curve_y ne bougent pas lors d’une collecte. k est inchangé.
• Un estimateur de frais créateur qui lit creator_fees_token* surévalue maintenant le paiement. Multipliez par (1 − share_rate / 1_000_000) en utilisant le taux qui s’applique réellement à cette paire (creator, amm_config), pas la valeur par défaut de config.
• protocol_fees_token* augmente en dehors des swaps. Un moniteur qui réconcilie l’accumulation du protocole par rapport au volume de swap verra des sauts à chaque collecte de frais créateur. L’accumulation du protocole n’est plus trade_fee × protocol_fee_rate seul.
• Le taux peut changer entre l’accumulation et la collecte. Il est lu au moment de la collecte, donc les frais qui se sont accumulés sous un taux se règlent au taux qui est en vigueur quand quelqu’un appelle Collect*.

​

Flux opérationnel de collecte

​

Modification d’un niveau de frais

• Déplacer un pool d’un AmmConfig à un autre.
• Réévaluer rétroactivement les frais déjà accumulés.
• Collecter les frais sans le signataire protocol_owner / fund_owner.

​

Lecture des frais d’un pool en cours d’exécution

// Off-chain: current accrued fees in each bucket.
// The SDK exports the layout, not a `PoolState` class, and the fee fields are
// named ...MintA / ...MintB — there are no ...Token0 / ...Token1 fields.
import { CpmmPoolInfoLayout } from "@raydium-io/raydium-sdk-v2";

const pool = await connection.getAccountInfo(poolStatePda);
const decoded = CpmmPoolInfoLayout.decode(pool!.data);   // no .slice(8) — the
                                                          // layout includes the discriminator
console.log(
  "Protocol accrued:",
  decoded.protocolFeesMintA.toString(),
  decoded.protocolFeesMintB.toString(),
);
console.log(
  "Fund accrued:",
  decoded.fundFeesMintA.toString(),
  decoded.fundFeesMintB.toString(),
);
console.log(
  "Creator accrued:",
  decoded.creatorFeesMintA.toString(),
  decoded.creatorFeesMintB.toString(),
);
// What the creator actually receives is this minus the protocol share, resolved at
// collection time from the (creator, ammConfig) CreatorFeeShare PDA if it exists and
// from AmmConfig.creator_fee_share_rate otherwise. See "Protocol share of the creator
// fee" above.

// Off-chain: effective rates today.
// trade_fee_rate, creator_fee_rate are fractions of volume (denominator 1e6).
// protocol_fee_rate, fund_fee_rate are fractions of the *trade fee* (same denominator).
const config = await fetch("https://api-v3.raydium.io/main/cpmm-config")
  .then((r) => r.json());
// `configId` on the decoded pool is the config account's PublicKey, not an index.
const tier = config.data.find((t) => t.id === decoded.configId.toBase58());

const tradeFeeOfVolume   = tier.tradeFeeRate / 1_000_000;
const protocolOfTradeFee = tier.protocolFeeRate / 1_000_000;
const fundOfTradeFee     = tier.fundFeeRate / 1_000_000;
const lpOfTradeFee       = 1 - protocolOfTradeFee - fundOfTradeFee;

console.log("LP fee effective:",       (tradeFeeOfVolume * lpOfTradeFee * 100).toFixed(4), "%");
console.log("Protocol fee effective:", (tradeFeeOfVolume * protocolOfTradeFee * 100).toFixed(4), "%");
console.log("Fund fee effective:",     (tradeFeeOfVolume * fundOfTradeFee * 100).toFixed(4), "%");
console.log(
  "Creator fee effective:",
  decoded.enableCreatorFee
    ? ((tier.creatorFeeRate / 1_000_000) * 100).toFixed(4) + " %"
    : "0 % (disabled on this pool)",
);

​

Comparaison avec CLMM et AMM v4

• AMM v4 utilise un frais de trading fixe de 0,25 % avec une répartition LP/protocole différente et pas de frais de fonds.
• CLMM les frais sont par niveau d’espacement de tick, accumulés par position (pas par pool), et réclamés via DecreaseLiquidity ou CollectFees.

​

Où aller ensuite

• products/cpmm/math — où la déduction du frais de trading se branche dans la courbe.
• products/cpmm/instructions — les listes de comptes d’instruction Collect*, y compris le compte creator_fee_share que les deux chemins créateur nécessitent maintenant.
• algorithms/token-2022-transfer-fees — comment combiner correctement un frais de trading de pool avec un frais de transfert de mint.

• raydium-io/raydium-cp-swap — states/config.rs, states/pool.rs, states/curve.rs
• Raydium API — GET /main/cpmm-config