هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
products/clmm/accounts (ما هي الحسابات) و products/clmm/math (ما هي الرياضيات). وهي مرجع معتمد للمعاملات وترتيب الحسابات؛ تأتي تخطيطات البايت المحددة من IDL.
جرد التعليمات
لا توجد تعليمة لتهيئة مصفوفة التكات، ولا حاجة إليها. تُنشأ مصفوفة التكات داخل
OpenPosition* / IncreaseLiquidity* بواسطة TickArrayState::get_or_create_tick_array، ويدفع
ثمنها payer. مرّر PDA مصفوفة التكات (وقد يكون غير مُهيّأ بعد ومملوكًا للنظام) كـ
tick_array_lower / tick_array_upper ويخصّصه البرنامج إن كان مفقودًا. وتفعل OpenLimitOrder
الشيء ذاته لمصفوفة tick_array الوحيدة الخاصة بها.CreateAmmConfig, UpdateAmmConfig, UpdatePoolStatus, CreateOperationAccount, UpdateOperationAccount, CloseProtocolPosition) يتم التحكم فيها بواسطة admin pubkey المشفر في البرنامج. CreatePermissionPda / ClosePermissionPda تقبل إما admin pubkey أو مفتاح permission_pda_admin مخصص؛ وCreateSupportMintAssociated / CloseSupportMintAssociated تقبلان إما admin pubkey أو مفتاح مالك عملة الدعم المخصص. تعليمات إدارة تدفق المكافآت (TransferRewardOwner, CollectRemainingRewards) يتم التحكم فيها بواسطة ممول المكافآت، وليس إدارة البرنامج.
لاحقة V2 تعني “يدعم Token-2022 على الأقبية / NFT، يتطلب فتحة امتداد bitmap”. يختار SDK V2 بشكل افتراضي للمجمعات الجديدة.
CreatePool
المعاملات
الشروط المسبقة
token_mint_0 < token_mint_1حسب ترتيب البايت.amm_config.disable_create_pool == false.- لا يتم رفض Mints بواسطة قائمة السماح بامتداد Token-2022.
pool_state.sqrt_price_x64 = sqrt_price_x64,tick_current = floor(log_{1.0001}(price)).pool_state.liquidity = 0(لا توجد مراكز حتى الآن).pool_state.fee_on = FromInput(الافتراضي القديم).pool_state.dynamic_fee_infoمصفر (الرسوم الديناميكية معطلة).
CreateCustomizablePool
موصى به للمجمعات الجديدة. نفس تأثير CreatePool بالإضافة إلى وضع جمع الرسوم لكل مجمع وعلم اختياري لتفعيل الرسوم الديناميكية.
المعاملات
CreatePool. وdynamic_fee_config ليس حسابًا مُعلَنًا.
الشروط المسبقة — نفس CreatePool. إذا كان enable_dynamic_fee = false، فلا حاجة إلى أي remaining_account، وأي حسابات تُمرَّر تُفحص فقط بحثًا عن سجلات عملات الدعم.
الشروط اللاحقة
pool_state.fee_onتم تعيينه إلى متغيرCollectFeeOnالمختار.- إذا تم تفعيل الرسوم الديناميكية: يتم تهيئة
pool_state.dynamic_fee_infoمنDynamicFeeConfigالمرسل (خمسة معاملات معايرة مسخوخة؛ حقول الحالة مصفرة). - وإلا:
pool_state.dynamic_fee_infoمصفر (= الرسوم الديناميكية غير نشطة إلى الأبد لهذا المجمع).
fee_on وبت تفعيل الرسوم الديناميكية فقط عند إنشاء المجمع. لا توجد ترقية في المكان — المجمعات التي تم إنشاؤها عبر CreatePool القديم لا يمكنها الحصول على رسوم ديناميكية أو رسوم أحادية الجانب بأثر رجعي. يجب أن تستخدم النشرات الجديدة هذه التعليمة بشكل افتراضي.
CreatePermissionedPool
كل من CreatePool و CreateCustomizablePool يشتقان PDA المجمع من ["pool", amm_config, token_mint_0, token_mint_1]، لذا يوجد بالضبط مجمع قانوني واحد لكل ثلاثية (config, mint0, mint1) — محاولة init ثانية بنفس البذور تفشل. CreatePermissionedPool يرفع هذا التقييد بطي seed_index: u16 يوفره العميل في بذور PDA المجمع، مما يسمح بـ مجمعات متعددة لنفس الزوج وفئة الرسوم — كل واحد في عنوانه الخاص. لأن عنوان مجمع تعسفي هو قدرة مميزة، يجب أن يحتفظ الدافع بـ Permission PDA يفوضه.
كل شيء آخر عن المجمع متطابق مع CreateCustomizablePool: يأخذ نفس CreateCustomizableParams ويدعم الرسوم أحادية الجانب وخيار الرسوم الديناميكية.
المعاملات
CreateCustomizablePool بالإضافة إلى، في الأمام:
يتم اشتقاق
pool_state PDA من ["pool", amm_config, token_mint_0, token_mint_1, seed_index.to_le_bytes()].
الشروط المسبقة
seed_index != 0.seed_indexمن0محجوز للمجمعات القديمة ويتم رفضه هنا؛ مكون البذرة[0, 0]هو ما يجعل عنوان المجمع القديم ينهار إلى شكل البذور الأربع الكلاسيكي.permissionPDA لـpayerموجود (تم إنشاؤه بواسطة إداري عبرCreatePermissionPda).- نفس قواعد mint / allow-list مثل
CreatePool.
pool_stateجديد موجود في عنوان مشتق منseed_index، معpool_state.seed_index = seed_index.- جميع حالات ما بعد الأخرى تطابق
CreateCustomizablePool(وضع الرسوم، الرسوم الديناميكية الاختيارية).
هذه التعليمة لا توسع الوصول العام لإنشاء المجمع — الإنشاء بدون إذن يستمر عبر
CreatePool / CreateCustomizablePool، والتي تبقى مجمع واحد لكل زوج. CreatePermissionedPool موجود للحالة المحددة حيث يحتاج مشغل مدرج في القائمة البيضاء إلى عدة مجمعات لنفس الزوج (على سبيل المثال، أسعار أولية مختلفة أو مجموعات إطلاق) ويحتفظ بـ Permission PDA منحه الإداري.OpenPositionV2 / OpenPositionWithToken22Nft
إنشاء موضع جديد داخل مجمع موجود.
المعاملات
OpenPositionWithToken22Nft هي القائمة نفسها مع حذف metadata_account (5) و metadata_program (19) — إذ تكتب بيانات المركز الوصفية عبر امتداد البيانات الوصفية في Token-2022 على mint الـ NFT بدلاً من ذلك — ما يعطي 20 حسابًا. وposition_nft_mint فيها هو Signer مجرد وposition_nft_account هو UncheckedAccount.
الرياضيات — انظر products/clmm/math. بالنظر إلى base_flag، يحل البرنامج إما liquidity أو (amount_0_max, amount_1_max) إلى L الفعلي والمبالغ الفعلية للرموز المستهلكة.
الشروط المسبقة
tick_lower < tick_upper، كلاهما مضاعفاتpool.tick_spacing، ضمن[MIN_TICK, MAX_TICK].- يتم تمرير PDAs مصفوفتَي التكات. ولا يلزم أن تكون موجودة بالفعل — إذ يخصّص
get_or_create_tick_arrayالمصفوفة المفقودة على حسابpayerداخل هذه التعليمة. لا توجد تعليمة منفصلة لتهيئة مصفوفة التكات. - المستخدم لديه على الأقل
amount_0_maxوamount_1_maxفي ATAs المصدر.
personal_positionموجود،liquidityتم تعيينه،fee_growth_inside_lastتم التقاطه.- إدخالات مصفوفة العلامات في
tick_lowerوtick_upperتم تحديثها (liquidity_gross += L,liquidity_net ± L، لقطات نمو الرسوم يتم الحفاظ عليها). pool_state.liquidity += Lإذا كان الموضع في النطاق (tick_lower ≤ tick_current < tick_upper).- صك NFT للموضع يسجل
pool_stateكسلطة تجميد. يتم إزالة سلطة الصك بعد صك NFT الواحد. تسجيل سلطة التجميد لا يغير حالة حساب رمز NFT. - يبقى حساب رمز NFT غير مجمد ما لم تكن التعليمة
OpenPositionV2أوOpenPositionWithToken22Nftو تطابق سلطة تجميد أي vault mint قائمة المُصدرين المقيدين لـ CLMM. فقط مسار V2 المطابق هذا يجمد الحساب.OpenPositionV1 لا يجمد.
TickInvalidOrder (tick_lower >= tick_upper)، TickAndSpacingNotMatch (أحد الطرفين ليس مضاعفًا لـ tick_spacing)، InvalidTickIndex (خارج [MIN_TICK, MAX_TICK])، MissingTickArrayBitmapExtensionAccount (النطاق خارج الخريطة النقطية المضمّنة ولم يُضَف الامتداد)، NotApproved (pool_state.status يمنع الفتح)، ZeroAmountSpecified.
تجميد الموضع لا يضيف حسابات تعليمات معلنة أو معاملات. يمكن للعملاء فتح هذه المراكز مع تخطيطات V2 الموجودة. يتم اختيار السلوك على السلسلة من
vault_0_mint و vault_1_mint.IncreaseLiquidityV2
إضافة السيولة إلى موضع مفتوح بالفعل.
المعاملات
OpenPosition: فلا يوجد rent، ولا system_program، ولا associated_token_program، ولا حساب بيانات وصفية.
أضِف PDA الخاص بـ
TickArrayBitmapExtension في مقدمة القائمة كـ remaining_accounts[0] عندما يكون نطاق المركز خارج الخريطة النقطية المضمّنة.
التأثير
- ينقل
amount_0_actual/amount_1_actualمن المستخدم → الأقبية. - يزيد
personal_position.liquidityوpool_state.liquidity(إذا كان في النطاق)، وبناءً على ذلكliquidity_gross/liquidity_netللعلامة النهائية. - يجمع الرسوم والمكافآت المستحقة منذ آخر لمسة ويعتمدها على
token_fees_owed_{0,1}/reward_amount_owed. ولا تُدفع هذه إلا علىDecreaseLiquidity/DecreaseLiquidityV2، وليس على الزيادة — فلا توجد تعليمة تحصيل مستقلة.
DecreaseLiquidityV2
إزالة السيولة من موضع.
المعاملات
IncreaseLiquidityV2: فـ personal_position و pool_state متبادلان، والخزائن تأتي قبل مصفوفات التكات، وحسابات جانب المستخدم تُسمى recipient_token_account_*، وهناك memo_program إضافي.
الحسابات المتبقية — ثلاثة لكل مكافأة نشطة يتم جمعها، بالترتيب
reward_token_vault(W) و recipient_token_account(W) و reward_vault_mint. أضِف PDA الخاص بـ TickArrayBitmapExtension في المقدمة عندما يكون نطاق المركز خارج الخريطة النقطية المضمّنة.
هذه أيضًا هي الطريقة الوحيدة لجمع الرسوم والمكافآت. ولجمعها دون تغيير المركز، استدعِها بـ
liquidity = 0 و amount_0_min = 0 و amount_1_min = 0.- يحسب
(amount_0, amount_1)للـLالمزال بالنظر إلىsqrt_price_x64الحالي. - يسوي الرسوم/المكافآت المتراكمة منذ آخر لمسة، نفس
IncreaseLiquidity. - ينقل
amount_0 + fees_owed_0وamount_1 + fees_owed_1خارج الأقبية إلى المستخدم. - يقلل عدادات السيولة؛ إذا كان
personal_position.liquidity == 0الجديد، يكون الموضع مؤهلاً لـClosePosition.
amount_0_min و amount_1_min هما الحد الأدنى الذي يقبله المستخدم بعد خصم رسوم نقل Token-2022 على جانب الإخراج.
ClosePosition
حرق NFT الموضع وإغلاق PersonalPositionState.
الحسابات المعلنة
الحسابات المتبقية
- NFT غير مجمد: لا يوجد مطلوب؛ حساب مجمع إضافي غير ضار لأن المعالج لا يقرأه.
- NFT مجمد: أضف
personal_position.pool_idكأول حساب متبقي. يحمل البرنامج كـPoolStateويستخدم بذور PDA الخاصة به للتوقيع على الإذابة.
personal_position.liquidity == 0.tokens_fees_owed_{0,1} == 0.- جميع عدادات المكافآت
reward_amount_owed == 0.
- إذا كان حساب رمز NFT مجمدًا، تحقق من أن أول حساب متبقي يساوي
personal_position.pool_id، ثم أذبه باستخدام PDA المجمع. - حرق NFT.
- أغلق حساب رمز NFT و
personal_position، مع استرجاع الإيجار إلىnft_owner. إذا كان موضع NFT يستخدم Token-2022، فإنه يغلق أيضًا صك NFT؛ لا يمكن إغلاق صك SPL Token الكلاسيكي ويبقى مع إمداد صفر.
AccountLack عند إغلاق موضع مجمد. تمرير المجمع لكل إغلاق هو أبسط استراتيجية متوافقة.
SwapV2
المشي على منحنى السيولة؛ إدخال دقيق أو إخراج دقيق حسب is_base_input.
المعاملات
يمرر المستدعون قائمة مرتبة من مصفوفات العلامات التي تغطي مشي المبادلة المتوقع؛ يستخدم البرنامج ما يحتاجه. يحسب SDK هذه القائمة عبر
PoolUtils.computeAmountOutFormat أو نقطة نهاية الاقتباس للـ API.
الشروط المسبقة
pool_state.statusيسمح بالمبادلة.now >= open_time.sqrt_price_limit_x64على الجانب الصحيح منsqrt_price_x64للاتجاه.
TooLittleOutputReceived (انزلاق exact-in)، TooMuchInputPaid (انزلاق exact-out)، SqrtPriceLimitOverflow، NotEnoughTickArrayAccount، InvalidFirstTickArrayAccount، MissingTickArrayBitmapExtensionAccount، LiquidityInsufficient، NotApproved (بت المبادلة مضبوط على pool_state.status). لا يوجد في CLMM متغير ExceededSlippage — فذلك الاسم خاص بـ CPMM — ولا TickArrayNotFound.
ما الذي يفعله SwapV2 داخليًا والذي يجب على المستدعين معرفته (إصدار ما بعد 2025):
- رسوم ديناميكية إضافية — إذا كان
pool.dynamic_fee_infoغير صفري، يحدث البرنامج مراكم التقلب باستخدام مسافة العلامة المقطوعة منذ آخر مبادلة (مع قواعد التصفية/الاضمحلال منproducts/clmm/fees) ويضيفdynamic_fee_componentعلى رأسAmmConfig.trade_fee_rate. إجمالي الرسوم مغطى بـ 10% (MAX_FEE_RATE_NUMERATOR / 1_000_000). - مطابقة أوامر الحد — عندما يعبر مشي السعر علامة تحتفظ بأوامر حد مفتوحة، يملأ البرنامج أولاً سيولة أوامر الحد المتاحة في تلك العلامة (FIFO حسب
order_phase)، ثم يتابع على منحنى سيولة LP. تحديث المبالغ المملوءةtick.unfilled_ratio_x64وtick.part_filled_orders_remainingللتسوية لاحقًا؛ تبقى الأوامر نفسها غير منفقة حتى يستدعي مالكهاSettleLimitOrder. - توجيه الرسوم أحادي الجانب — عندما
pool.fee_on = Token0OnlyأوToken1Only، خطوة المبادلة لا تزال تحسب نفس تجارة الإدخال-الإخراج؛ يتم بعد ذلك توجيه الرسوم إلى الجانب المكون. للاتجاهات حيث جانب الرسوم المكون هو الإخراج، يتم خصم الرسوم من إخراج المبادلة (يتلقى المستخدمout − fee)؛ للاتجاهات حيث يكون الإدخال، السلوك يطابقFromInput. انظرis_fee_on_input(zero_for_one)وis_fee_on_token0(zero_for_one)علىPoolState.
Swap (V1) ينفذ نفس الرسوم الديناميكية وتوجيه الرسوم أحادي الجانب ومطابقة أوامر الحد مثل SwapV2؛ الميزة الوحيدة التي ينقصها هي دعم Token-2022 — يجب أن تكون كلا الأقبية SPL Token كلاسيكي. المجمعات التي تحتوي على أي mint Token-2022 يجب أن تتم مبادلتها عبر SwapV2. المجمع والـ SDK يفضلان بالفعل V2 لكل ساق CLMM لذا لا يضطر المستدعون إلى الفرع على نوع mint.
OpenLimitOrder
ضع أمر بيع في علامة محددة. يجلس الأمر في مجموعة FIFO لكل علامة ويملأ عندما يمشي السعر.
المعاملات
الحسابات المتبقية —
[0] tick_array_bitmap_extension، مطلوب فقط عند تهيئة مصفوفة تكات يقع مؤشر بدايتها خارج الخريطة النقطية المضمّنة في المجمع. لا تمرّر شيئًا غير ذلك.
تغيير قائمة الحسابات (إصدار 2026-07).
OpenLimitOrder يأخذ الآن أيضًا حسابات جانب الإخراج — output_token_account, output_vault, و output_vault_mint — بالإضافة إلى جانب الإدخال. يتم استخدامها فقط للتحقق: يرفض البرنامج الأمر إذا كان حساب رمز الإدخال أو الإخراج للمالك مجمدًا. هذا يضمن أن الملء يمكن فعلاً أن يتم تسويته إلى ATA الإخراج للمالك، وهو مهم لـ allow-list / default-frozen Token-2022 mints (على سبيل المثال، الرموز المرخصة) حيث قد لا يكون الحساب مذابًا بعد. يجب على العملاء المبنيين مقابل قائمة الحسابات أحادية الجانب الأقدم إضافة الحسابات الثلاثة للإخراج.- لا
input_token_accountولاoutput_token_accountمجمد (وإلاNotApproved). pool_state.statusيسمح بكل من عمليات المبادلة (بت 4) وأوامر الحد (بت 5) (وإلاNotApproved).tick_index % pool.tick_spacing == 0وضمن[MIN_TICK, MAX_TICK].tick_indexعلى الجانب الأيمن منpool.tick_currentللاتجاه المختار (بيع token0 → يجب أن تكون العلامة فوق الحالية، والعكس صحيح). البيع في علامة تم عبورها بالفعل سيتم مطابقته فورًا ويتم رفضه.
limit_orderموجود، التقاطtick.order_phaseوtick.unfilled_ratio_x64في وقت الفتح.tick.orders_amount += amount(في المجموعة الحالية).limit_order_nonce.order_nonce += 1.OpenLimitOrderEventمُصدر.
NotApproved (حساب رمز الإدخال أو الإخراج مجمد، أو المجمع لديه مبادلة / أوامر حد معطلة)، ZeroAmountSpecified (amount == 0 بعد رسم النقل على جانب الإدخال)، InvalidLimitOrderAmount (المبلغ سينتج مخرجًا أقل من وحدة أساس واحدة عند تلك التكة، أو يتجاوز u64)، InvalidTickIndex (خارج [MIN_TICK, MAX_TICK]، أو على الجانب الخاطئ من tick_current للاتجاه المختار)، TickAndSpacingNotMatch (tick_index % pool.tick_spacing != 0)، OrderPhaseSaturated.
IncreaseLimitOrder
إضافة إلى أمر مفتوح موجود. يمكن استدعاؤها فقط من قبل owner الأمر.
المعاملات
system_program.
الشروط المسبقة
limit_order.owner == signer.- الأمر لا يزال في نفس المجموعة (
tick.order_phase == limit_order.order_phase). إذا بدأت المجموعة بالفعل بالملء، يتم تسوية الأمر جزئيًا — يجب على المستدعي استدعاءDecreaseLimitOrderأوSettleLimitOrderأولاً للمتابعة.
- ينقل
amountمن ATA المالك إلىinput_vault. limit_order.total_amount += amount؛tick.orders_amount += amount.
DecreaseLimitOrder
تقليل أو إلغاء كامل أمر مفتوح. يدفع الباقي غير المملوء مرة أخرى إلى المالك، بالإضافة إلى أي إخراج تم تسويته بالفعل بواسطة ملء جزئي سابق.
المعاملات
التأثير
- يعيد حساب مبلغ الملء للأمر من
unfilled_ratio_x64للمجموعة منذ الفتح. - يرسل الإخراج المملوء إلى
output_token_account. - يرسل
amountمن الإدخال غير المملوء مرة أخرى إلىinput_token_account. - يحدث
limit_orderوفقًا لذلك. إذا كان الباقي غير المملوء الجديد صفرًا، يغلق البرنامج الحساب ويسترجع الإيجار إلىowner.
SettleLimitOrder
دفع رموز الإخراج المملوءة إلى المالك دون تغيير الباقي غير المملوء للأمر. مفيد عندما يريد حراس auto_withdraw تقطير الملء الجزئي طويل الأمد.
المستدعي — إما owner الأمر، أو limit_order_admin للبرنامج (محفظة ساخنة تشغيلية خارج السلسلة تشغل حلقة حارس آلية). الحارس ليس لديه سلطة أخرى — لا يمكنه نقل أموال المستخدم خارج دفع الإخراج المملوء إلى ATA owner.
الحسابات
التأثير
- يحسب الإخراج التراكمي المستحق باستخدام
(limit_order.unfilled_ratio_x64, tick.unfilled_ratio_x64). - ينقل الفرق إلى
output_token_account. - يحدث
limit_order.settled_output. - لا يغلق الأمر؛ لا يزال مفتوحًا مقابل أي إدخال متبقي.
CloseLimitOrder
إغلاق حساب أمر مستهلك بالكامل. يتم إرجاع الإيجار دائمًا إلى limit_order.owner بغض النظر عمن يوقع.
المستدعي — إما owner أو limit_order_admin.
الشروط المسبقة
- الأمر لديه باقي غير مملوء صفري (إما
amount == total_amountتم ملؤه وتسويته، أو قلل المالك الأمر إلى صفر ونسي الإغلاق).
- يغلق
limit_order؛ يتم إرسال الإيجار إلىlimit_order.owner.
CreateDynamicFeeConfig (admin)
إنشاء مجموعة معاملات قابلة لإعادة الاستخدام تحت فهرس u16.
المعاملات
الأخطاء الشائعة —
InvalidDynamicFeeConfigParams إذا كان decay_period <= filter_period أو أي حقل بقيمة 0 خارج الحدود.
UpdateDynamicFeeConfig (admin)
تعديل DynamicFeeConfig موجود. المجمعات التي التقطت لقطة من التكوين بالفعل في وقت الإنشاء لا يتم تحديثها بأثر رجعي؛ فقط المجمعات المنشأة حديثًا التي تشير إلى هذا التكوين ستلتقط القيم الجديدة.
المعاملات — نفس خمسة حقول المعايرة مثل CreateDynamicFeeConfig (filter_period, decay_period, reduction_factor, dynamic_fee_control, max_volatility_accumulator)؛ index ثابت عند الإنشاء ولا يتم إعادة تمريره هنا.
CollectProtocolFee / CollectFundFee
مسح الرسوم المتراكمة للبروتوكول/الصندوق من أقبية المجمع إلى مستقبِل، مع تصفير الحقول المقابلة PoolState.protocol_fees_* / fund_fees_*. هذا ليس تخطيط CPMM — فـ CLMM ليس لديه حساب authority، وحقول المستقبِل تُسمّى recipient_token_account_{0,1} وليس recipient_token_{0,1}_account.
المعاملات — amount_0_requested: u64، amount_1_requested: u64.
InitializeReward
إضافة تدفق مكافآت جديد إلى مجمع. قد يكون هناك ما يصل إلى 3 تدفقات نشطة في نفس الوقت.
المعاملات
param واحدًا بدلاً من ثلاث وسائط موضعية.
الحسابات
الشروط المسبقة
- أقل من 3 تدفقات نشطة حاليًا على المجمع.
- يودع الممول
total_emission = emissions_per_second × (end_time − open_time)من رمز المكافآت في القبو كجزء من هذه التعليمة. - mint مكافآت مدرج في القائمة البيضاء لكل
operation_state.
SetRewardParams
توسيع أو تعبئة أو تغيير معدل الانبعاث على تدفق مكافآت موجود. عادة ما يتم استدعاؤها من قبل منشئ المجمع أو Raydium multisig. تعيش القيود على السلسلة: يمكنك عادة توسيع end_time أو زيادة الانبعاثات، وليس تقليلها بأثر رجعي. تحقق من قائمة المالكين operation_state.
UpdateRewardInfos
محاسبة بحتة — تسوي reward_growth_global_x64 إلى الوقت الحالي بضرب emissions_per_second × Δt / liquidity. يتم استدعاؤها داخليًا بواسطة كل تعليمة تلمس السيولة. يتم تعريضها كتعليمة مستقلة لأن الجهات الفاعلة الخارجية (UIs، cranks) تريد أحيانًا تشغيلها.
جمع المكافآت
تُدفع المكافآت المستحقة لمركز عبرDecreaseLiquidity / DecreaseLiquidityV2. ولجمعها دون تغيير
المركز، استدعِها بـ liquidity = 0 و amount_0_min = 0 و amount_1_min = 0.
تُمرَّر أقبية المكافآت وحسابات المستقبِل في remaining_accounts في مجموعات من ثلاثة لكل مكافأة
نشطة، بالترتيب reward_token_vault(W) و recipient_token_account(W) و reward_vault_mint.
أما CollectRemainingRewards فهي شيء مختلف: فهي تتيح لـ ممول المكافآت، بعد end_time الخاص
بالتدفق، مسح الرموز التي لم تُخصَّص لأي مركز.

