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.
لكل برنامج من برامج Raydium دور مميّز واحد على الأقل — مفتاح يتيح ترقية البرنامج، أو إنشاء إعدادات جديدة، أو سحب رسوم البروتوكول. يُعدّ تضييق نطاق هذه الأدوار (وتأمينها خلف multisigs مع فترات تأخير) الخط الدفاعي الأول في حال اختراق أي مسؤول. توثّق هذه الصفحة تلك الأدوار وآليات تأمينها على أرض الواقع.
الأدوار حسب كل برنامج
AMM v4
| الدور | عنوان الصلاحية | ما يمكنه فعله |
|---|
| ترقية البرنامج | Squads multisig (3/4) | نشر bytecode جديد للبرنامج |
| Pool admin | Treasury multisig (3/5) | تفعيل/تعطيل Pool، وتحديث الرسوم على Pools القائمة |
CPMM
| الدور | عنوان الصلاحية | ما يمكنه فعله |
|---|
| ترقية البرنامج | Squads multisig (3/4) | نشر bytecode جديد للبرنامج |
| AmmConfig admin | Treasury multisig (3/5) | إنشاء AmmConfigs جديدة (فئات الرسوم)؛ تفعيل/تعطيل القائمة |
| مستلم رسوم إنشاء Pool | Treasury multisig (3/5) | استلام رسوم إنشاء Pool لمرة واحدة |
CLMM
| الدور | عنوان الصلاحية | ما يمكنه فعله |
|---|
| ترقية البرنامج | Squads multisig (3/4) | نشر bytecode جديد للبرنامج |
| AmmConfig admin | Treasury multisig (3/5) | إنشاء/تعديل AmmConfigs |
| DynamicFeeConfig admin | Treasury multisig (3/5) | CreateDynamicFeeConfig / UpdateDynamicFeeConfig — ضبط فئات الرسوم الديناميكية التي يمكن لاستدعاء CreateCustomizablePool الاشتراك فيها |
limit_order_admin (على مستوى البرنامج) | محفظة تشغيلية hot wallet خارج السلسلة، وليست multisig | تسوية أوامر الحد وإغلاقها نيابةً عن أصحابها. مفتاح الـ keeper هو ثابت واحد على مستوى البرنامج (قيمة مختلفة على mainnet مقابل devnet)، يُتحقق منه عبر signer == limit_order.owner || signer == limit_order_admin::ID عند SettleLimitOrder / CloseLimitOrder. يُودَع الناتج دائمًا في ATA المالك الأصلي؛ لا يستطيع الـ keeper إعادة توجيه الأموال، أو تعديل الأوامر، أو فتح أوامر جديدة. |
limit_order_admin دورًا تشغيليًا ضيّق النطاق بصورة مقصودة. وجوده يُتيح لـ keeper خارج السلسلة تسوية الأوامر المنفّذة دون اشتراط تواجد مالك الأمر على الإنترنت. مفتاح الـ keeper هو مفتاح hot يعيش على VM الخاص بالـ keeper ويُدار باستقلالية عن الـ multisigs أعلاه. بصورة ملموسة، صلاحية الـ keeper محدودة بما يلي:
SettleLimitOrder — دفع الناتج المنفّذ لأمر ما إلى ATA المالك بسعر الحد المحدد في الأمر.CloseLimitOrder — إغلاق حساب أمر مُسوَّى بالكامل لاستعادة الإيجار (يعود الإيجار إلى مالك الأمر).
لا يستطيع الـ keeper استدعاء OpenLimitOrder أو IncreaseLimitOrder أو DecreaseLimitOrder، ولا تعديل أي حقل في Pool، ولا التوقيع على أي تعليمة أخرى — تُطبَّق هذه القيود على السلسلة عبر قيود الـ seed وقيود has_one في هيكل Accounts الخاص بالتعليمة. في أسوأ سيناريو لاختراق الـ keeper، يكون غير متاح (تبقى الأوامر معلّقة حتى يُسوّيها المالك بنفسه)، أو يُسوّي/يُغلق أوامر مؤهلة للتنفيذ بترتيب مختلف؛ لا يستطيع نقل أموال المستخدمين إلى أي وجهة غير تلك التي فوّضها المالك مسبقًا.
Farm v6
| الدور | عنوان الصلاحية | ما يمكنه فعله |
|---|
| ترقية البرنامج | Squads multisig (3/4) | نشر bytecode جديد للبرنامج |
| منشئ Farm (لكل Farm) | محفظة منشئ الـ Farm | تمويل خزائن المكافآت، تمديد الجداول الزمنية، استعادة المكافآت غير المستخدمة |
LaunchLab
| الدور | عنوان الصلاحية | ما يمكنه فعله |
|---|
| ترقية البرنامج | Squads multisig (3/4) | نشر bytecode جديد للبرنامج |
| منشئ الإطلاق (لكل إطلاق) | محفظة منشئ الإطلاق | تحصيل رسوم المنشئ بعد التخرّج؛ سحب متبقيات المنحنى في حال عدم التخرّج |
صلاحية ترقية البرنامج
تستخدم برامج Raydium آلية الترقية القياسية في Solana عبر BPF Loader v3. تتولى الـ 3/4 Squads multisig صلاحية ترقية جميع البرامج.
سبب اختيار 3/4: عدد كافٍ من الموقّعين بحيث لا يكفي اختراق واحد منهم؛ وعدد منخفض بما يكفي لجعل تنسيق الترقيات الشرعية أمرًا عمليًا. الجهات الأربع هي موقّعون مستقلون يستخدمون أجهزة باردة معزولة هوائيًا يحتفظ بها أعضاء الفريق الأساسي. يمنع التوقيع التسلسلي الموافقات المتوازية على المعاملة ذاتها؛ وتحمل كل معاملة نافذة انتهاء صلاحية ثابتة. تُراجَع عمليات Multisig دوريًا بالشراكة مع برنامج Solana STRIDE (Asymmetric Research).
إزالة صلاحية الترقية
لم تُعيَّن صلاحية ترقية أي برنامج في Raydium إلى null. يعمل البروتوكول وفق مبدأ أن البرامج يجب أن تكون قابلة للترقية (لتصحيح الأخطاء، وإضافة امتدادات كـ Token-2022، وإصلاح انجرافات التكامل). المقايضة هي: يثق المستخدمون بأن الـ 3/4 multisig ستنشر فقط ترقيات مُراجَعة بعناية.
للمستخدمين الراغبين في بديل ثابت لا يقبل التغيير، يُعدّ برنامج AMM v4 الأقدم مستقرًا منذ آخر مراجعة أمنية له؛ دون أي ترقيات خلال 18 شهرًا. هذا المسار البرمجي مُجمَّد فعليًا حتى وإن كانت الصلاحية لا تزال قائمة.
صلاحية AmmConfig
إنشاء كل AmmConfig جديدة مقيَّد بالصلاحية — تُجيز الـ 3/5 treasury multisig فئات الرسوم الجديدة وتباعد نقاط الـ tick. تُشير الـ Pools القائمة إلى AmmConfig الخاصة بها عبر PDA؛ وفئة رسوم الـ Pool هي ما تحدده AmmConfig.
هل يمكن للمسؤولين تعديل AmmConfig قائمة؟ نعم، من الناحية التقنية. يمكن للمسؤول استدعاء updateAmmConfig. غير أنه في الممارسة العملية، تُتجنّب تعديلات AmmConfigs المنشورة لأنها تُغيّر الاقتصاديات لجميع الـ Pools المستخدِمة لهذه الإعدادات بصمت. سياسة البروتوكول هو إنشاء AmmConfig جديدة لأي تغيير، ثم الترحيل إليها.
هل يمكن للمسؤولين سرقة رسوم البروتوكول عبر الإعدادات؟ لا — تحتوي AmmConfig على معاملات الرسوم لكن ليس على عنوان مستلم رسوم البروتوكول؛ وهذا عنوان ثابت منفصل لكل Pool.
المطالبة برسوم البروتوكول
تتراكم نسبة من رسوم swap (تتراوح عادةً بين 3 و12 bps من رسوم swap البالغة 25 bps، بحسب الإعداد) في خزينة رسوم البروتوكول. يمكن لـ multisig سحب هذه الرسوم المتراكمة. لا يرى المستخدمون أي تغيير في رصيد LP الخاص بهم جراء ذلك — فهذه الحصة المخصصة مسبقًا للبروتوكول وليست من أموال الـ LP.
صلاحية منشئ الـ Farm
يمنح نظام Farms v6 المنشئ الصلاحيات التالية:
- تمويل خزينة المكافآت (إضافة المزيد من التوكنات).
- تمديد الجدول الزمني (تأجيل وقت الانتهاء).
- استدعاء
withdrawReward بعد انتهاء الوقت لاستعادة رصيد الخزينة غير المستخدم.
لا يستطيع منشئو الـ Farm:
- سحب حصص LP الخاصة بالمستخدمين.
- تغيير mint الخاص بالـ staking.
- تغيير معدلات الإصدار بأثر رجعي (فقط بشكل استشرافي عبر
setRewards).
- تجميد حصاد المستخدمين.
في أسوأ سيناريو لمنشئ Farm ضار، يتمثل في تقليص تمويل الخزينة فتنفد الـ Farm؛ بينما تظل أموال الـ staking الأصلية للمستخدمين آمنة دائمًا.
إعداد Squads Multisig
تُشغّل Raydium اثنين من Squads multisigs منفصلين لمعالجة سطوح مخاطر مختلفة. يمكن فحص كليهما على السلسلة عبر واجهة Squads Protocol.
| Multisig | الحدّ الأدنى للموافقة | التأخير الزمني | النطاق |
|---|
| ترقية البرنامج | 3/4 | 24 ساعة | الصلاحية الوحيدة لنشر bytecode جديد لبرامج AMM v4 وCPMM وCLMM وLaunchLab وLock وAMM Routing وStable Swap وبرامج Farm/Staking القديمة. عرضه على app.squads.so/.../FytDr…ceZQK. |
| Treasury | 3/5 | لا يوجد | أصول الخزينة، عائدات البروتوكول، النفقات التشغيلية. كما يحمل صلاحية الإدارة المحدودة للبرامج في Raydium (إنشاء AmmConfigs، تجميع رسوم البروتوكول، ضبط معاملات Pool) في الوقت الراهن. عرضه على v3.squads.so/dashboard/RVha…dHdtYz09. |
- تأخير 24 ساعة على أي معاملة. أي ترقية تُوافَق عليها اليوم لن تُنفَّذ قبل مرور 24 ساعة، مما يمنح المستخدمين وقتًا للتصرف.
- التوقيع عبر أجهزة باردة معزولة هوائيًا. أُزيلت بطاقات الشبكة فعليًا من الأجهزة الباردة؛ وتتصل هذه الأجهزة فقط بمحافظ الأجهزة وتقرأ بيانات المعاملة عبر رمز QR من جهاز hot منفصل.
- التوقيع التسلسلي. فقط بعد أن يُنشئ جهاز بارد أول المعاملة ويوقّعها يمكن للجهاز البارد الثاني البدء في التوقيع — مما يمنع التوقيعات المتضاربة أو المتوازية على المعاملة ذاتها.
- انتهاء صلاحية المعاملة. تحمل كل معاملة نافذة انتهاء صلاحية ثابتة، فتُلغى المعاملات القديمة تلقائيًا.
- تطبيق TOTP + المفتاح المادي على الأجهزة الساخنة المستخدمة لبدء المعاملات والبث على السلسلة.
- قائمة انتظار المعاملات العامة. يمكن لأي شخص مراقبة الترقيات المعلّقة عبر واجهة Squads.
لا يوجد تأخير زمني لـ treasury multisig — نطاقه أضيق والعمليات الروتينية (إنشاء AmmConfigs، تجميع الرسوم) تحتاج إلى التسوية في اليوم ذاته. كما تحمل treasury multisig صلاحية الإدارة المحدودة للبرامج الواردة في جداول كل برنامج أعلاه؛ وهذا ترتيب مرحلي يُراجَع دوريًا مع شركاء الأمن للمشروع.
التحقق من الصلاحية على السلسلة
أبسط طريقة للتحقق من صلاحية الترقية الحالية لأي برنامج:
solana program show <PROGRAM_ID>
Program Id: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: <ProgramDataPDA>
Authority: <EXPECTED_MULTISIG_ADDRESS>
Last Deployed In Slot: <slot>
Data Length: <n> bytes
Authority هو عنوان Squads multisig المتوقع، فثمة خطأ ما. تنشر Raydium عناوين الصلاحية المتوقعة على reference/program-addresses.
لأدوار AmmConfig / pool admin، اجلب الحساب على السلسلة وفكّ ترميزه:
const config = await raydium.cpmm.getAmmConfig(configPda);
console.log("AmmConfig admin:", config.admin.toBase58());
// Expected: 3/5 treasury multisig.
التغييرات التاريخية في الصلاحيات
| التاريخ | البرنامج | التغيير |
|---|
| 2022-12 | AMM v4 | نقل صلاحية الترقية من توقيع منفرد إلى 3/4 multisig إثر حادثة |
| 2023-02 | جميع البرامج | توحيد جميع الأدوار التشغيلية تحت 3/5 treasury multisig |
| 2023-11 | CLMM | إضافة multisig ثانٍ لعمليات المكافآت فحسب لتقليل التعرض |
| 2024-05 | CPMM | النشر الأولي مع صلاحية multisig من اليوم الأول |
اعتبارات للمستخدمين
ما الذي ينبغي لك فعله بوصفك مستخدمًا أو LP أو مُدمِجًا؟
- تحقق من صلاحية الترقية قبل التخصيصات الكبيرة. تأكد من تطابقها مع الـ multisig الموثّق.
- راقب نشاط الـ multisig. تعرض واجهة Squads المعاملات المعلّقة؛ والترقية المجدولة تمنحك 24 ساعة للخروج إن كنت لا توافق على التغيير.
- استراتيجيات استرداد تراعي التأخير الزمني. إن كنت تُشغّل مُركّبًا تلقائيًا، تأكد من أن مسار الخروج الخاص بك لا يستلزم تعليمة يجري تعديلها.
- لا تفترض ثبات البرنامج وعدم قابليته للتغيير. كل برنامج في Raydium قابل للترقية؛ خطّط لذلك.
مخاطر شائعة للمُدمِجين
1. تخزين عناوين الصلاحيات مؤقتًا (Caching)
إن قمت بتضمين عنوان صلاحية الترقية أو multisig المسؤول بصورة ثابتة في كودك وتغيّر لاحقًا، سيفشل التحقق. اجلب البيانات من reference/program-addresses في وقت التشغيل أو حدّثها دوريًا.
2. افتراض ثبات AmmConfigs
يمكن إنشاء AmmConfig جديدة في أي وقت. يجب على مُجمِّعك/موجِّهك إعادة جلب القائمة الكاملة للإعدادات دوريًا (كل ساعة كافٍ).
3. مخاطر الإضرار من منشئي الـ Farm
إن كنت تودع في Farm ذات سمعة مجهولة، يستطيع المنشئ إنهاء الـ Farm مبكرًا واستعادة خزينة المكافآت (شريطة ألا يكون أي مستخدم قد وضع حصصه بعد). حالما يضع المستخدمون حصصهم، يُطبّق البرنامج الاستحقاقات بالتناسب؛ وتتم الاستعادة فقط من المتبقي بعد الانتهاء الطبيعي.
مراجع وروابط مفيدة
المصادر:
