Комиссии CPMM

​

Две независимые комиссии, четыре направления

1. Торговая комиссия — взимается по ставке AmmConfig.trade_fee_rate и распределяется между тремя направлениями:
   • Доля LP — остаётся в хранилище и увеличивает k. Получается неявно при сжигании токенов LP.
   • Доля протокола — накапливается в PoolState.protocol_fees_token*; собирается protocol_owner через CollectProtocolFee.
   • Доля фонда — накапливается в PoolState.fund_fees_token*; собирается fund_owner через CollectFundFee.
2. Комиссия создателя (опциональная, для каждого пула) — взимается по ставке AmmConfig.creator_fee_rate независимо от торговой комиссии и накапливается в PoolState.creator_fees_token*. Создатель может собрать её через CollectCreatorFee, или любой плательщик может запустить путь CollectCreatorFeePermissionless с ограничениями на направление. Активна только если пул был создан с enable_creator_fee = true. С обновления от 2026-09-13 накопленная комиссия создателя разделяется ещё раз во время сбора: настраиваемая доля переводится в протокольный бакет пула, и только остаток достаётся создателю — см. Доля протокола в комиссии создателя.

​

Ставки и единицы

• trade_fee_rate — доля объёма своп. 2500 ⇒ 0,25% соответствующей стороны (входа или выхода, в зависимости от creator_fee_on — см. раздел “С какой стороны своп берутся комиссии” ниже).
• creator_fee_rate — доля объёма своп, взимается отдельно от торговой комиссии. 1000 ⇒ 0,10% соответствующей стороны.
• protocol_fee_rate и fund_fee_rate — доли торговой комиссии, а не объёма. 120_000 ⇒ 12% торговой комиссии.
• creator_fee_share_rate — доля накопленной комиссии создателя, не объёма и не торговой комиссии. 200_000 ⇒ 20% того, что находится в creator_fees_token* в момент сбора. 0 (по умолчанию) оставляет всю комиссию создателя создателю.

​

Разделение в коде

// Переформулировано из raydium-cp-swap/programs/cp-swap/src/curve/{calculator,fees}.rs.
// Фактический код ветвится на `is_creator_fee_on_input`; обе ветви сохраняют
// инвариант, что creator_fee — это собственная ставка, никогда не срез trade_fee.

const FEE_RATE_DENOMINATOR_VALUE: u64 = 1_000_000;

pub struct FeeBreakdown {
    pub amount_in_after_fees: u64,    // вход минус все комиссии, взятые со стороны входа
    pub amount_out_after_fees: u64,   // выход минус любая комиссия создателя, взятая со стороны выхода
    pub trade_fee:    u64,            // → разделяется на бакеты LP / протокол / фонд ниже
    pub protocol_fee: u64,            // доля trade_fee
    pub fund_fee:     u64,            // доля trade_fee
    pub creator_fee:  u64,            // независимый бакет (сторона входа или выхода)
}

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 */) {
    // Две ставки складываются, поэтому мы округляем один раз на комбинированной комиссии,
    // затем разделяем пропорционально — это чисто трюк округления/эффективности.
    // Разделение соблюдает ставки точно: 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) {
    // Когда creator_fee_on маршрутизирует комиссию создателя на сторону выхода,
    // trade_fee берётся на входе как одна ставка, и creator_fee
    // вычисляется против выхода кривой.
    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)
}

• Общая комиссия на входе округляется вверх, поэтому пул никогда не недозаряжает.
• Подразделения trade_fee (протокол, фонд) округляются вниз, поэтому их сумма никогда не превышает trade_fee; остаток — это доля LP.
• lp_share = trade_fee − protocol_fee − fund_fee (creator_fee не вычитается здесь, потому что это собственный бакет).
• Комиссия создателя берётся со входа или выхода в зависимости от PoolState.creator_fee_on (см. следующий раздел). Ставка остаётся неизменной в любом случае.

​

С какой стороны своп берутся комиссии

​

Как “накопленные” комиссии взаимодействуют с кривой

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)

• Котировка по сырым балансам неправильна. Если вы построите котировщик на основе getTokenAccountBalance, вы будете постоянно переоценивать цену, которую пул будет соблюдать. Всегда вычитайте накопленные комиссии или моделируйте через SwapBaseInput / API.
• CollectProtocolFee не движет цену. Он перемещает токены из хранилища и обнуляет счётчики protocol_fees_token*, поэтому curve_x и curve_y остаются неизменными.
• Комиссии LP не накапливаются в счётчик. Они неявны в балансе хранилища. Право LP на накопленные комиссии LP осуществляется путём сжигания токенов LP (т. е. через Withdraw) — нет CollectLpFee.

​

Взаимодействие с комиссиями передачи Token-2022

1. Комиссия передачи входной монеты на amount_in (органу сбора комиссий монеты).
2. Комиссия пула trade_fee на остаток (разделена как выше).
3. Комиссия передачи выходной монеты на amount_out (органу сбора комиссий монеты).

​

Комиссия создателя

• Включена при создании пула. Initialize устанавливает enable_creator_fee = false по умолчанию; пулы, созданные через InitializeWithPermission (используется выпускниками LaunchLab и другими закрытыми путями), могут передать enable_creator_fee = true и выбрать creator_fee_on.
• Ставка общая с уровнем комиссии. Сама ставка — это AmmConfig.creator_fee_rate, одно и то же значение для каждого пула, привязанного к этой конфигурации. Каждый пул затем решает, взимать ли её (enable_creator_fee) и с какой стороны своп взимать (creator_fee_on). Когда enable_creator_fee = false, эффективная ставка комиссии создателя пула равна нулю независимо от значения конфигурации (см. PoolState::adjust_creator_fee_rate в исходном коде).
• Независима от торговой комиссии. Комиссия создателя никогда не уменьшает доли LP / протокол / фонд — это собственная ставка, применяемая отдельно, накапливаемая в собственных счётчиках.
• Собирается через CollectCreatorFee или CollectCreatorFeePermissionless. Исходный путь требует подписи PoolState.pool_creator. Путь без разрешения позволяет любому плательщику запустить сбор, но фиксирует оба направления на канонических ATA создателя. Оба пути сначала рассчитывают долю протокола — см. следующий раздел.
• Не может быть повторно включена или переведена после создания. Пул, инициализированный с enable_creator_fee = false, никогда не будет взимать комиссию создателя; инициализированный с конкретным creator_fee_on не может переключать стороны.

​

Доля протокола в комиссии создателя

​

Откуда берётся ставка

1. PDA CreatorFeeShare — семена ["creator_fee_share", creator, amm_config]. Когда этот счёт существует и принадлежит CPMM, его share_rate побеждает. Это позволяет протоколу согласовать ставку для каждого создателя на данном уровне комиссии без изменения самого уровня.
2. AmmConfig.creator_fee_share_rate — по умолчанию для каждого создателя на этом уровне комиссии. Используется всякий раз, когда PDA не существует.

​

Что делает разделение

// programs/cp-swap/src/states/creator_fee_share.rs
shared_amount  = floor(creator_fee * share_rate / 1_000_000);   // протоколу
creator_amount = creator_fee - shared_amount;                   // создателю

• creator_amount_{0,1} передаётся из хранилищ на счета токенов создателя.
• shared_amount_{0,1} добавляется к protocol_fees_token_{0,1} и остаётся в хранилище до тех пор, пока владелец протокола не соберёт его с помощью CollectProtocolFee. Нет отдельной инструкции и нет отдельного счётчика для неё.
• creator_fees_token_{0,1} обнуляются, точно как раньше.

• Округление благоприятствует создателю. Доля протокола округляется вниз, поэтому пыль остаётся с создателем — то же направление, что и protocol_fee и fund_fee, которые также вырезают долю из уже накопленной комиссии.
• Значение сохраняется. creator_amount + shared_amount == creator_fee для каждой ставки и каждой комиссии, включая u64::MAX.
• share_rate = 0 — это холостой ход. Как стандартное значение конфигурации, так и отсутствие PDA CreatorFeeShare оставляют всю комиссию создателя создателю, что является поведением до обновления.

​

Что это означает для интеграторов

• LP и котировка не затронуты. Общая сумма перемещается между двумя счётчиками, которые оба уже исключены из представления кривой о хранилище (vault_amount_without_fee), поэтому curve_x и curve_y не движутся при сборке. k не затронут.
• Оценщик комиссии создателя, который читает creator_fees_token*, теперь переоценивает выплату. Умножьте на (1 − share_rate / 1_000_000), используя ставку, которая фактически применяется к этой паре (creator, amm_config), а не стандартную конфигурацию.
• protocol_fees_token* растёт вне своп. Монитор, который согласует накопление протокола с объёмом своп, увидит скачки при каждом сборе комиссии создателя. Накопление протокола больше не только trade_fee × protocol_fee_rate.
• Ставка может измениться между накоплением и сбором. Она читается во время сбора, поэтому комиссии, которые накопились под одной ставкой, рассчитываются по любой ставке, которая действует, когда кто-то вызывает Collect*.

​

Операционный поток сбора

​

Изменение уровня комиссии

• Переместить пул из одного AmmConfig в другой.
• Переоценить уже накопленные комиссии задним числом.
• Собрать комиссии без подписи protocol_owner / fund_owner.

​

Чтение комиссий из работающего пула

// Off-chain: текущие накопленные комиссии в каждом бакете.
// SDK экспортирует макет, а не класс `PoolState`, и поля комиссии
// названы ...MintA / ...MintB — нет полей ...Token0 / ...Token1.
import { CpmmPoolInfoLayout } from "@raydium-io/raydium-sdk-v2";

const pool = await connection.getAccountInfo(poolStatePda);
const decoded = CpmmPoolInfoLayout.decode(pool!.data);   // без .slice(8) — макет
                                                          // включает дискриминатор
console.log(
  "Накопленный протокол:",
  decoded.protocolFeesMintA.toString(),
  decoded.protocolFeesMintB.toString(),
);
console.log(
  "Накопленный фонд:",
  decoded.fundFeesMintA.toString(),
  decoded.fundFeesMintB.toString(),
);
console.log(
  "Накопленный создатель:",
  decoded.creatorFeesMintA.toString(),
  decoded.creatorFeesMintB.toString(),
);
// То, что фактически получает создатель, — это минус доля протокола, разрешённая во время
// сбора из PDA CreatorFeeShare (creator, ammConfig), если он существует, и
// из AmmConfig.creator_fee_share_rate в противном случае. См. "Доля протокола в комиссии создателя"
// выше.

// Off-chain: эффективные ставки сегодня.
// trade_fee_rate, creator_fee_rate — доли объёма (знаменатель 1e6).
// protocol_fee_rate, fund_fee_rate — доли *торговой комиссии* (тот же знаменатель).
const config = await fetch("https://api-v3.raydium.io/main/cpmm-config")
  .then((r) => r.json());
// `configId` на декодированном пуле — это PublicKey счёта конфигурации, а не индекс.
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:",       (tradeFeeOfVolume * lpOfTradeFee * 100).toFixed(4), "%");
console.log("Эффективная комиссия протокола:", (tradeFeeOfVolume * protocolOfTradeFee * 100).toFixed(4), "%");
console.log("Эффективная комиссия фонда:",     (tradeFeeOfVolume * fundOfTradeFee * 100).toFixed(4), "%");
console.log(
  "Эффективная комиссия создателя:",
  decoded.enableCreatorFee
    ? ((tier.creatorFeeRate / 1_000_000) * 100).toFixed(4) + " %"
    : "0 % (отключена на этом пуле)",
);

​

Сравнение с CLMM и AMM v4

• AMM v4 использует фиксированную торговую комиссию 0,25% с другим разделением LP/протокол и без комиссии фонда.
• CLMM комиссии — это уровень интервала тиков, накапливаются для каждой позиции (не для каждого пула) и получаются через DecreaseLiquidity или CollectFees.

​

Куда дальше

• products/cpmm/math — где вычитание торговой комиссии подключается к кривой.
• products/cpmm/instructions — списки счётов инструкции Collect*, включая счёт creator_fee_share, который теперь требуют оба пути создателя.
• algorithms/token-2022-transfer-fees — как правильно объединить комиссию своп пула с комиссией передачи монеты.

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