Skip to main content
هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
يغطي هذا الإدراج تحديث برنامج CPMM القادم. تم التحقق منه مقابل فرع الإصدار المحلي (0dde43d، 11 سبتمبر 2026) قبل النشر. تأكد من البرنامج المنشور قبل الاعتماد على التعليمات الجديدة أو قوائم الحسابات المتغيرة.
كان رسم المنشئ في CPMM يذهب دائماً بالكامل إلى منشئ المجموعة. يتيح هذا الإصدار للبروتوكول الاحتفاظ بحصة منه — قابلة للتفاوض لكل فئة رسم، أو لكل منشئ على فئة رسم — دون المساس بكيفية فرض الرسم. اختيار التصميم الذي يبقي نطاق الانفجار صغيراً: الانقسام يحدث عند وقت الجمع، وليس عند وقت المبادلة. المبادلة لا تزال تفرض creator_fee_rate وتراكم المبلغ كاملاً إلى creator_fees_token_{0,1}. عندما يعمل CollectCreatorFee أو CollectCreatorFeePermissionless، يتم تقسيم الرصيد المتراكم، وإعادة تسمية جزء البروتوكول كرسم بروتوكول على نفس المجموعة، وفقط جزء المنشئ يترك الخزينة. الاقتباسات والمنحنى و k وكل مسار يواجه LP لم تتأثر.

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

  • كلا تعليمات جمع رسم المنشئ غيّرت قوائم حساباتهما. هذا كسر. يكتسب CollectCreatorFee حساب creator_fee_share في الموضع 5. يكتسب CollectCreatorFeePermissionless حساب amm_config في 5 و creator_fee_share في 6. كلا الإدراجين يجلسان قبل الخزائن، لذا كل شيء بعده ينزاح. أعد بناء هذه المعاملات؛ لا تصلحها.
  • يجب تمرير creator_fee_share حتى عندما لا يكون موجوداً. يتم التصريح عنه بقيد بذرة لكن يُقرأ كحساب غير مفحوص، لذا يجب أن يكون العنوان هو PDA الكنسي في ["creator_fee_share", creator, amm_config] بينما الحساب نفسه اختياري. عندما يكون فارغاً، يعود البرنامج إلى AmmConfig.creator_fee_share_rate.
  • يكتسب AmmConfig حقل creator_fee_share_rate، محفور من الحشو. الحساب لا يزال 236 بايت وكل تكوين موجود يبقى قابلاً للفك — لكن أول u64 من padding: [u64; 15] القديم هو الآن حقل نشط. فكاكات النموذج الذي يمثل الذيل كمصفوفة من 15 عنصراً تقرأ معدل المشاركة كـ padding[0].
  • PoolState لم يتغير. 637 بايت، نفس الإزاحات، نفس الحقول. حصة البروتوكول مسجلة في عدادات protocol_fees_token_{0,1} الموجودة — لا يوجد عداد جديد ولا تعليمة جمع جديدة له.
  • protocol_fees_token* ينمو الآن خارج المبادلات. أي مراقب يوفق بين تراكم البروتوكول مقابل حجم التداول سيرى قفزات عند كل جمع رسم منشئ.
  • مقدّر دفع المنشئ الذي يقرأ creator_fees_token* يبالغ الآن. اضرب في (1 − share_rate / 1_000_000)، محلول لزوج (creator, amm_config) هذا.
  • تمت إضافة تعليمتا إدارة: CreateCreatorFeeShare و CloseCreatorFeeShare. معامل UpdateAmmConfig جديد واحد: 8creator_fee_share_rate.
  • لا توجد أكواد خطأ جديدة. المسارات الجديدة تعيد استخدام InvalidOwner (6001InvalidInput (6003) و MathOverflow (6011). 60006015 لم تتغير.
  • يلزم تحديث IDL — تعليمتان جديدتان، نوع حساب جديد واحد، قائمتا حسابات متغيرتان، حقل تكوين جديد واحد.

كيف يعمل الانقسام

الدقة، بترتيب الأولوية:
  1. CreatorFeeShare PDA في ["creator_fee_share", creator, amm_config] — عندما يكون الحساب موجوداً ومملوكاً بواسطة CPMM، يفوز share_rate الخاص به.
  2. AmmConfig.creator_fee_share_rate — الافتراضي لفئة الرسم، يُستخدم بخلاف ذلك.
كلاهما u64 على FEE_RATE_DENOMINATOR_VALUE = 1_000_000 وكلاهما يُفحص مقابل هذا السقف. ثم، لكل جانب رمز:
ثلاث خصائص تثبتها اختبارات البرنامج:
  • التقريب يفضل المنشئ. المشاركة تنخفض، لذا الغبار يبقى مع المنشئ — نفس الاتجاه مثل Fees::protocol_fee و Fees::fund_fee، التي تحفر أيضاً حصة من رسم مراكم بالفعل. 20% من رسم بوحدة واحدة هو 0، وليس 1.
  • القيمة محفوظة. creator_amount + shared_amount == creator_fee لكل معدل وكل رسم حتى u64::MAX.
  • share_rate = 0 هو بالضبط السلوك القديم. كل من قيمة التكوين الافتراضي و PDA المفقود يعطي المنشئ الرسم كاملاً، لذا لا شيء يتغير لأي مجموعة موجودة حتى يضع المسؤول معدلاً.
لأن protocol_fees_token* و creator_fees_token* كلاهما مطروح بالفعل في vault_amount_without_fee، نقل القيمة بينهما لا يغير رؤية المنحنى للخزينة. لا يرى أي LP تغيير سعر عبر جمع رسم منشئ، والفحص k لم يتغير.
يُقرأ المعدل عند الجمع، وليس عند التراكم. الرسوم التي تراكمت بينما كان المعدل 0 تستقر بأي معدل ساري عندما يستدعي شخص ما Collect* أخيراً. لا توجد لقطة لكل حقبة أو لكل مبادلة.

تغييرات قائمة الحسابات

CollectCreatorFee — إدراج واحد: CollectCreatorFeePermissionless — إدراجان:
لا يفشل أي من التغييرات بصوت عالٍ بطريقة مفيدة. الحسابات المدرجة ليست في نهاية القائمة، لذا العميل القديم لا “يفتقد حساباً” — يسلم البرنامج خزينة حيث يتوقع تكويناً والمعاملة تفشل على فك التسلسل. أعد الإنشاء من IDL الجديد، وتحقق من أن أي إصدار SDK تثبته يحمل الحسابات الجديدة قبل توجيهه إلى البرنامج المرقى.
جداول الحسابات الكاملة في products/cpmm/instructions.

CreateCreatorFeeShare و CloseCreatorFeeShare

CreateCreatorFeeShare(share_rate: u64) يهيئ PDA؛ CloseCreatorFeeShare يغلقه ويعيد الإيجار إلى الموقّع. كلاهما يقبل مسؤول البرنامج المشترك أو مالك مخصص لمشاركة رسم المنشئ — زوج مفاتيح مشفر جديد يتبع نفس نمط cfg devnet/mainnet مثل السلطات المفوضة الأخرى للبرنامج. العناوين في reference/program-addresses. نقاط تستحق الملاحظة:
  • منشئ المجموعة ليس طرفاً في أي من التعليمتين ولا يوقع. حساب creator غير مفحوص — يمكن إنشاء PDA لمفتاح لا يملك مجموعة حتى الآن.
  • حساب واحد يغطي زوج (creator, amm_config)، لذا يحكم كل مجموعة يملكها هذا المنشئ على فئة الرسم تلك. منشئ لديه مجموعات على فئتي رسم يحتاج إلى حسابين ليكون مغطى على كليهما.
  • لا توجد مسار تحديث. init يفشل على إنشاء ثانٍ لنفس الزوج؛ لتغيير معدل، أغلق وأعد الإنشاء.

معامل UpdateAmmConfig 8

يعيّن الافتراضي للمشاركة لفئة الرسم. إنه غير مرتبط بـ protocol_fee_rate (المعامل 1)، الذي ينقسم رسم التداول — نقطة تستحق الحذر بشأنها في أدوات الإدارة، لأن الاثنين يبدوان متشابهين وكلاهما ينزل في protocol_fees_token*.

الركوب معاً

إصلاح ترتيب CollectExcessLamports. التعليمة الآن تجعل مسارين على remaining_accounts — كل CPI لبرنامج الرمز أولاً، ثم الخصومات المباشرة لـ PDAs المملوكة بواسطة CPMM — بدلاً من الإرسال بترتيب المستدعي. كان الفصل بين الاثنين يُجهض مع UnbalancedInstruction (“مجموع أرصدة الحسابات قبل وبعد التعليمة لا تتطابق”) كلما تم خصم PDA قبل CPI، لأن التغييرات المعلقة في lamport للمستدعي يتم فقط تفريغها في الحسابات التي تحملها CPI فعلاً. واجهة التعليمة لم تتغير؛ المستدعون لا يزالون يمررون المصادر بأي ترتيب، والآن هذا آمن حقاً. بيانات وصفية للبناء القابل للتحقق. يصرح Cargo.toml لمساحة العمل بـ [workspace.metadata.cli] solana = "3.1.10"، لذا بناء قابل للتحقق يحل نفس Solana CLI الذي تم بناء البرنامج ضده. لا تأثير على السلسلة.

ما لم يتغير

  • PoolState — 637 بايت، نفس الحقول، نفس الإزاحات. حصة البروتوكول تعيد استخدام الجرافة البروتوكول الموجودة بدلاً من إضافة عدادات خاصة بها.
  • AmmConfig::LEN — لا تزال 236 بايت.
  • رياضيات المبادلة والاقتباس والفحص k. يتم فرض رسم المنشئ بالضبط كما هو الحال من قبل.
  • CollectProtocolFee / CollectFundFee — نفس الحسابات، نفس الموقّعون. CollectProtocolFee ببساطة لديه المزيد للجمع.
  • أكواد الخطأ. 60006015 لم تتغير؛ لا شيء مضاف.
  • كل تعليمة أخرى، ومعرّف البرنامج.

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

  • products/cpmm/fees — قسم جديد “حصة البروتوكول من رسم المنشئ” يغطي دقة المعدل وحساب الانقسام والتقريب والعواقب على المدمج؛ تمت إضافة creator_fee_share_rate إلى قائمة الأسعار/الوحدات وجدول المعاملات الافتراضية؛ تم إعادة صياغة جدول تدفق الجمع.
  • products/cpmm/instructions — تحذير التغيير الكسر في الأعلى؛ جداول حسابات كاملة لكلا مسارات رسم المنشئ؛ أقسام CreateCreatorFeeShare و CloseCreatorFeeShare جديدة؛ معامل UpdateAmmConfig 8؛ ملاحظة ترتيب CollectExcessLamports؛ صفوف الملخص ومصفوفة تغيير الحالة.
  • products/cpmm/accounts — قسم حساب CreatorFeeShare جديد؛ تخطيط AmmConfig وتحذير نقش الحشو؛ ملاحظات عداد الرسم PoolState؛ صفوف دورة حياة الحساب.
  • products/cpmm/overview — استدعاء رسم المنشئ والرصاصة “الرسوم المتوقعة”.
  • products/cpmm/math — ملاحظة أن الانقسام متعمد غائب عن رياضيات المبادلة.
  • products/cpmm/code-demos — تحذير أن منشئي SDK قبل الترقية ينبعثون من قوائم الحسابات القديمة؛ مقتطف الرسم المتراكم معلق.
  • reference/program-addresses — قسم جديد “سلطة مشاركة رسم المنشئ CPMM”؛ تمت إضافة creator_fee_share إلى كتلة بذرة PDA.
  • reference/fee-comparison — يتم استدعاء creator_fee_share_rate كمعدل CPMM رابع بقاعدة مختلفة.