الانتقال إلى المحتوى الرئيسي

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
هذا سجل تغييرات التوثيق — السجل الخاص بتحديثات هذه الصفحات منذ إطلاق المشروع. للعودة إلى السجل الزمني التاريخي للبروتوكول نفسه، راجع introduction/history-and-milestones. يحتوي كل إدخال على تاريخ وقائمة بالفصول المتأثرة والسبب وتاريخ التحقق الذي يشير إلى آخر مرة تم فيها فحص حالة السلسلة ومصدر البرنامج مقابل المحتوى المكتوب.

2026-05-18 — CLMM: أوامر محدودة، رسوم أحادية الجانب، رسوم ديناميكية

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

الملخص السريع للمدمجين

  • أوامر محدودة أصبحت الآن بدائل أساسية من الدرجة الأولى في CLMM. يمكن لمزودي السيولة فتح أمر بسعر واحد على تجمع يدعمه؛ يتم ملء الأمر بنظام FIFO عند عبور المبادلة للسعر، ويمكن لحارس خارج السلسلة (limit_order_admin) تسوية المخرجات المملوءة دون أن يكون المالك متصلاً. سبع طرق جديدة في SDK (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) وثلاث نقاط نهاية جديدة في Temp API تحت /limit-order/ (الأوامر النشطة، السجل لكل مستخدم، سجل الأحداث لكل PDA) تغطي التدفق الكامل.
  • رسوم أحادية الجانب (CollectFeeOn) تسمح للتجمع بجمع رسوم المبادلة من جانب الإدخال (الإرث، الوضع 0)، أو دائماً من token_0 (الوضع 1)، أو دائماً من token_1 (الوضع 2). مفيد عندما يكون أحد جانبي الزوج هو رمز المحاسبة الأساسي.
  • الرسوم الديناميكية تسمح للتجمع باختيار رسم إضافي يتتبع التقلب ويزداد مع حركة السعر السريعة وينخفض بمرور الوقت، معايرة بواسطة DynamicFeeConfig لكل طبقة وDynamicFeeInfo لكل تجمع. نقطة النهاية الجديدة /main/clmm-dynamic-config تعرض قائمة الطبقات.
  • تعليمة جديدة، CreateCustomizablePool، تعرض جميع الخيارات الثلاثة وقت إنشاء التجمع. CreatePool الكلاسيكية تستمر في العمل للتجمعات الافتراضية بدون أوامر محدودة.
  • تغيير حاسم للمفهرس: عدادات حجم الاتجاهات المنفصلة (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) وعدادات الرسوم مدى الحياة (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) على PoolState تم إيقاؤها في الحشو لإفساح المجال لـ fee_on وdynamic_fee_info. المفهرسات التي تقرأ هذه الحقول مباشرة يجب أن تنتقل إلى حلقة Observation على السلسلة أو API.

لماذا هذا مهم (للمتداولين وموفري السيولة والمدمجين)

  • المتداولون يحصلون على عروض أسعار أضيق على الأزواج طويلة الذيل والمرتبطة بالأحداث: الرسوم الديناميكية تسمح للتجمع باستيعاب رسوم التقلب من الآخذ دون أن يضطر موفرو السيولة إلى توسيع النطاقات بنشاط، والسلالم على الأوامر المحدودة تعمق السيولة على السلسلة بأسعار محددة دون الالتزام برأس مال على نطاق واسع.
  • موفرو السيولة يحصلون على استراتيجية ثالثة إلى جانب النطاقات المركزة والمراكز الكاملة: ركن أوامر بسعر محدد، احصل على ملء عند زيارة السعر، استوطن في رمز الاقتباس. لا توازن نشط مطلوب للجزء المملوء.
  • المدمجون يمكنهم نمذجة تجمعات الرسوم الديناميكية بشكل حتمي — الخوارزمية والمعاملات على السلسلة بالكامل، طبقات المعايرة قابلة للاستعلام، ومسار المبادلة لم يتغير في الشكل (فقط الرسم لكل خطوة يختلف).

ما تغير في البرنامج

حسابات جديدة

  • DynamicFeeConfig — سجل معايرة لكل طبقة (فترة التصفية، فترة الاضمحلال، عامل الاختزال، التحكم برسوم ديناميكية، أقصى مراكم تقلب). تم إنشاؤها بواسطة CreateDynamicFeeConfig (مسؤول)، المرجعية بواسطة CreateCustomizablePool عند تفعيل الرسوم الديناميكية.
  • LimitOrderState — حساب لكل أمر (بذور PDA: [owner, limit_order_nonce, order_nonce]) يحتفظ بالتجمع والسعر والجانب ومبلغ الإدخال ونسبة غير مملوءة وطور FIFO cohort وقطاع الحفظ. دورة الحياة ضمنية (filled_amount مقابل total_amount، بالإضافة إلى وجود الحساب): Open → Filled → Settled → Closed.
  • LimitOrderNonce — عداد متزايد بشكل أحادي لكل (مالك، مؤشر nonce) يحصل على بذور PDA للأمر المحدود. يتيح nonce_index: u8 للمالك نفسه تقسيم الأوامر إلى ما يصل إلى 256 تدفق nonce مستقل.
راجع الحسابات → DynamicFeeConfig و DynamicFeeInfo والحسابات → LimitOrderState.

إعادة تشكيل PoolState

مجموعة الحقولالتخطيط القديمالتخطيط الجديد
عدادات حجم الاتجاه المنفصلswap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1مدمج في padding5: [u128; 4]
عدادات رسوم مدى الحياةtotal_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1مدمج في padding6: [u64; 4]
رسوم أحادية الجانبfee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
رسوم ديناميكيةdynamic_fee_info: DynamicFeeInfo (مدمج)
حجم الحساب الإجمالي لم يتغير. المفهرسات: قم بتبديل تتبع الحجم بعيداً عن PoolState وإلى حلقة Observation أو API. العدادات المتقاعدة لم تُصفر على التجمعات الحالية (تحتفظ بما حدث آخر حمل)، لذا إعادة قراءتها بعد الترقية ستعيد بيانات قديمة.

إضافات TickState (لا توجد تغييرات حاسمة)

تمت إضافة أربعة حقول جديدة في نهاية TickState، استبدال بعض الحشو الخلفي:
  • order_phase: u64 — عداد يميز مجموعات الأوامر المحدودة في هذا السعر.
  • orders_amount: u64 — إجمالي الإدخال الملتزم به من قبل جميع الأوامر المفتوحة في هذا السعر (ليست كلها غير مملوءة تماماً).
  • part_filled_orders_remaining: u64 — الإدخال غير المملوء بعد في المجموعة التي يتم استهلاكها حالياً بواسطة المبادلات.
  • unfilled_ratio_x64: u128 — نسبة Q64.64 المستخدمة لحساب حصة الملء لكل أمر.
تخطيط صفيف السعر، والحجم، وبذور PDA لم تتغير.

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

  • CreateDynamicFeeConfig (مسؤول) — إنشاء طبقة DynamicFeeConfig معايرة. السلطة: نفس multisig الخزانة مثل CreateAmmConfig.
  • UpdateDynamicFeeConfig (مسؤول) — تحديث معاملات طبقة موجودة.
  • CreateCustomizablePool — نقطة دخول إنشاء التجمع التي تعرض collect_fee_on وenable_dynamic_fee وdynamic_fee_config. تتعايش مع CreatePool؛ نوصي بـ CreateCustomizablePool لأي تجمع جديد يحتاج إلى الخيارات الجديدة.
  • OpenLimitOrder — فتح أمر محدود بسعر واحد. تضخيم LimitOrderNonce، تخصيص LimitOrderState، إدراج الأمر في مجموعة FIFO في السعر.
  • IncreaseLimitOrder / DecreaseLimitOrder — اضبط جزء الأمر غير المملوء. يرتد على أمر مملوء بالكامل مع InvalidOrderPhase.
  • SettleLimitOrder — اكتساح المخرجات المملوءة إلى ATA المالك. يمكن للمتصل أن يكون المالك أو حارس limit_order_admin للتجمع.
  • CloseLimitOrder — إغلاق أمر مستوطن بالكامل لاسترجاع الإيجار.

تغييرات سلوك SwapV2

مسار المبادلة نفسه لم يتغير في الشكل، لكن ثلاثة أشياء تحدث الآن على طول الطريق:
  1. رسوم ديناميكية (عند التفعيل): DynamicFeeInfo للتجمع يتم تحديثه في كل خطوة (اضمحلال → تجمع → حد)، والرسم الإضافي الناتج يتم إضافته على رأس الرسم الأساسي لهذه الخطوة.
  2. مطابقة الأوامر المحدودة (عند عبور الخطوة لسعر مهيأ يحتوي على أوامر مفتوحة): جزء من إدخال المبادلة يتم استهلاكه بنظام FIFO لملء المجموعة في هذا السعر، مع تحديث unfilled_ratio_x64 بشكل ذري.
  3. توجيه الرسوم أحادية الجانب (عند fee_on != 0): يتم أخذ الرسم من token_0 أو token_1 بغض النظر عن اتجاه المبادلة، بدلاً من أخذه دائماً من جانب الإدخال.
كل من هذه لا شيء عند إنشاء التجمع بالافتراضيات الموروثة. راجع التعليمات → SwapV2 لمصفوفة تغيير الحالة المحدثة.

رموز أخطاء جديدة

تم إعادة ترقيم enum ErrorCode في هذا الإصدار: تم إزالة خمسة متغيرات قديمة (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount)، وتمت إضافة احدى عشر متغير جديد. لأن Anchor يرقم الأخطاء حسب ترتيب enum من 6000، كل رمز خطأ عند أو بعد المواضع المحذوفة قد تحول — العملاء الذين رموا الأكواد الرقمية بشكل صريح يحتاجون إلى إعادة خريطة. الرموز الجديدة هي:
  • 6040 OrderAlreadyFilled
  • 6041 InvalidOrderPhase
  • 6042 InvalidLimitOrderAmount
  • 6043 OrderPhaseSaturated
  • 6044 InvalidDynamicFeeConfigParams
  • 6045 InvalidFeeOn
  • 6046 ZeroSqrtPrice
  • 6047 ZeroLiquidity
  • 6048 MissingBaseFlag
  • 6049 MissingMintAccount
  • 6050 MissingTokenProgram2022
الرموز الكاملة والجدول بعد الإزاحة لجميع أخطاء CLMM موجودة في رموز الأخطاء.

ما تغير في SDK (@raydium-io/raydium-sdk-v2)

  • طرق جديدة على raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
  • مساعدات REST جديدة على raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
  • أنواع جديدة: enum CollectFeeOn, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
  • إعادة تنظيم داخلية: utils/ انتقل إلى libraries/. براميل الحزمة لم تتغير؛ فقط الواردات العميقة تحت @raydium-io/raydium-sdk-v2/utils/... تحتاج إلى تحديث إلى …/libraries/....
نسق TypeScript من النهاية إلى النهاية يعيش في products/clmm/code-demos.

ما تغير في APIs

  • api-v3 — نقطتا نهاية جديدة تحت /main/:
    • GET /main/clmm-dynamic-config — قائمة طبقات DynamicFeeConfig.
    • GET /main/clmm-limit-order-config — تكوين الأوامر المحدودة لكل تجمع.
  • temp-api-v1 — ثلاث نقاط نهاية جديدة تحت /limit-order/:
    • GET /limit-order/order/list?wallet=… — أوامر محددة حالياً لمحفظة (مفتوح وممتلئ جزئياً، يتم تقديمه من ذاكرة التخزين المؤقت Redis للمفهرس؛ نفس الحمولة تغطي كلا المرحلتين عبر totalAmount / filledAmount / pendingSettle).
    • GET /limit-order/history/order/list-by-user?wallet=… — أوامر محدودة تاريخية لمحفظة. مرشحات اختيارية: poolId, mint1, mint2, hideCancel. الدفع حسب الكود عبر nextPageId / size (أقصى 100).
    • GET /limit-order/history/event/list-by-pda?pda=… — سجل حدث لكل PDA (open / increase / decrease / settle / close) لواحد أو أكثر من PDAs الأوامر المحدودة مفصولة بفاصلة. الدفع حسب الكود عبر nextPageId / size (أقصى 100).
جميع الخمسة موثقة في تبويب مرجع API.

سطح السلطة

limit_order_admin هو حارس تشغيلي خارج السلسلة، وليس multisig. يمكنه فقط استدعاء SettleLimitOrder وCloseLimitOrder على الأوامر الموجودة، ومخرجات التسوية تذهب دائماً إلى ATA المالك. لا يمكنه تغيير حقول التجمع أو فتح أو تعديل الأوامر أو التوقيع على أي شيء آخر. راجع مفاتيح المسؤول و multisig → CLMM.

الصفحات المحدثة

  • products/clmm/overview — قسم “ما الجديد” ومؤشرات الخطوة التالية المحدثة.
  • products/clmm/accounts — ثلاث حسابات جديدة، إعادة تشكيل PoolState مع تحذير الهجرة، إضافات TickState، مساعدات PDA جديدة.
  • products/clmm/instructions — سبع تعليمات جديدة، ملحق سلوك SwapV2، مصفوفة تغيير الحالة المحدثة.
  • products/clmm/fees — قسم الرسوم أحادية الجانب، قسم الرسوم الديناميكية مع جدول المعاملات.
  • products/clmm/math — أكواد شبه مطابقة الأوامر المحدودة، اشتقاق الرسوم الديناميكية.
  • products/clmm/code-demos — عرض createCustomizablePool، نسق أوامر محدودة كاملة، مزالق جديدة.
  • algorithms/clmm-math — مرجع متقاطع إلى مطابقة الأوامر المحدودة والرسوم الديناميكية في حلقة المبادلة متعددة الأسعار.
  • sdk-api/typescript-sdk — قسم إضافات وحدة CLMM، ملاحظة الهجرة utils/libraries/.
  • api-reference/openapi/api-v3.yaml — نقطتا نهاية جديدة مع مخططات الاستجابة.
  • api-reference/openapi/temp-api-v1.yaml — ثلاث نقاط نهاية جديدة للأوامر المحدودة (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) مع طلبات واستجابات مخطط.
  • api-reference/api-v3/overview — ملاحظة عن نقاط نهاية تكوين CLMM الجديدة.
  • api-reference/temp-api-v1/overview — ملاحظة عن نقاط النهاية الجديدة للأوامر النشطة والسجل حسب المستخدم والحدث حسب PDA.
  • reference/error-codes — احدى عشر رموز أخطاء CLMM جديدة (6040–6050) بالإضافة إلى خمسة رموز موروثة محذوفة؛ الرموز الرقمية بعد نقاط الإزالة قد تحولت.
  • security/admin-and-multisig — صف مسؤول DynamicFeeConfig جديد وصف حارس limit_order_admin، مع شرح السلطة المحدودة.
تم التحقق من:
  • مصدر raydium-clmm.
  • مصدر @raydium-io/raydium-sdk-v2.
  • مصدر api-v3 وtemp-api-v1.

2026-04-26 — النشر الأولي

الإصدار العام الأول من مجموعة توثيق Raydium. تم التحقق من:
  • نشرات البرنامج المباشرة على Solana mainnet-beta.
  • @raydium-io/raydium-sdk-v2@0.2.42-alpha.
  • مستندات Raydium العامة والمراجع على السلسلة حتى أبريل 2026.
في المستقبل، كل ترقية بروتوكول أو تدقيق أو مراجعة وثائق تصبح إدخالاً جديداً في هذا الملف.

اتفاقيات التوثيق

  • الإصدار: هذا التوثيق يستخدم الإصدار المستند إلى التقويم (YYYY-MM-DD). كل تحديث ينشئ إدخالاً جديداً في أعلى الملف.
  • تاريخ التحقق: كل إدخال يسجل متى تم آخر فحص للمحتوى مقابل حالة السلسلة / API ومصدر البرنامج. إذا لم يتم ذكره، افترض التاريخ الرئيسي للإدخال.
  • التغييرات الحاسمة: يتم الإشارة إليها في تحذير مربع على الصفحات المتأثرة وتوسيم في الإدخال أدناه.
  • التغطية: هذا السجل يغطي مجموعة التوثيق نفسها. السجل الزمني التاريخي للبروتوكول نفسه يعيش في introduction/history-and-milestones وهو مصدر الحقيقة لـ “متى حدثت X على Raydium”.

التصحيحات

إذا وجدت خطأ في هذا التوثيق، يرجى فتح إصدار أو طلب سحب على مستودع التوثيق. يتم تسجيل التصحيحات في هذا السجل.

المؤشرات