CPMM-Gebühren

​

Zwei unabhängige Gebühren, vier Ziele

1. Handelsgebühr — erhoben bei AmmConfig.trade_fee_rate und aufgeteilt auf drei Ziele:
   • LP-Anteil — bleibt im Vault und vergrößert k. Wird implizit durch das Verbrennen von LP-Token beansprucht.
   • Protokoll-Anteil — aufgelaufen zu PoolState.protocol_fees_token*; eingezogen durch den protocol_owner via CollectProtocolFee.
   • Fund-Anteil — aufgelaufen zu PoolState.fund_fees_token*; eingezogen durch den fund_owner via CollectFundFee.
2. Creator-Gebühr (optional, pro Pool) — erhoben bei AmmConfig.creator_fee_rate unabhängig von der Handelsgebühr und aufgelaufen zu PoolState.creator_fees_token*. Der Creator kann sie über CollectCreatorFee einziehen, oder jeder Zahler kann den zielgebundenen Pfad CollectCreatorFeePermissionless auslösen. Aktiv nur, wenn der Pool mit enable_creator_fee = true erstellt wurde. Seit dem Upgrade vom 2026-09-19 wird die aufgelaufene Creator-Gebühr bei der Einziehung erneut aufgeteilt: Ein konfigurierbarer Anteil wird in den Protokoll-Bucket des Pools verschoben und nur der Rest erreicht den Creator — siehe Protokoll-Anteil der Creator-Gebühr.

​

Sätze und Einheiten

• trade_fee_rate ist ein Bruchteil des Swap-Volumens. 2500 ⇒ 0,25% der relevanten Seite (Input oder Output, abhängig von creator_fee_on — siehe „Von welcher Seite des Trades die Gebühren erhoben werden” unten).
• creator_fee_rate ist ein Bruchteil des Swap-Volumens, erhoben separat von der Handelsgebühr. 1000 ⇒ 0,10% der relevanten Seite.
• protocol_fee_rate und fund_fee_rate sind Bruchteile der Handelsgebühr, nicht des Volumens. 120_000 ⇒ 12% der Handelsgebühr.
• creator_fee_share_rate ist ein Bruchteil der aufgelaufenen Creator-Gebühr, nicht des Volumens und nicht der Handelsgebühr. 200_000 ⇒ 20% von dem, was sich in creator_fees_token* zum Zeitpunkt der Einziehung befindet. 0 (Standard) lässt die gesamte Creator-Gebühr beim Creator.

​

Die Aufteilung im 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)
}

• Die Gesamtgebühr auf Input rundet auf, damit der Pool nie unterberechnet.
• Die Unter-Aufteilungen von trade_fee (Protokoll, Fund) runden ab, damit ihre Summe trade_fee nie überschreitet; der Rest ist der LP-Anteil.
• lp_share = trade_fee − protocol_fee − fund_fee (creator_fee wird hier nicht subtrahiert, da es sein eigener Bucket ist).
• Die Creator-Gebühr wird je nach PoolState.creator_fee_on von der Input- oder Output-Seite erhoben (siehe nächster Abschnitt). Der Satz bleibt in beiden Fällen unverändert.

​

Von welcher Seite des Trades die Gebühren erhoben werden

​

Wie „aufgelaufene” Gebühren mit der Kurve interagieren

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)

• Quoting von Raw-Salden ist falsch. Wenn Sie einen Quoter von getTokenAccountBalance erstellen, werden Sie den Preis, den der Pool ehrt, konsistent überzeichnen. Subtrahieren Sie immer aufgelaufene Gebühren, oder simulieren Sie via SwapBaseInput / die API.
• CollectProtocolFee bewegt den Preis nicht. Es bewegt Token aus dem Vault und setzt die protocol_fees_token*-Zähler auf Null, also bleiben curve_x und curve_y unverändert.
• LP-Gebühren fallen nicht auf einem Zähler an. Sie sind implizit im Vault-Saldo. Die Berechtigung des LP auf aufgelaufene LP-Gebühren wird durch das Verbrennen von LP-Token ausgeübt (d. h. via Withdraw) — es gibt kein CollectLpFee.

​

Interaktion mit Token-2022-Transfergebühren

1. Die Transfergebühr des Input-Mints auf amount_in (an die Gebührenautorität des Mints).
2. Die trade_fee des Pools auf den Rest (aufgeteilt wie oben).
3. Die Transfergebühr des Output-Mints auf amount_out (an die Gebührenautorität des Mints).

​

Creator-Gebühr

• Bei Pool-Erstellung aktiviert. Initialize setzt enable_creator_fee = false standardmäßig; Pools, die über InitializeWithPermission erstellt werden (verwendet von LaunchLab-Graduierungen und anderen gated Pfaden), können enable_creator_fee = true übergeben und creator_fee_on wählen.
• Satz wird mit der Gebühren-Stufe geteilt. Der Satz selbst ist AmmConfig.creator_fee_rate, der gleiche Wert über jeden Pool, der an diese Konfiguration gebunden ist. Jeder Pool entscheidet dann, ob er ihn erhebt (enable_creator_fee) und von welcher Seite des Swaps er ihn erhebt (creator_fee_on). Wenn enable_creator_fee = false, ist die effektive Creator-Gebührenrate des Pools unabhängig vom Konfigurationswert Null (siehe PoolState::adjust_creator_fee_rate im Quellcode).
• Unabhängig von der Handelsgebühr. Die Creator-Gebühr reduziert nie die LP-/Protokoll-/Fund-Anteile — sie ist ihr eigener Satz, separat angewendet, in ihren eigenen Zählern aufgelaufen.
• Eingezogen via CollectCreatorFee oder CollectCreatorFeePermissionless. Der ursprüngliche Pfad erfordert, dass PoolState.pool_creator signiert. Der gebührenfreie Pfad lässt jeden Zahler die Einziehung auslösen, aber fixiert beide Ziele auf die kanonischen ATAs des Creators. Beide Pfade begleichen zuerst den Protokoll-Anteil — siehe den nächsten Abschnitt.
• Kann nach der Erstellung nicht erneut aktiviert oder umgeleitet werden. Ein Pool, der mit enable_creator_fee = false initialisiert wurde, wird nie eine Creator-Gebühr erheben; einer, der mit einem bestimmten creator_fee_on initialisiert wurde, kann nicht die Seiten wechseln.

​

Protokoll-Anteil der Creator-Gebühr

​

Woher der Satz kommt

1. CreatorFeeShare-PDA — Seeds ["creator_fee_share", creator, amm_config]. Wenn dieses Konto existiert und von CPMM besessen wird, gewinnt sein share_rate. Es ermöglicht dem Protokoll, einen Pro-Creator-Satz auf einer bestimmten Gebühren-Stufe auszuhandeln, ohne die Stufe selbst zu berühren.
2. AmmConfig.creator_fee_share_rate — der Standard für jeden Creator auf dieser Gebühren-Stufe. Verwendet, wenn die PDA nicht existiert.

​

Was die Aufteilung tut

// 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} wird aus den Vaults zu den Token-Konten des Creators transferiert.
• shared_amount_{0,1} wird zu protocol_fees_token_{0,1} addiert und bleibt im Vault, bis der Protokoll-Owner es mit CollectProtocolFee einzieht. Es gibt keine separate Anweisung und keinen separaten Zähler dafür.
• creator_fees_token_{0,1} werden auf Null gesetzt, genau wie zuvor.

• Rundung bevorzugt den Creator. Der Protokoll-Anteil rundet ab, also bleibt Staub beim Creator — die gleiche Richtung wie protocol_fee und fund_fee, die auch einen Anteil aus einer bereits aufgelaufenen Gebühr herausschneiden.
• Wert wird konserviert. creator_amount + shared_amount == creator_fee für jeden Satz und jede Gebühr, einschließlich u64::MAX.
• share_rate = 0 ist ein No-Op. Sowohl der Standard-Konfigurationswert als auch das Fehlen einer CreatorFeeShare-PDA lassen die gesamte Creator-Gebühr beim Creator, was das Verhalten vor dem Upgrade ist.

​

Was es für Integratoren bedeutet

• LPs und Quoting sind unbeeinträchtigt. Der gemeinsame Betrag bewegt sich zwischen zwei Zählern, die beide bereits von der Kurvenansicht des Vaults ausgeschlossen sind (vault_amount_without_fee), also bewegen sich curve_x und curve_y nicht über eine Einziehung. k ist unverändert.
• Ein Creator-Gebühren-Schätzer, der creator_fees_token* liest, überzeichnet jetzt die Auszahlung. Multiplizieren Sie mit (1 − share_rate / 1_000_000) unter Verwendung des Satzes, der tatsächlich auf dieses (creator, amm_config)-Paar angewendet wird, nicht der Konfiguration-Standard.
• protocol_fees_token* wächst außerhalb von Swaps. Ein Monitor, der die Protokoll-Abgrenzung gegen das Swap-Volumen abgleicht, wird Sprünge bei jeder Creator-Gebühren-Einziehung sehen. Die Protokoll-Abgrenzung ist nicht mehr nur trade_fee × protocol_fee_rate.
• Der Satz kann sich zwischen Abgrenzung und Einziehung ändern. Er wird bei der Einziehung gelesen, also werden Gebühren, die unter einem Satz aufgelaufen sind, zu dem Satz abgerechnet, der in Kraft ist, wenn jemand Collect* aufruft.

​

Operativer Ablauf der Einziehung

​

Ändern einer Gebühren-Stufe

• Einen Pool von einer AmmConfig zu einer anderen verschieben.
• Bereits aufgelaufene Gebühren rückwirkend neu bewerten.
• Gebühren ohne den protocol_owner / fund_owner-Unterzeichner einziehen.

​

Gebühren aus einem laufenden Pool lesen

// 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)",
);

​

Vergleich mit CLMM und AMM v4

• AMM v4 verwendet eine feste 0,25%-Handelsgebühr mit einer anderen LP-/Protokoll-Aufteilung und keine Fund-Gebühr.
• CLMM-Gebühren sind pro-Tick-Spacing-Stufe, aufgelaufen pro-Position (nicht pro-Pool), und beansprucht via DecreaseLiquidity oder CollectFees.

​

Wo es weitergeht

• products/cpmm/math — wo die Handelsgebühren-Abzug in die Kurve einfließt.
• products/cpmm/instructions — die Collect*-Anweisungs-Kontolisten, einschließlich des creator_fee_share-Kontos, das beide Creator-Pfade jetzt erfordern.
• algorithms/token-2022-transfer-fees — wie man eine Pool-Handelsgebühr mit einer Mint-Transfergebühr korrekt kombiniert.

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