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

​

1. هجمات Sandwich / MEV

​

الهجوم

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

​

التعرض

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

​

الدفاعات

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

​

موقف Raydium

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

​

2. التلاعب بالأسعار

​

الهجوم

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

​

التعرض

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

​

الدفاعات

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

​

موقف Raydium

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

​

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

​

الهجوم

يودع أول LP في مجموعة جديدة مبلغًا صغيرًا (مثلاً، 1 رمز لكل من 6 عملات عشرية → 1 وحدة LP صادرة). ثم يقوم المهاجم بـ “التبرع” بـ 1,000,000 رمز مباشرة إلى خزانة المجموعة عبر نقل SPL Token. الآن 1 وحدة LP تمثل 500,000 من كل عملة. أي 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 لديه آلية مماثلة. يجب على المستخدمين الذين ينشئون مجموعات أن يزرعوا بما لا يقل عن 10,000+ وحدة من كل عملة لجعل هجمات التبرع غير اقتصادية على أي حال.

​

4. إساءة استخدام خطافات Token-2022

​

الهجوم

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

​

التعرض

مجموعات تتضمن عملة بخطاف نقل.

​

الدفاعات

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

​

موقف Raydium

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

​

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

​

الهجوم

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

​

التعرض

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

​

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

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

​

الدفاعات

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

​

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

​

الهجوم

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

​

التعرض

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

​

الدفاعات

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

​

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

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

​

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

​

الهجوم

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

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

​

التعرض

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

​

موقف Raydium

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

​

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

​

الهجوم

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

​

التعرض

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

​

الدفاعات

• يجب على واجهات محفظة التعرف على NFTs موضع Raydium وعرضها بشكل مميز (وليس كـ NFTs عامة للـ “إرسال”).
• يجب أن يكون المستخدمون حذرين من التوقيع على معاملات تنقل NFTs.
• يتم تجميد موضع جديد فقط عندما يستخدم مسار فتح V2 وسلطة تجميد عملة الخزانة الأساسية تطابق قائمة المُصدرين المقيدين بـ CLMM. لا يمكن نقل الموضع المطابق أو تغيير مالك حسابه الرمزي؛ تبقى جميع المواضع الجديدة الأخرى قابلة للنقل.

​

موقف Raydium

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

​

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

​

الهجوم

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

​

التعرض

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

​

الدفاعات

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

​

موقف Raydium

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

​

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

​

الهجوم

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

​

التعرض

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

​

الدفاعات

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

​

موقف Raydium

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

​

جدول الملخص

​

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

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

​

ما يمكن للمدمجين فعله

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

​

المؤشرات

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

المصادر:

• Rekt News — تحليلات DeFi بعد الحادث التي تُعلم هذه القائمة.
• تقارير التدقيق المرتبطة في security/audits.