متجهات الهجوم

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.

​

1. هجمات الساندويتش / MEV

​

الهجوم

يراقب بوت مجموعة الذاكرة / تدفق gossip، ويرى عملية المبادلة الخاصة بالمستخدم، ويتقدمها بعملية شراء في نفس الاتجاه (لدفع السعر)، ويسمح بتنفيذ معاملة المستخدم بسعر أسوأ، ثم يعقبها ببيع معاكس. يحقق البوت ربح الفارق.

​

التعرض

• الأكثر تعرضًا: CPMM pools منخفضة TVL و AMM v4 pools — حتى الصفقات الصغيرة تغير السعر بشكل كبير.
• أقل تعرضًا: CLMM pools العميقة — الصفقات داخل التك لا تغير السعر.
• غير معرضة: حصاد المزارع وإيداعات LP (يتم فرض النسبة، وليست حساسة للسعر بنفس الطريقة).

​

الدفاعات

• Jito bundles (integration-guides/routing-and-mev) تخفي المعاملة من مجموعة الذاكرة العامة.
• slippage محكم — حد أدنى للمخرجات أقرب إلى المتوقع يجعل الساندويتش غير مربح. أقل من ~0.3%، معظم هجمات الساندويتش تخسر المال.
• أحجام صفقات أصغر — قسّم مبادلة بقيمة 100 دولار إلى 10 × 10 دولارات؛ كل واحدة تغير السعر أقل.

​

موقف Raydium

لا تفرض برامج Raydium الأساسية حماية مضادة لـ MEV — فهي محايدة على مستوى البرنامج. الحماية تحدث على طبقة الإرسال (Jito والحماية المدمجة في المحافظ). واجهة المستخدم تعيّن slippage الافتراضي إلى 0.5% وهو معقول لمعظم المجموعات.

​

2. معالجة السعر

​

الهجوم

يقوم متاجر كبير بتحريك سعر مجموعة المتداول مؤقتًا (عن طريق قرض فلاش أو تمويل ذاتي)، مما يؤدي إلى تنفيذ إجراء لاحق يعتمد على السعر (تصفية أو استدانة مشتقة من oracle أو دفع مشتق)، ثم يعيد السعر إلى طبيعته.

​

التعرض

• عمليات Raydium الأصلية: غير معرضة. مبادلة فورية داخل وخارج تتكبد فقط رسوم الرحلة ذهابًا وإيابًا؛ يخسر المتاجر المال.
• البرامج المتكاملة: معرضة إذا كانت تقرأ سعر مجموعة Raydium بطريقة ساذجة.

​

الدفاعات

• استخدم TWAPs، وليس الأسعار الفورية، للتركيب (انظر security/oracle-and-token-risks).
• CLMM ObservationState توفر TWAP لنافذة قصيرة لا يمكن معالجتها بدون التزام رأس مال مستدام.
• توافق multi-oracle: إذا كان برنامجك يقرأ Raydium و Pyth و Jupiter والعمل فقط عندما تتفق ضمن 1%، فإن معالجة قرض فلاش لأي مصدر واحد غير كافية.

​

موقف Raydium

يأتي CLMM مع دعم TWAP ObservationState؛ المتكاملون الذين يتجاهلونها ويستخدمون الأسعار الفورية يكونون بمفردهم. تستخدم واجهة Raydium الأمامية مصادر أسعار متعددة للعرض بالدولار الأمريكي.

​

3. هجمات التبرع / التضخم

​

الهجوم

يودع أول LP في مجموعة جديدة مبلغًا ضئيلاً (على سبيل المثال، رمز واحد من كل نعناع بـ 6 عشريات → 1 وحدة LP صادرة). بعد ذلك، يقوم المهاجم بـ “التبرع” بـ 1000000 رمز مباشرة إلى خزانة المجموعة عبر نقل SPL Token. الآن 1 وحدة LP تمثل 500000 من كل نعناع. أي LP لاحق يودع أقل من ذلك يتم تقريبه إلى 0 وحدة LP ويخسر الإيداع.

​

التعرض

• CPMM / AMM v4: قد تكون معرضة في المجموعات المنشأة حديثًا منخفضة السيولة.
• CLMM: غير معرضة (لا نعناع LP مشترك؛ كل موضع هو NFT خاص به مع قيمة سيولة صريحة).

​

الدفاعات

تقفل تعليمات initialize الخاصة بـ CPMM مبلغًا أدنى من LP في المجموعة (مستوحاة من نمط MINIMUM_LIQUIDITY في Uniswap V2). هذا يعني أن أول LP يتلقى sqrt(x × y) - MINIMUM_LIQUIDITY، مع حرق MINIMUM_LIQUIDITY (1000 وحدة) إلى null. يتطلب هجوم التبرع أن يتبرع المهاجم >> الإيداع الأولي، الذي يصبح غير اقتصادي. بالإضافة إلى ذلك، يحذر SDK الخاص بـ Raydium بصراحة عندما يكون الإيداع الأولي صغيرًا ويوجه المستخدمين نحو مبالغ معقولة.

​

موقف Raydium

يأتي قفل MINIMUM_LIQUIDITY مع CPMM؛ AMM v4 له آلية مشابهة. يجب على المستخدمين الذين ينشئون مجموعات أن يبدأوا برصيد 10000+ وحدة على الأقل من كل نعناع لجعل هجمات التبرع غير اقتصادية على أي حال.

​

4. استغلال transfer-hook في Token-2022

​

الهجوم

يكون transfer hook للنعناع قابلاً للترقية. يقوم المهاجم بنشر hook بريء عند إطلاق النعناع، يحصل على قائمة في Raydium، يتراكم LP من المستخدمين. لاحقًا، يرقي hook لحظر جميع التحويلات (فعليًا soft-rug — لا يمكن للمستخدمين الانسحاب). يجعل المهاجم المجموعة قابلة للتداول في اتجاه واحد فقط، يشتري LP بسعر منخفض، يفتح hooks، يفوز.

​

التعرض

المجموعات التي تتضمن نعناع transfer-hook.

​

الدفاعات

• مستوى البرنامج: تستدعي برامج Raydium hook أثناء المبادلات؛ إذا حجب hook، تتراجع المبادلة. هذا لا يمنع الهجوم ميكانيكيًا.
• مستوى واجهة المستخدم: تعلم Raydium المجموعات ذات أنواع mint transfer-hook.
• مستوى المتكامل: يجب على المجمعات تخطي أنواع mint transfer-hook بشكل افتراضي والسماح بقائمة أنواع hooks المتحققة فقط.

​

موقف Raydium

لا تحظر Raydium مجموعات transfer-hook (توجد hooks مشروعة)، لكن تضع علامات عليها بوضوح. يمكن للمجمعات التي تقوم بالتصفية على tags.includes("TRANSFER_HOOK") استبعادها إذا أرادت.

​

5. استغلالات التركيب / CPI

​

الهجوم

يقوم برنامج بتكوين Raydium عبر CPI وقدم خطأ: مثلاً، يمرر observation_state خاطئة، أو tick arrays خاطئة لمبادلة CLMM، أو ينفق حسابًا مرتين. يحدد المهاجم التكوين الخاطئ ويستغله.

​

التعرض

• المتكامل الخاطئ — عادة مصدر الخطأ.
• Raydium — فقط إذا كان الخطأ ينجز سلوكًا غير مقصود في برامج Raydium نفسها.

​

أمثلة تاريخية

لم يتم استغلال أي من برامج Raydium عبر CPI — مدققو حسابات Raydium يمسكون بالحسابات المشوهة ويتراجعون. حدثت الاستغلالات في النظام البيئي الأوسع عبر أخطاء برنامج مخصص تركبت مع AMM لكن لم تنشأ من AMM.

​

الدفاعات

• يجب على البرامج الاستدعائية استخدام مساعدي Anchor CPI (وليس التعليمات المبنية يدويًا) عند الإمكان — الأمان النوعي يمسك معظم الاستخدام الخاطئ.
• اختبارات التكامل مقابل حالة mainnet-forked تغطي حالات التكوين.

​

6. اختراق المفاتيح / الإدارة

​

الهجوم

يتم اختراق مفتاح إداري (سلطة الترقية، مسؤول AmmConfig، مطالبة رسوم البروتوكول). ينشر المهاجم ترقية خبيثة تستنزف المجموعات، أو تعديل AmmConfigs لتوجيه الرسوم إلى محفظة المهاجم، أو تستنزف رسوم البروتوكول.

​

التعرض

جميع الأدوار الموثقة في security/admin-and-multisig.

​

الدفاعات

• multisig 3/4 على سلطة الترقية يتطلب اختراق 4 موقعين مستقلين.
• 24 ساعة timelock على الترقيات يعطي المستخدمين وقتًا للانسحاب قبل تنشيط ترقية خبيثة.
• المراقبة التشغيلية — تنبيهات على أي نشاط multisig عبر قائمة انتظار Squads العامة.

​

حادثة تاريخية

تم اختراق مفتاح سلطة مجموعة AMM v4 في ديسمبر 2022 (ما قبل multisig). الإصلاح: نقل جميع السلطات إلى Squads multisig. بعد الإصلاح، لم تحدث حوادث.

​

7. هجمات اقتصادية على رياضيات CLMM tick

​

الهجوم

يستغل مهاجم متطور حالات التقريب أو محاسبة الرسوم على حافة رياضيات CLMM tick. أمثلة تم العثور عليها في تطبيقات CLMM أخرى (وليس Raydium):

• محاسبة نمو الرسوم التي تقرب ضد المستخدم، تتراكم الأتربة.
• عبور tick يودع / يخصم delta fee_growth الخاطئ.
• تجاوز عدد صحيح في منتجات sqrtPrice * liquidity.

​

التعرض

رياضيات معقدة مخصصة. التدقيق والـ fuzzing هما الدفاع الأساسي.

​

موقف Raydium

قد يكون CLMM قد خضع لتدقيقين مستقلين (OtterSec + MadShield) بالإضافة إلى fuzzing قائم على خصائص جارٍ. لم يتم العثور على خطأ ذي تأثير إنتاجي حتى الآن. يستخدم sqrt_price_x64 حسابات Q64.64 رياضيات مشبعة 128-بت مع اختبارات وحدة تغطي ticks الحدودية.

​

8. التباس NFT الموضع

​

الهجوم

يتم خداع المستخدم لتوقيع معاملة تنقل NFT موضع CLMM الخاص به إلى المهاجم. يمتلك المهاجم الآن سيولة الموضع.

​

التعرض

أي حامل موضع NFT.

​

الدفاعات

• يجب على محافظ UIs التعرف على موضع Raydium NFTs وعرضها بشكل مميز (وليس كـ NFTs عامة للـ “إرسال”).
• يجب على المستخدمين توخي الحذر من توقيع المعاملات التي تنقل NFTs.

​

موقف Raydium

تطبق موضع NFTs معيار metadata Metaplex؛ تطبيقات المحفظة التي تفهم مواضع CLMM تعرضها كمواضع سيولة وليس NFTs قابلة للتداول. معظم محافظ Solana الرئيسية تعرضها بشكل خاص اعتبارًا من عام 2026.

​

9. معالجة تدفق مكافآت المزرعة

​

الهجوم

ينشئ منشئ مزرعة خزانة المكافآت ويجذب أصحاب الرهان، ثم يستدعي restartRewards بمعاملات تجعل حساب المكافآت المعلقة معقدًا، سرقة قيمة الحصاد.

​

التعرض

المزارع ذات المنشئين الخبيثين. Farm v6 يحد من قوى المنشئ بإحكام؛ هذا الهجوم لا يعمل.

​

الدفاعات

تحافظ تعليمات إدارة Farm v6 (setRewards, restartRewards, addReward) على حقوق pro-rata — يتم تعديل reward_per_share في لحظة التغيير، لذلك لا يتم إفساد أي استحقاق سابق للتغيير بأثر رجعي.

​

موقف Raydium

اختبر تدقيق OtterSec للمزرعة بشكل خاص سيناريوهات restart-rewards؛ لم يتم العثور على استغلال.

​

10. تباعد المحاكاة مقابل التنفيذ

​

الهجوم

ينشئ مهاجم معاملة تحاكي بنجاح لكنها تتراجع عند التنفيذ (أو العكس). يُستخدم للتشويش على المحافظ التي تعتمد على المحاكاة للعرض.

​

التعرض

المحافظ التي تعرض “ستتلقى X” بناءً على المحاكاة.

​

الدفاعات

• استخدم simulateTransaction مع نفس blockhash كالإرسال الفعلي.
• اعرض المخرجات المتوقعة كـ ”≈” (تقريبًا) وليس دقيق.
• أعد المحاكاة مباشرة قبل الإرسال.

​

موقف Raydium

محاكاة CLMM حتمية نظرًا لحالة المجموعة الحالية؛ التباعد يحدث فقط إذا تغيرت الحالة بين المحاكاة والتنفيذ (حالة عادية، تُعالج عبر حدود slippage).

​

جدول الملخص

​

ما يمكن للمستخدمين فعله

• استخدم slippage محكم بشكل افتراضي؛ ارفعه فقط عند الحاجة.
• استخدم محافظ / تدفقات مبادلة مفعلة بـ Jito.
• تحقق من ملحقات النعناع قبل LP.
• راقب multisig Squads للترقيات المعلقة.
• تنوع عبر المجموعات؛ لا تركز كل LP الخاص بك في مجموعة إطلاق جديدة واحدة.

​

ما يمكن للمتكاملين فعله

• استخدم ObservationState TWAPs لتسعير المشتقات.
• تحقق من قيود الحساب عند التكوين عبر CPI.
• رشح المجموعات حسب حقل tags (تخطي scam, honeypot, transfer-hook غير المتحقق).
• اضبط حدود slippage معقولة؛ لا تقبل 0 slippage من إدخال المستخدم.
• استخدم simulateTransaction بحذر — وثق أنها تقدير.

​

المؤشرات

• security/oracle-and-token-risks — مخاطر Token-2022 بعمق.
• security/admin-and-multisig — هيكل السلطة.
• security/disclosure — برنامج مكافأة الأخطاء.
• integration-guides/routing-and-mev — تخفيفات MEV.

المصادر:

• Rekt News — post-mortems DeFi تفيد هذه القائمة.
• تقارير التدقيق المرتبطة في security/audits.