البنية التحتية المشتركة

​

ما معنى “المشترك” هنا

• مشاركة الاتفاقية. يستخدم كل برنامج نفس نمط اشتقاق PDA، وشكل تقسيم الرسوم نفسه، وفكرة حساب المراقبة نفسها — لكن كل منها ينفذها في برنامجه الخاص بذوره الخاصة.
• مشاركة الحساب. عدد قليل من الحسابات هي حرفيًا نفس السجل عبر العديد من المجموعات (PDA السلطة العامة في CPMM، حسابات AmmConfig).
• المشاركة خارج السلسلة. واجهة REST واحدة وحزمة TypeScript واحدة تخدم جميع البرامج الأربعة. يتفاعل المدمجون مع مضيف HTTP واحد وحزمة NPM واحدة بغض النظر عن البرنامج الذي ينتهي بهم الحال.

​

1. PDAs السلطة

• بالنسبة إلى CPMM و CLMM، فإن PDA السلطة هو حساب عام — تستخدمه كل مجموعة من هذا النوع. إذا كنت تقوم بـ CPI في CPMM فأنت تحتاجه مرة واحدة، وليس لكل مجموعة.
• بالنسبة إلى السلطات لكل مجموعة / لكل مزرعة، تشتق PDA من معرّف المجموعة/المزرعة. يقوم SDK بهذا في getPoolKeys / getFarmKeys؛ إذا كنت تدمج مباشرة، فأنت تشتق باستخدام findProgramAddressSync.
• لا يمكن تغيير ملكية الخزينة. بمجرد إنشاء حساب رمز مع PDA السلطة كمالك، فقط هذا PDA — الذي يستدعيه البرنامج — يمكنه نقل الأموال للخارج. لا يوجد تجاوز إداري.

​

2. حسابات المسؤول والإعدادات

// CPMM AmmConfig (مختصر — نسخة CLMM متشابهة هيكليًا)
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // gate new pool creation in this tier
    pub index: u16,                       // tier index
    pub trade_fee_rate: u64,              // fraction of trade going to fees
    pub protocol_fee_rate: u64,           // fraction of trade fee to protocol
    pub fund_fee_rate: u64,               // fraction of trade fee to fund
    pub create_pool_fee: u64,             // one-time per-pool creation fee
    pub protocol_owner: Pubkey,           // signer for CollectProtocolFee
    pub fund_owner: Pubkey,               // signer for CollectFundFee
    pub padding: [u64; 16],
}

• طبقات الرسوم عامة. عندما تقول مجموعة “هذه مجموعة 0.25%”، فهذا يعني أنها تربط بـ AmmConfig الذي كان trade_fee_rate فيه 0.25% عند وقت الإنشاء. لا يوجد تجاوز معدل لكل مجموعة.
• يمكن تغيير الإعداد لكن المجموعات لا تتابع. إذا قام سلطة الإعداد بتحرير AmmConfig، فإن كل مجموعة موجودة مرتبطة بهذا الإعداد تلتقط المعدل الجديد على الفور. هذه ميزة وليست خطأ؛ هذه هي الطريقة التي تنتشر بها التغييرات الاقتصادية على مستوى البروتوكول دون هجرات لكل مجموعة.
• disable_create_pool هو رافعة الإيقاف. عندما يتم إيقاف طبقة رسوم، تقوم multisig البروتوكول بتعيين هذا العلم — تستمر المجموعات الموجودة في العمل لكن لا يمكن لأي مجموعات جديدة اختيار الطبقة.
• protocol_owner / fund_owner هم الموقّعون لاستدعاءات جمع الرسوم. تعيينهم إلى multisig هو ما يحد من سحب الرسوم. إنهم ليسوا عناوين الوجهة للرسوم نفسها؛ هذا هو protocol_fee_destination / fund_fee_destination على نفس الحساب.

​

3. تقسيم رسوم البروتوكول / الصندوق / المنشئ

                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)

1. رسم التجارة يتراكم في المجموعة. يتم إزالة الرسم من جانب الإدخال للمبادلة والمبلغ بعد الرسم هو ما تراه رياضيات المنتج الثابت. هذا ما يعنيه “LP يكسب الرسم” — k يرتفع وكذلك قيمة الرمز المضمون لكل LP.
2. يتم خصم أجزاء البروتوكول/الصندوق/المنشئ من هذا التراكم على جانب LP إلى حسابات عداد لكل مجموعة. تجلس على حالة المجموعة (protocol_fees_token{0,1}، fund_fees_token{0,1}، إلخ.) حتى يستدعي شخص ما تعليمات الجمع المقابلة. لا تغادر خزائن المجموعة حتى ذلك الحين؛ من منظور المبادلة، لا تزال “في المجموعة”.
3. الجمع ينقلها للخارج. مسارات البروتوكول والصندوق تتطلب موقّع protocol_owner / fund_owner الخاص بهما من AmmConfig. تستخدم رسوم منشئ CPMM إما مسار CollectCreatorFee الموقّع من قبل المنشئ أو CollectCreatorFeePermissionless، والذي يمكن لأي دافع أن يشغله لكنه يصلح الوجهات إلى ATAs الكنسية للمنشئ.

• نسب التقسيم تكون من رسم التجارة، وليس من التجارة. رسم تجارة 0.25% مع حصة بروتوكول 12% يعني أن البروتوكول يحصل على 0.25% × 12% = 0.03% من التجارة — وليس 12% من التجارة.
• رسوم المنشئ موجودة فقط على مجموعات LaunchLab المتخرجة. مجموعات CPMM/CLMM القياسية لها تقسيم ثلاثي (LP / بروتوكول / صندوق). يضيف LaunchLab فتحة رابعة موجهة إلى من أطلق الرمز، مُعدّة عند Initialize وغير قابلة للتغيير.
• AMM v4 ينقسم بطريقتين فقط، مشفرة بشكل ثابت لكل مجموعة: LP والبروتوكول. لا توجد فتحة صندوق، لا توجد فتحة منشئ.
• الصندوق مقابل البروتوكول — كلاهما وجهات خزينة البروتوكول، لكن لديهما موقّعون مختلفون واستخدامات مقصودة مختلفة. يمول protocol تاريخيًا العمليات؛ fund هي الخزينة الأطول أجلاً. التقسيم بين الاثنين هو نفسه قابل للتعديل.

​

4. حسابات المراقبة (حلقة TWAP)

// CPMM ObservationState (مختصر)
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // next slot to overwrite
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // sum of (price × dt) since init
    pub cumulative_token_1_price_x32: u128,
}

• كل مبادلة تستدعي update_observation. يقرأ البرنامج السعر الحالي، ويضربه في الثواني المنقضية منذ المراقبة السابقة، ويضيفه إلى العداد التراكمي. يستبدل الإدخال الجديد الفتحة الأقدم (بأسلوب حلقة الذاكرة المؤقتة).
• TWAP على نافذة = (cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start]). يختار المستهلكون ملاحظتين تحيط بالنافذة المرغوبة ويقسمان.
• Raydium نفسها لا تستخدم TWAP للتسعير. تقرأ رياضيات AMM الاحتياطيات الفورية مباشرة. المراقبات هي خارجية — تدفع Raydium تكلفة كتابتها حتى تتمكن العقود الأخرى من القراءة.
• AMM v4 لا يحتوي على حساب مراقبة. إنه أقدم من تصميم ObservationState؛ المدمجون الذين يريدون TWAP v4 يجب أن يحسبوا واحدًا خارج السلسلة من سجل السجلات.

​

5. REST API + SDK + IDL

• REST API — https://api-v3.raydium.io. عرض مفهرس يقرأ في الغالب لجميع حالة السلسلة بالإضافة إلى محرك الاقتباس. مضيف واحد، مخطط واحد.
• TypeScript SDK — @raydium-io/raydium-sdk-v2 على NPM. ينشئ ويوقّع معاملات لكل برنامج. يتحدث إلى API للاقتباسات/البيانات الوصفية، ويتحدث إلى Solana RPC لتحديثات الحالة قبل التوقيع.
• سجل IDL — توجد Anchor IDLs لكل برنامج منشور في مستودع raydium-idl (JSON واحد لكل برنامج: CPMM، CLMM، LaunchLab). يستهلك TypeScript SDK هذه IDLs داخليًا؛ يعيد إنشاء عملاء Rust / Python من نفس الملفات.

​

6. المفهرسات وموجزات الأسعار

• المفهرس هو الشيء الوحيد الذي “يعرف عن” حالة البرنامج المتقاطع. ربط مجموعة CPMM بنظيرتها CLMM، حساب رقم الحجم 24 ساعة عبر إصدارات البرنامج، التقاط مزرعة مرتبطة برمز LP — كل ذلك هو عمل المفهرس. البرامج نفسها لا تفعل ذلك.
• وقت توقف المفهرس هو وقت توقف API. إذا أرجع API بيانات قديمة أو فارغة، فالمفهرس هو المريب. حالة السلسلة غير متأثرة؛ يمكن للمدمجين الذين لديهم RPC خاص بهم و SDK الاستمرار في المعاملات.

​

ما هو غير مشترك

• البرامج لا تستدعي بعضها البعض. مبادلة CPMM لا تقوم أبدًا بـ CPI في CLMM أو AMM v4. البرنامج الوحيد الذي يؤلف عدة AMMs هو برنامج AMM Routing — وهذا الواحد نفسه رقيق، فقط ينبعث CPIs في كل AMM بالتسلسل.
• لا توجد سلطة ترقية مشتركة عبر البرامج. لكل برنامج على السلسلة مفتاح ترقية برنامج خاص به (multisig 3/4 بالإضافة إلى timelock 24 ساعة). لم يتم ربطهم.
• لا توجد حالة مشتركة بين المزارع و AMMs. لا تعرف المزرعة أي LP تراهن من مجموعة CPMM، أو NFT موضع CLMM-mint، أو رمز SPL غير ذي صلة. يعامل برنامج المزرعة رمز الرهن كمعتم.
• لا توجد تبعية نبي. التسعير هو احتياطيات السلسلة. لا يوجد بديل Pyth/Switchboard؛ لا يتحقق AMM من نبي قبل المقاصة.

​

المؤشرات

• protocol-overview/architecture — الرسم البياني الموثوق الذي يوضح كيفية تكوين هذه القطع.
• protocol-overview/versions-and-migration — كيف تطورت الاتفاقيات عبر إصدارات البرنامج.
• security/admin-and-multisig — من يتحكم في المفاتيح خلف AmmConfigs.
• reference/fee-comparison — مصفوفة معدل الرسوم لكل منتج.
• reference/program-addresses — معرفات البرامج الموثوقة.

• Raydium SDK v2 — مصدر الحقيقة لبذور PDA وتخطيطات الحسابات وتعريفات IDL.
• سجل Raydium IDL — Anchor IDLs.
• صفحات حسابات المنتجات المذكورة أعلاه.