Математика CPMM

Эта страница переведена с помощью ИИ. За эталон принимается английская версия.Открыть английскую версию →

Инвариант

CPMM поддерживает классический инвариант постоянного произведения на двух хранилищах:

x \cdot y = k

где x — баланс хранилища 0 после любых комиссий передачи Token-2022 при получении, аналогично для y. Каждый своп должен оставить k' ≥ k после учёта торговых комиссий, зачисленных LP (бакеты протокола, фонда и создателя не учитываются в k — они находятся в хранилище, но исключены из представления кривой, см. Комиссии на кривой ниже). Таким образом, k монотонно растёт со временем по мере накопления комиссий LP. Цена LP-токенов определяется резервами пула, а не k:

\text{цена LP в token0} = \frac{x}{\text{lpSupply}}, \qquad \text{цена LP в token1} = \frac{y}{\text{lpSupply}}

Сжигание ΔLP LP-токенов возвращает ровно ΔLP × x / lpSupply token0 и ΔLP × y / lpSupply token1. Ни кривая, ни k не изменяются при депозите или снятии — только своп меняет цену.

Модель комиссий на пути своп

CPMM применяет две независимо оцениваемые комиссии на каждый своп:

Торговая комиссия берётся на входной стороне по ставке AmmConfig.trade_fee_rate. Затем она разделяется на доли LP, протокола и фонда (доля LP остаётся в хранилище и увеличивает k; доли протокола и фонда извлекаются из учёта хранилища).
Комиссия создателя (активна только при enable_creator_fee == true) берётся по ставке AmmConfig.creator_fee_rate. Она берётся на входной или выходной стороне в зависимости от PoolState.creator_fee_on и направления своп (см. products/cpmm/fees). Это отдельный бакет — никогда не часть торговой комиссии.

Доля протокола в комиссии создателя не появляется нигде на этой странице, и это намеренно. Она применяется, когда CollectCreatorFee перемещает накопленные комиссии между двумя счётчиками, которые кривая уже исключает — не во время своп. Математика своп, котировки и k идентичны с ней и без неё. См. products/cpmm/fees.

Обозначим:

FEE_RATE_DENOMINATOR = 1_000_000
trade_fee_rate — из AmmConfig, например 2500 = 0,25% от соответствующей стороны объёма
creator_fee_rate — из AmmConfig, например 1000 = 0,10% от соответствующей стороны объёма
protocol_fee_rate, fund_fee_rate — выражены в единицах 1/FEE_RATE_DENOMINATOR торговой комиссии, а не объёма

Когда комиссия создателя на входной стороне:

total_input_fee = ceil(amount_in * (trade_fee_rate + creator_fee_rate) / FEE_RATE_DENOMINATOR)
creator_fee     = floor(total_input_fee * creator_fee_rate / (trade_fee_rate + creator_fee_rate))
trade_fee       = total_input_fee - creator_fee
amount_in_after_fees = amount_in - total_input_fee

Когда комиссия создателя на выходной стороне:

trade_fee            = ceil(amount_in * trade_fee_rate / FEE_RATE_DENOMINATOR)
amount_in_after_fees = amount_in - trade_fee
amount_out_curve     = curve_output(amount_in_after_fees, ...)
creator_fee          = ceil(amount_out_curve * creator_fee_rate / FEE_RATE_DENOMINATOR)
amount_out           = amount_out_curve - creator_fee

В обоих случаях торговая комиссия разделяется одинаково:

protocol_fee   = floor(trade_fee * protocol_fee_rate / FEE_RATE_DENOMINATOR)
fund_fee       = floor(trade_fee * fund_fee_rate     / FEE_RATE_DENOMINATOR)
lp_fee         = trade_fee - protocol_fee - fund_fee     // creator_fee НЕ вычитается здесь

Сумма protocol_fee + fund_fee + creator_fee хранится в хранилищах, но отслеживается отдельно в состоянии пула (protocol_fees_token*, fund_fees_token*, creator_fees_token*). Когда проверка инварианта постоянного произведения проверяет k' ≥ k, она использует балансы хранилища минус все три накопленные, но не собранные комиссии — таким образом, LP получают только lp_fee. См. products/cpmm/fees для инструкций сбора и отработанных числовых примеров.

SwapBaseInput (точный вход)

«Пользователь даёт нам ровно amount_in входного токена и получает как минимум minimum_amount_out выходного токена.» Игнорируя Token-2022 на момент:

amount_in_after_trade_fee = amount_in - trade_fee
amount_out                = y − (x * y) / (x + amount_in_after_trade_fee)

По алгебре:

\text{amount\_out} = \frac{y \cdot \Delta x_{\text{net}}}{x + \Delta x_{\text{net}}}

где Δx_net = amount_in_after_trade_fee. Затем программа обновляет учёт хранилища так, чтобы часть trade_fee, причитающаяся протоколу/фонду/создателю, находилась в бакетах «накопленных» (не включённых в следующий x кривой), в то время как доля LP присоединяется к x для следующего своп.

Token-2022 на входной стороне

Если входной токен имеет расширение комиссии передачи, токен вычитает свою комиссию при передаче от пользователя → хранилище. Таким образом, хранилище фактически получает amount_in − transfer_fee_in(amount_in). Программа CPMM поэтому вычисляет:

amount_actually_received = amount_in − transfer_fee_in(amount_in)
trade_fee                = ceil(amount_actually_received * trade_fee_rate / FEE_RATE_DENOMINATOR)
amount_in_after_trade_fee = amount_actually_received − trade_fee

и запускает кривую против amount_in_after_trade_fee. Это важно, потому что цена кривой вычисляется от чистой суммы, которая попала в хранилище, а не от объявленной суммы пользователя.

Token-2022 на выходной стороне

Если выходной токен имеет комиссию передачи, пул отправляет amount_out из своего хранилища пользователю. Токен затем снимет свою комиссию на выходе, поэтому пользователь получает amount_out − transfer_fee_out(amount_out). Программа вычисляет amount_out из кривой как обычно, но интегратор должен преобразовать число «отправка из хранилища» пула в число «получение пользователем» при отображении котировок.

Проверка проскальзывания

После вычисления amount_out:

require(amount_out >= minimum_amount_out, "AmountSpecifiedLessThanMinimum")

Если выходной токен берёт комиссию передачи, SDK применяет комиссию передачи перед установкой minimum_amount_out, чтобы константа проскальзывания была выражена в том, что пользователь фактически получит, а не в том, что отправит хранилище.

SwapBaseOutput (точный выход)

«Пользователь получит ровно amount_out выходного токена и готов заплатить до maximum_amount_in входного токена.» Инвертируя кривую для Δx_net:

\Delta x_{\text{net}} = \left\lceil \frac{x \cdot \text{amount\_out}}{y - \text{amount\_out}} \right\rceil

Потолок важен — он гарантирует k' ≥ k после целочисленного усечения. Затем:

// Работаем в обратном направлении от чистого входа к валовому входу.
// комиссия применяется к валовому, поэтому:
//   net = gross − ceil(gross * rate / D)
//       ≈ gross * (D − rate) / D
// инвертируя с потолком в правильных местах:
gross_needed = ceil(Δx_net * D / (D − trade_fee_rate))

На входе Token-2022 оберните:

gross_needed_before_mint_fee
  = inflate_for_transfer_fee(gross_needed, input_mint)

чтобы пользователь заплатил достаточно, чтобы после вычета комиссии передачи токена пул всё ещё получил gross_needed.

Проверка проскальзывания

require(gross_needed_before_mint_fee <= maximum_amount_in, "AmountSpecifiedExceedsMaximum")

Отработанный пример

Состояние пула, игнорируя Token-2022:

x = 1_000_000_000_000 (1 000 000,000000 token0, 6 десятичных)
y = 2_000_000_000_000 (2 000 000,000000 token1, 6 десятичных)
AmmConfig: trade_fee_rate = 2500, protocol_fee_rate = 120_000, fund_fee_rate = 40_000, creator_fee_rate = 0

Пользователь: SwapBaseInput с amount_in = 1_000_000_000 (1 000,000000 token0). Комиссия создателя отключена (enable_creator_fee = false).

trade_fee                = ceil(1_000_000_000 * 2500 / 1_000_000)       = 2_500_000
  protocol_fee           = floor(2_500_000 * 120_000 / 1_000_000)       = 300_000
  fund_fee               = floor(2_500_000 *  40_000 / 1_000_000)       = 100_000
  lp_fee                 = 2_500_000 − 300_000 − 100_000                 = 2_100_000
creator_fee              = 0                                              // отключена

amount_in_after_trade_fee = 1_000_000_000 − 2_500_000                    = 997_500_000

amount_out = y − (x * y) / (x + Δx_net)
           = 2_000_000_000_000
             − (1_000_000_000_000 * 2_000_000_000_000)
               / (1_000_000_000_000 + 997_500_000)
           = 1_993_011_971

new_vault0_raw   = x + amount_in                                        = 1_001_000_000_000
new_vault1       = y − amount_out                                       = 1_998_006_988_029

// Из 1_000_000_000 полученных в хранилище 0, 400_000 — это «накопленная комиссия»
// (протокол + фонд), которую кривая должна исключить:
curve_x          = new_vault0_raw − (protocol_fees_token0 + fund_fees_token0)
                 = 1_001_000_000_000 − 400_000
                 = 1_000_999_600_000

k' = curve_x * new_vault1 ≈ 2.000_004_196_E24  ≥  k = 2.0E24   ✓

Если бы тот же пул имел enable_creator_fee = true с creator_fee_rate = 1000 (0,10%) на входной стороне, программа взяла бы total_input_fee = ceil(1_000_000_000 * 3500 / 1_000_000) = 3_500_000, затем разделила бы её как creator_fee = 1_000_000 и trade_fee = 2_500_000. Арифметика протокола/фонда/LP на trade_fee не изменяется из примера выше — комиссия создателя — это отдельный бакет, накопленный в creator_fees_token0 и исключённый из curve_x вместе с бакетами протокола и фонда. Если входной токен имеет комиссию передачи Token-2022 в 1%, хранилище получит 990_000_000 токенов вместо 1_000_000_000, и все последующие вычисления используют эту чистую сумму.

Правило обновления наблюдения

На каждом своп программа оценивает, нужно ли добавить новое наблюдение в кольцевой буфер:

let since_last = now − observations[head].block_timestamp;
if since_last >= MIN_OBSERVATION_INTERVAL {
    let price0 = (vault1 << 32) / vault0;            // Q32.32-ish
    let price1 = (vault0 << 32) / vault1;
    let head' = (head + 1) % OBSERVATION_NUM;
    observations[head'] = Observation {
        block_timestamp: now,
        cumulative_token0_price_x32:
            observations[head].cumulative_token0_price_x32 + price0 * since_last,
        cumulative_token1_price_x32:
            observations[head].cumulative_token1_price_x32 + price1 * since_last,
    };
    head = head';
}

Два свойства:

Кумулятивная цена, не спотовая цена. Одно наблюдение — это не цена. Чтобы получить TWAP от времени t0 к t1, прочитайте наблюдения, ближайшие к каждому концу, и вычислите (cumulative(t1) − cumulative(t0)) / (t1 − t0).
Образцы ограничены по скорости. Последовательные своп в одном слоте могут использовать одно наблюдение. Чтение наблюдения сразу после своп может поэтому выглядеть устаревшим на один слот — это нормально.

Подробнее в products/clmm/accounts.

Комиссии на кривой

Это тонкая часть и стоит её выделить. Арифметика кривой работает против чистых балансов хранилища — то есть сырого баланса SPL минус накопленные комиссии протокола, фонда и создателя (все три — независимые бакеты — см. products/cpmm/fees). Конкретная картина:

raw_vault_balance   = что возвращает RPC getTokenAccountBalance
accrued_fees        = protocol_fees_token{0,1} + fund_fees_token{0,1} + creator_fees_token{0,1}
curve_balance       = raw_vault_balance − accrued_fees
invariant           = curve_balance0 * curve_balance1

Последствия для интеграторов:

Не котируйте от сырых балансов. Сначала вычтите поля накопленных комиссий, или вызовите SwapBaseInput как симуляцию и возьмите его результат.
CollectProtocolFee перемещает токены из хранилища. После сбора raw_vault_balance падает, но curve_balance не изменяется; цена пула не движется. Это намеренно.

Точность и переполнение

Вся арифметика кривой использует промежуточные значения u128 для предотвращения переполнения на x * y.
Деление округляется к нулю, кроме Δx_net в SwapBaseOutput, который округляется вверх, и вычисления комиссии, которое округляется вверх на trade_fee и вниз на подразделения. Эти направления округления выбраны так, чтобы инвариант никогда не уменьшался из-за целочисленного усечения.
Пулы с экстремальными соотношениями хранилищ (миллиарды : 1) могут столкнуться с полами точности на небольших сделках; программа возвращает ZeroTradingTokens в этом случае. См. reference/error-codes.

Куда дальше

products/cpmm/fees — полная семантика уровня комиссий и сбора.
products/cpmm/instructions — инструкции, которые вызывают эту математику.
algorithms/constant-product — вывод и граничные случаи x · y = k, общие для AMM v4 и CPMM.

Источники:

raydium-io/raydium-cp-swap — математика своп в states/curve.rs
Отчёты аудита Raydium, ссылки на которые находятся в security/audits

Продукты

Алгоритмы

Математика CPMM

Инвариант

Модель комиссий на пути своп

SwapBaseInput (точный вход)

Token-2022 на входной стороне

Token-2022 на выходной стороне

Проверка проскальзывания

SwapBaseOutput (точный выход)

Проверка проскальзывания

Отработанный пример

Правило обновления наблюдения

Комиссии на кривой

Точность и переполнение

Куда дальше

​Инвариант

​Модель комиссий на пути своп

​SwapBaseInput (точный вход)

​Token-2022 на входной стороне

​Token-2022 на выходной стороне

​Проверка проскальзывания

​SwapBaseOutput (точный выход)

​Проверка проскальзывания

​Отработанный пример

​Правило обновления наблюдения

​Комиссии на кривой

​Точность и переполнение

​Куда дальше

Инвариант

Модель комиссий на пути своп

SwapBaseInput (точный вход)

Token-2022 на входной стороне

Token-2022 на выходной стороне

Проверка проскальзывания

SwapBaseOutput (точный выход)

Проверка проскальзывания

Отработанный пример

Правило обновления наблюдения

Комиссии на кривой

Точность и переполнение

Куда дальше