رياضيات CPMM

هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →

الثابت

يحافظ CPMM على ثابت الناتج الثابت الكلاسيكي على خزانتيه:

x \cdot y = k

حيث x هو رصيد vault0 بعد أي رسوم نقل Token-2022 عند الاستقبال، وبالمثل لـ y. يجب أن يترك كل مبادلة k' ≥ k بعد احتساب رسوم التداول المرصودة للـ LP (لا تُحسب دلاء البروتوكول والصندوق والمنشئ نحو k — فهي موجودة في الخزان لكن مستثناة من عرض المنحنى، انظر الرسوم على المنحنى أدناه). لذلك ينمو k بشكل رتيب بمرور الوقت مع تراكم الرسوم لدى LPs. يتم تسعير حصص 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، يستخدم أرصدة الخزان ناقص جميع الرسوم الثلاثة المتراكمة غير المجمعة — لذا يلتقط LPs فقط 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 المستقبلة في vault0، 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   = ما يعيده getTokenAccountBalance من RPC
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

Products

Algorithms

الثابت

نموذج الرسوم على مسار المبادلة

SwapBaseInput (إدخال دقيق)

Token-2022 على جانب الإدخال

Token-2022 على جانب الإخراج

فحص الانزلاق

SwapBaseOutput (إخراج دقيق)

فحص الانزلاق

مثال معمول

قاعدة تحديث الملاحظة

الرسوم على المنحنى

الدقة والفيض

أين تذهب بعد ذلك

​الثابت

​نموذج الرسوم على مسار المبادلة

​SwapBaseInput (إدخال دقيق)

​Token-2022 على جانب الإدخال

​Token-2022 على جانب الإخراج

​فحص الانزلاق

​SwapBaseOutput (إخراج دقيق)

​فحص الانزلاق

​مثال معمول

​قاعدة تحديث الملاحظة

​الرسوم على المنحنى

​الدقة والفيض

​أين تذهب بعد ذلك

الثابت

نموذج الرسوم على مسار المبادلة

SwapBaseInput (إدخال دقيق)

Token-2022 على جانب الإدخال

Token-2022 على جانب الإخراج

فحص الانزلاق

SwapBaseOutput (إخراج دقيق)

فحص الانزلاق

مثال معمول

قاعدة تحديث الملاحظة

الرسوم على المنحنى

الدقة والفيض

أين تذهب بعد ذلك