رياضيات CLMM

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

هذه الصفحة عملية: فهي تقدم الصيغ والاتفاقيات ذات النقطة الثابتة والخطوات المستخدمة من قبل برنامج CLMM. للاطلاع على الأساس المنطقي وراء منحنى السيولة المركزة نفسه — لماذا L = sqrt(x · y) مهم — انظر algorithms/clmm-math. تفترض هذه الصفحة أنك قد قرأت ذلك.

تمثيل الجذر التربيعي للسعر

يخزن CLMM السعر كـ sqrt_price_x64 — الجذر التربيعي لسعر token1 لكل token0، كرقم نقطة ثابتة Q64.64:

\text{sqrt\_price\_x64} = \lfloor \sqrt{p} \cdot 2^{64} \rfloor

حيث p = token1_amount / token0_amount. العمل بـ sqrt بدلاً من p يخطي رياضيات المبادلة (تصبح دلتا مبالغ الرموز خطية في Δsqrt_price)، والنقطة الثابتة x64 تحافظ على الدقة عبر المبادلات متعددة التيك. يتم حساب تحويل التيك ↔ الجذر التربيعي للسعر مسبقًا عبر تقريب لوغاريتمي bit-by-bit:

\text{sqrt\_price\_x64}(t) \approx 2^{64} \cdot (1.0001)^{t/2}

مُنفذ كأس بحث عن الأس في tick_math::get_sqrt_price_at_tick.

السيولة كوحدة قانونية

داخل نطاق [sqrt_a, sqrt_b] (مع sqrt_a < sqrt_b)، موضع بـ سيولة L يُعيّن إلى مبالغ الرموز كما يلي. دع sqrt_c = sqrt_price_x64 يكون السعر الحالي للمجمع.

الحالة	`amount0`	`amount1`
`sqrt_c <= sqrt_a` (سعر المجمع أقل من النطاق)	`L · (sqrt_b - sqrt_a) / (sqrt_a · sqrt_b)`	`0`
`sqrt_a < sqrt_c < sqrt_b` (داخل النطاق)	`L · (sqrt_b - sqrt_c) / (sqrt_c · sqrt_b)`	`L · (sqrt_c - sqrt_a)`
`sqrt_c >= sqrt_b` (سعر المجمع أعلى من النطاق)	`0`	`L · (sqrt_b - sqrt_a)`

تأتي جميع الهويات الثلاث من الثابت x = L / sqrt_p، y = L · sqrt_p الذي تحققه السيولة المركزة داخل نطاق. عادة ما يريد المدمجون العكس: بالنظر إلى إيداع amount0 / amount1، احسب الحد الأقصى L الذي يناسب النطاق. يفعل SDK LiquidityMath.getLiquidityFromTokenAmounts هذا. الصيغة لحالة داخل النطاق:

L_0 = \text{amount0} \cdot \frac{\text{sqrt\_c} \cdot \text{sqrt\_b}}{\text{sqrt\_b} - \text{sqrt\_c}}, \qquad L_1 = \frac{\text{amount1}}{\text{sqrt\_c} - \text{sqrt\_a}}, \qquad L = \min(L_0, L_1)

أيهما يقيد يحدد النسبة المستهلكة فعليًا؛ قد يكون للجانب الآخر بقايا.

خطوة المبادلة أحادية التيك

تتقدم المبادلة في خطوات. كل خطوة إما (أ) تستهلك كل المدخلات المتاحة داخل نطاق التيك الحالي دون عبور تيك، أو (ب) تحرك السعر بالضبط إلى التيك المهيأ التالي. بالنظر إلى الحالة الحالية (sqrt_c, L) ومبادلة لأسفل (token0 داخل، token1 خارج، sqrt_price ينخفض — السعر مقتبس كـ token1/token0، لذا فإن إضافة token0 تخفضه)، التيك المهيأ التالي أدناه يجلس عند sqrt_t < sqrt_c. داخل هذا الفاصل الدقيق، العلاقة بين المدخلات والسعر هي:

\Delta\text{amount0} = L \cdot \left( \frac{1}{\text{sqrt\_t}} - \frac{1}{\text{sqrt\_c}} \right) = \frac{L \cdot (\text{sqrt\_c} - \text{sqrt\_t})}{\text{sqrt\_c} \cdot \text{sqrt\_t}}

\Delta\text{amount1} = L \cdot (\text{sqrt\_c} - \text{sqrt\_t})

مبادلة token1-in هي صورة معكوسة: sqrt_price يرتفع نحو التيك التالي أعلاه، والصيغتان تبدلان أي نقطة نهاية يتم طرحها. يشفر البرنامج الاتجاه كـ zero_for_one (true عندما يكون mint المدخلات token_mint_0)، ومبادلة zero_for_one تشد نحو MIN_SQRT_PRICE_X64. يفعل البرنامج أحد شيئين:

هل يناسب كل المدخلات؟ إذا كان المدخل المتبقي (بعد الرسم) أقل من Δamount0 للوصول إلى sqrt_t، حل للحصول على sqrt_c' الجديد بالضبط: $\text{sqrt\_c}' = \frac{L \cdot \text{sqrt\_c}}{L + \Delta\text{input} \cdot \text{sqrt\_c}}$ (لمبادلة token0 → token1 دقيقة المدخلات). تكتمل المبادلة في هذه الخطوة دون عبور تيك.
هل يتجاوز المدخل Δamount0؟ اضبط sqrt_c' = sqrt_t، عبر التيك (طبق liquidity_net)، قلل المدخل المتبقي بـ Δamount0، زد المخرجات بـ Δamount1، وكرر.

للاتجاه المعاكس (token1 → token0، السعر ينخفض)، الصيغ لها sqrt_c و sqrt_t مبدلة والعكس في الفتحة الأخرى. التنفيذ الكامل لـ Rust يعيش في raydium-clmm/programs/amm/src/libraries/swap_math.rs. المنطق هناك يطابق SwapMath.computeSwapStep لـ Uniswap v3 واحد لواحد.

الرسوم على كل خطوة

يتم أخذ رسوم التجارة من مبلغ المدخل في كل خطوة، نفس الاتفاقية مثل CPMM:

step_fee_amount  = ceil(step_input * trade_fee_rate / 1_000_000)
step_net_input   = step_input - step_fee_amount
protocol_portion = floor(step_fee_amount * protocol_fee_rate / 1_000_000)
fund_portion     = floor(step_fee_amount * fund_fee_rate     / 1_000_000)
lp_portion       = step_fee_amount - protocol_portion - fund_portion

يتم تقسيم حصة LP عبر السيولة المهيأة حاليًا بتحديث مراكم نمو الرسوم العام:

\text{fee\_growth\_global}_{\text{in}} \mathrel{+}= \text{lp\_portion} \cdot \frac{2^{64}}{L}

— أي أنها مقومة بـ رسوم لكل وحدة سيولة، Q64.64، بحيث يقرأ موضع بحجم L_i الذي بقي داخل النطاق عبر هذه المبادلة لاحقًا L_i · Δfee_growth_global / 2^{64} رموز مستحقة. تتراكم حصص البروتوكول والصندوق على PoolState.protocol_fees_token_{0,1} و PoolState.fund_fees_token_{0,1} على التوالي، مطابقة لـ CPMM. يتم مسحها بواسطة CollectProtocolFee / CollectFundFee.

نمو الرسوم خارج وداخل

الجزء الصعب من محاسبة رسوم CLMM: يكسب الموضع رسوم فقط بينما يكون سعر المجمع داخل نطاقه. يتتبع المجمع الرسوم التراكمية عالميًا؛ يحتاج الموضع إلى معرفة الرسوم التراكمية بينما داخل نطاقه المحدد. الحل هو مراكم قائم على التيك. يخزن كل تيك:

fee_growth_outside_0_x64
fee_growth_outside_1_x64

في لحظة تهيئة التيك:

إذا كان سعر المجمع أعلى من هذا التيك (tick_current >= this_tick)، fee_growth_outside = fee_growth_global. (كل ما تم كسبه حتى الآن هو “خارج” — أي أسفل — هذا التيك، بالنسبة للسعر الحالي.)
وإلا fee_growth_outside = 0.

عندما يعبر السعر تيك، يقلب البرنامج fee_growth_outside لذلك التيك:

\text{fee\_growth\_outside} \gets \text{fee\_growth\_global} - \text{fee\_growth\_outside}

الثابت الذي يحافظ عليه: لأي تيك t، fee_growth_outside(t) يساوي الرسوم التي تراكمت بينما كان tick_current على الجانب المعاكس من t. نمو الرسوم داخل نطاق [tick_lower, tick_upper] يُشتق بعد ذلك:

if tick_current >= tick_upper:
    fee_growth_below = fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_global - fee_growth_outside(tick_upper)
elif tick_current >= tick_lower:
    fee_growth_below = fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_outside(tick_upper)
else:
    fee_growth_below = fee_growth_global - fee_growth_outside(tick_lower)
    fee_growth_above = fee_growth_outside(tick_upper)

fee_growth_inside = fee_growth_global - fee_growth_below - fee_growth_above

هذه صيغة نمو الرسوم لـ Uniswap-v3، دون تغيير.

ما يخزنه الموضع وما يقرأه

يخزن PersonalPositionState fee_growth_inside_0_last_x64 و fee_growth_inside_1_last_x64: قيم fee_growth_inside في آخر مرة تم لمس الموضع فيها. في أي لمسة لاحقة (زيادة، تقليل، جمع)، يقوم البرنامج بـ:

حساب fee_growth_inside_{0,1}_x64 الحالي باستخدام الصيغة أعلاه.
حساب Δ = fee_growth_inside_now − fee_growth_inside_last (طرح معياري على u128).
إضافة Δ × position.liquidity / 2^{64} إلى tokens_fees_owed_{0,1}.
تحديث fee_growth_inside_last إلى القيمة الجديدة.

تتحرك الرموز فعليًا خارج الأقبية فقط على CollectFees / DecreaseLiquidity، مقابل tokens_fees_owed.

المكافآت

يستخدم كل من تدفقات المكافآت الثلاثة للمجمع نفس آلية النمو داخل، في مراكمه reward_growth_global_x64 الخاص. في وقت الانبعاث:

\text{reward\_growth\_global} \mathrel{+}= \text{emission\_per\_second} \cdot \Delta t \cdot \frac{2^{64}}{L}

— الانبعاثات تتناسب عكسيًا مع السيولة النشطة، لذا يدفع المجمع الأكثر كثافة لكل موضع أقل نسبيًا في الثانية، لكن على مواضع أكثر إجمالاً. المكافأة المستحقة لكل موضع هي

\text{reward\_owed} = (\text{reward\_growth\_inside}_{\text{now}} - \text{reward\_growth\_inside}_{\text{last}}) \cdot L / 2^{64}

ويتم دفعها بواسطة DecreaseLiquidity / DecreaseLiquidityV2 — لا توجد تعليمات جمع مكافآت مستقلة. انظر products/clmm/fees.

مثال عملي: مبادلة دقيقة المدخلات

افترض:

tick_spacing = 60
sqrt_price_x64 = 1 × 2^{64} — السعر = 1.0، لذا tick_current = 0.
السيولة النشطة L = 1_000_000 × 2^{64}.
التيك المهيأ التالي أدناه: t = −60 (sqrt_price_b ≈ 0.997005 × 2^{64}). مبادلة token0-in تتحرك لأسفل، لذا التيك أعلاه غير ذي صلة هنا.
معدل رسم التجارة: 500 (0.05%).

المستخدم: SwapBaseInput دقيق المدخلات 1,000 token0. الخطوة 1 — الرسوم:

trade_fee       = ceil(1000 * 500 / 1_000_000)  = 1
step_net_input  = 999

الخطوة 2 — هل 999 يناسب داخل نطاق التيك الحالي؟

Δ to next tick (amount0):
  L · (sqrt_c - sqrt_t) / (sqrt_c * sqrt_t)
  ≈ 1_000_000 · (1 − 0.997005) / (1 · 0.997005)
  ≈ 3004.4 token0

999 < 3004.4، لذا يناسب كل المدخل دون عبور التيك. الخطوة 3 — السعر الجديد:

sqrt_c' = L · sqrt_c / (L + Δin · sqrt_c)
        = 1_000_000 · 1 / (1_000_000 + 999 · 1)
        ≈ 0.999002

أي أن sqrt_c' يهبط قليلاً أقل من sqrt_c، وهو الاتجاه الصحيح: مبادلة token0 → token1 تضيف token0 إلى المجمع وبالتالي تخفض سعر token1/token0. الخطوة 4 — مبلغ المخرجات:

Δout token1 = L · (sqrt_c − sqrt_c')
            = 1_000_000 · 0.000998
            ≈ 998.00

بعد حساب التقريب، يتلقى المستخدم ≈ 998 token1. يتم تقسيم الرسم (1 token0) بين LP والبروتوكول والصندوق بـ trade_fee_rate × protocol_fee_rate / 1e6 (وبالمثل للصندوق)؛ تتدفق حصة LP إلى fee_growth_global_0_x64.

مطابقة أوامر الحد أثناء المبادلة

عندما تعبر خطوة مبادلة تيك يحتوي على أوامر حد مفتوحة، تستهلك تلك الأوامر مدخل المبادلة قبل منحنى LP، بسعر التيك بالضبط. المطابقة هي FIFO داخل التيك بـ order_phase cohort.

حالة لكل cohort على `TickState`

order_phase                  : u64    monotonic cohort id
orders_amount                : u64    input-token total in the current (newest) cohort
part_filled_orders_remaining : u64    remaining input of the cohort that swap is currently filling
unfilled_ratio_x64           : u128   Q64.64 fill ratio for the partially-filled cohort

تكون تخطيط cohort الثنائي موجودة لأن أوامر جديدة قد تُفتح على تيك بينما cohort أقدم لا يزال يتم ملؤه. تنضم الأوامر المفتوحة حديثًا إلى orders_amount وترث order_phase التالي؛ لا يمكنها الملء حتى يتم استهلاك cohort السابق بالكامل.

خطوة المطابقة

pseudo-code للمطابقة التي تحدث عند كل عبور تيك أثناء المبادلة:

fn match_limit_orders_at_tick(tick, swap_input_remaining, sqrt_p):
    # 1. Try to fill the partially-filled cohort first.
    if tick.part_filled_orders_remaining > 0:
        consume = min(tick.part_filled_orders_remaining, swap_input_remaining)
        # Update the unfilled-ratio for that cohort.
        tick.unfilled_ratio_x64 *= (1 - consume / tick.part_filled_orders_remaining)
        tick.part_filled_orders_remaining -= consume
        swap_input_remaining -= consume
        if tick.part_filled_orders_remaining == 0:
            tick.unfilled_ratio_x64 = 0
        if swap_input_remaining == 0: return

    # 2. Promote the active cohort.
    if tick.orders_amount > 0:
        tick.part_filled_orders_remaining = tick.orders_amount
        tick.orders_amount = 0
        tick.order_phase += 1
        tick.unfilled_ratio_x64 = ONE_X64
        # Recurse with the freshly-promoted cohort.
        return match_limit_orders_at_tick(tick, swap_input_remaining, sqrt_p)

    return  # tick has no more limit orders

رموز المخرجات التي تذهب إلى مالكي أوامر الحد لا يتم نقلها لكل مبادلة. تجلس فعليًا في قبو المخرجات للمجمع حتى يستدعي مالك الأمر SettleLimitOrder (أو DecreaseLimitOrder). يتتبع المجمع ببساطة مقدار cohort الذي تم ملؤه الآن عبر unfilled_ratio_x64. يخزن كل LimitOrderState لقطة (order_phase, unfilled_ratio_x64) الخاصة به في وقت الفتح، لذا يقلل التسوية إلى:

filled_amount  = total_amount × (1 − tick_now.unfilled_ratio_x64 / order.unfilled_ratio_x64)
                if tick_now.order_phase > order.order_phase
                else 0
output_amount  = price_at(tick_index) × filled_amount   # adjusted for direction

هذا التسوية O(1) هي النقطة كاملة من تصميم cohort — يمكن لتيك ملء أوامر عديدة بشكل تعسفي دون غاز لكل أمر.

التفاعل مع منحنى LP

في خطوة مبادلة، تحدث مطابقة أوامر الحد عند التيك (صفر Δsqrt_price)؛ استهلاك منحنى LP يحدث بين التيكات. الترتيب بالتالي:

عبور التيك t_cross (طبق تغيير LP liquidity_net أولاً، لأن هذا كيف يفعله Uniswap-V3).
ملء أي أوامر حد جالسة عند t_cross.
المتابعة على طول منحنى LP إلى التيك المهيأ التالي أو إلى استنزاف swap_input.

وبالتالي تعطي أوامر الحد للمتداولين سيولة فعالة أكثر بالضبط بسعر أمر التيك (تأثير تحسين السعر)، على حساب LPs عدم كسب رسوم على تلك الحصة من حجم المبادلة — حصة أمر الحد من التجارة خالية من الرسوم للمتداول، لأن مُنشئ أمر الحد يعمل كصانع. لا تزال الزيادة الرسوم الديناميكية (إن كانت مفعلة) تنطبق على حصة LP من نفس المبادلة.

اشتقاق الرسوم الديناميكية

يحمل PoolState.dynamic_fee_info حالة التقلب. تحسب كل خطوة مبادلة معدل الرسم لكل خطوة كـ:

\text{fee\_rate}_{\text{total}} = \text{trade\_fee\_rate}_{\text{config}} + \underbrace{\frac{\text{dynamic\_fee\_control} \cdot (\text{vol\_acc} \cdot \text{tick\_spacing})^2} {D_{\text{ctrl}} \cdot S_{\text{vol}}^2}}_{\text{dynamic surcharge}}

حيث:

$D_{\text{ctrl}} = 100{,}000$ — DYNAMIC_FEE_CONTROL_DENOMINATOR
$S_{\text{vol}} = 10{,}000$ — VOLATILITY_ACCUMULATOR_SCALE
vol_acc هو مراكم لكل مبادلة بعد قاعدة التحديث أدناه
tick_spacing من PoolState.tick_spacing

يتم تشديد النتيجة عند

100{,}000 / 10^6 = 10\%

تحديث المراكم

يتم تطبيق قاعدتين لكل مبادلة، بالترتيب: الاضمحلال. يتحلل الحد المرجعي بناءً على الوقت منذ آخر تحديث:

\text{vol\_ref} = \begin{cases} 0 & \text{if } \Delta t > \text{decay\_period} \\ \text{vol\_acc}_{\text{prev}} \cdot \dfrac{\text{reduction\_factor}}{10{,}000} & \text{if } \text{filter\_period} < \Delta t \le \text{decay\_period} \\ \text{vol\_ref}_{\text{prev}} & \text{if } \Delta t \le \text{filter\_period} \end{cases}

التراكم. المراكم الجديد هو المرجع بالإضافة إلى مسافة التيك المقطوعة منذ فهرس المرجع السابق:

\text{vol\_acc} = \min\left( \text{vol\_ref} + \left| t_{\text{ref}} - t_{\text{now}} \right| \cdot S_{\text{vol}}, \text{max\_vol\_acc} \right)

tick_spacing_index_reference (

t_{\text{ref}}

) بوحدات tick-spacing، وليس التيكات الخام:

t_{\text{ref}} = \lfloor \text{tick\_current} / \text{tick\_spacing} \rfloor

لماذا مكافئ في مسافة التيك

تربيع المراكم يعني أن الرسم يرتفع كـ مربع كم بعيد السعر قد مشى بعيدًا عن نقطة مرجعه. تجريبيًا هذا يطابق تحجيم التباين للسعر تحت ضغط المشي العشوائي: إثارة تيك 2× تعني 4× التقلب الضمني، لذا تفرض 4× الزيادة. معامل dynamic_fee_control يعاير المستوى المطلق. نافذة filter_period تمنع تذبذبات صغيرة دون الثانية (مثلاً، بوتات MEV sandwiching) من تضخيم المراكم. نافذة decay_period تمنع ارتفاع واحد في الماضي من فرض رسوم إلى الأبد بعد أن يكون السوق قد هدأ.

المتانة العددية

جميع المنتجات الوسيطة تمر عبر حسابات u128 أو u256. يستخدم CLMM مساعدات U128Sqrt وأنماط FullMath::mulDiv المنقولة مباشرة من Uniswap v3.
يتم اختيار تقريب القسمة لكل خطوة لفرض الثابت k' ≥ k محليًا. SwapBaseInput يقرب المخرجات لأسفل؛ SwapBaseOutput يقرب المدخلات لأعلى.
عبور التيكات التي تسقط PoolState.liquidity إلى صفر مسموحة (السعر يمكن أن يعبر “حفرة سيولة”) لكن المبادلة ببساطة تتقدم إلى التيك المهيأ التالي دون استهلاك مدخل، دون فرض رسم.
حماية الفيضان: يتم الاحتفاظ بـ sqrt_price_x64 في النطاق الشامل [MIN_SQRT_PRICE_X64, MAX_SQRT_PRICE_X64] المقابل لـ [MIN_TICK, MAX_TICK]. مبادلة قد تدفع ماضي أي حد ترجع مع SqrtPriceLimitOverflow.

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

products/clmm/ticks-and-positions لكيفية مشاركة خريطة التيك في المشي.
products/clmm/fees لجانب الرسم/المكافأة من الرياضيات بالتفصيل.
algorithms/clmm-math للاشتقاقات وراء L = sqrt(x · y) وصيغ النطاق مقابل السيولة.

المصادر:

raydium-io/raydium-clmm — libraries/swap_math.rs, libraries/tick_math.rs
“Uniswap v3 Core” whitepaper، §6–7

Products

Algorithms

تمثيل الجذر التربيعي للسعر

السيولة كوحدة قانونية

خطوة المبادلة أحادية التيك

الرسوم على كل خطوة

نمو الرسوم خارج وداخل

ما يخزنه الموضع وما يقرأه

المكافآت

مثال عملي: مبادلة دقيقة المدخلات

مطابقة أوامر الحد أثناء المبادلة

حالة لكل cohort على `TickState`

خطوة المطابقة

التفاعل مع منحنى LP

اشتقاق الرسوم الديناميكية

تحديث المراكم

لماذا مكافئ في مسافة التيك

المتانة العددية

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

​تمثيل الجذر التربيعي للسعر

​السيولة كوحدة قانونية

​خطوة المبادلة أحادية التيك

​الرسوم على كل خطوة

​نمو الرسوم خارج وداخل

​ما يخزنه الموضع وما يقرأه

​المكافآت

​مثال عملي: مبادلة دقيقة المدخلات

​مطابقة أوامر الحد أثناء المبادلة

​حالة لكل cohort على TickState

​خطوة المطابقة

​التفاعل مع منحنى LP

​اشتقاق الرسوم الديناميكية

​تحديث المراكم

​لماذا مكافئ في مسافة التيك

​المتانة العددية

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

تمثيل الجذر التربيعي للسعر

السيولة كوحدة قانونية

خطوة المبادلة أحادية التيك

الرسوم على كل خطوة

نمو الرسوم خارج وداخل

ما يخزنه الموضع وما يقرأه

المكافآت

مثال عملي: مبادلة دقيقة المدخلات

مطابقة أوامر الحد أثناء المبادلة

حالة لكل cohort على `TickState`

خطوة المطابقة

التفاعل مع منحنى LP

اشتقاق الرسوم الديناميكية

تحديث المراكم

لماذا مكافئ في مسافة التيك

المتانة العددية

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