باستخدام 200,000 لشراء ما يقرب من مليار، عملات الاستقرار في التمويل اللامركزي تتعرض لهجمات مرة أخرى

كتبه: إريك، أخبار فوري سايت

في تمام الساعة 10:21 بتوقيت بكين اليوم، تعرضت Resolv Labs، التي تستخدم استراتيجية Delta المحايدة لإصدار العملة المستقرة USR، لهجوم من قراصنة. استخدم عنوان يبدأ بـ 0x04A2 مبلغ 100,000 USDC لصك 50,000,000 USR من بروتوكول Resolv Labs.

مع ظهور هذا الحدث، انخفض USR إلى حوالي 0.25 دولار، وحتى وقت كتابة هذا المقال، ارتفع إلى حوالي 0.8 دولار. كما انخفض سعر رمز RESOLV بنسبة قريبة من 10% لفترة قصيرة.

بعد ذلك، قام القراصنة بنفس الأسلوب مرة أخرى باستخدام 100,000 USDC لصك 30,000,000 USR. مع الانخفاض الكبير في USR، تحرك المتداولون السريعون، حيث تم استنفاد العديد من أسواق الإقراض المدعومة بـ USR و wstUSR على Morpho، وأوقفت Lista DAO على شبكة BNB الطلبات الجديدة للقروض.

لم تتأثر هذه البروتوكولات فقط. في تصميم بروتوكول Resolv Labs، يمكن للمستخدمين أيضًا صك رمز RLP الذي يتميز بتقلبات أكبر في الأسعار، وعوائد أعلى، ولكن يتطلب تحمل المسؤولية عن التعويض عندما يتكبد البروتوكول خسائر. حالياً، يبلغ إجمالي تداول رموز RLP حوالي 30,000,000، حيث يمتلك أكبر مالك، Stream Finance، أكثر من 13,000,000 RLP، مما يشير إلى تعرض صافٍ للمخاطر بحوالي 17,000,000 دولار.

لا، Stream Finance، التي تأثرت سابقًا بسبب انهيار xUSD، قد تتعرض لضربة أخرى.

حتى وقت كتابة هذا المقال، قام القراصنة بتحويل USR إلى USDC و USDT، واستمروا في شراء الإيثيريوم، حيث تم شراء أكثر من 10,000 وحدة. استخدموا 200,000 USDC للحصول على أصول تتجاوز 20,000,000 دولار، حيث وجد القراصنة في سوق هابطة “عملة بمئة ضعف” تخصهم.

مرة أخرى بسبب “عدم الدقة” يُستغل الأمر

أدى الانهيار الكبير في 11 أكتوبر من العام الماضي إلى تكبد الكثير من العملات المستقرة التي تستخدم استراتيجية Delta المحايدة خسائر في الضمانات بسبب ADL (الخفض التلقائي للرافعة). تكبدت بعض مشاريع الأصول التي تستخدم العملات البديلة كاستراتيجية تنفيذ خسائر أكثر فداحة، بل حتى اختفت.

تستخدم Resolv Labs، التي تعرضت للهجوم هذه المرة، آلية مشابهة لإصدار USR، حيث أعلنت المشروع في أبريل 2025 عن إكمال جولة تمويل أولية بقيمة 10 ملايين دولار بقيادة Cyber.Fund و Maven11، وبمشاركة Coinbase Ventures، وتم إطلاق رمز RESOLV في أواخر مايو وأوائل يونيو.

لكن أسباب هجوم Resolv Labs ليست الظروف القاسية، بل تصميم آلية صك USR “غير الدقيق”.

لم تقم أي شركة أمنية أو جهة رسمية بعد بتحليل أسباب وقوع هذا الهجوم. وقد استنتج مجتمع DeFi YAM من خلال التحليل أن الهجوم ربما كان نتيجة السيطرة على SERVICE_ROLE المستخدمة في الجزء الخلفي من البروتوكول لتقديم المعلمات لعقد الصك.

وفقًا لتحليل Grok، عند صك USR، يقوم المستخدم بإرسال طلب على السلسلة، ويستدعي وظيفة requestMint للعقد، وتشمل المعلمات:

_depositTokenAddress: عنوان الرمز المدخل؛

_amount: كمية الإدخال؛

_minMintAmount: الحد الأدنى المتوقع من USR (لتجنب الانزلاق).

بعد ذلك، يقوم المستخدم بإيداع USDC أو USDT في العقد، ويراقب SERVICE_ROLE في الجزء الخلفي من المشروع الطلبات، ويستخدم Oracle Pyth للتحقق من قيمة الأصول المدخلة، ثم يستدعي وظائف completeMint أو completeSwap لتحديد كمية USR الفعلية التي سيتم صكها.

المشكلة تكمن في أن عقد الصك يثق تمامًا في _mintAmount المقدم من SERVICE_ROLE، معتقدًا أن الرقم تم التحقق منه خارج السلسلة بواسطة Pyth، لذا لم يتم تعيين حد أقصى، ولم يتم التحقق بواسطة Oracle على السلسلة، وتم تنفيذ mint(_mintAmount) مباشرة.

على هذا الأساس، يشتبه YAM في أن القراصنة سيطروا على SERVICE_ROLE التي كان ينبغي أن تتحكم فيها الجهة المسؤولة عن المشروع (ربما بسبب فقدان السيطرة على Oracle الداخلي، أو سرقة مفاتيح، أو غير ذلك)، وحددوا مباشرة _mintAmount ليكون 50,000,000، مما أدى إلى الهجوم الذي صك 50,000,000 USR مقابل 100,000 USDC.

في النهاية، توصل Grok إلى استنتاج مفاده أن Resolv لم تأخذ في الاعتبار أثناء تصميم البروتوكول احتمال أن يتم السيطرة على العنوان (أو العقد) المستخدم لاستقبال طلبات صك المستخدم، وعند تقديم طلب صك USR إلى العقد النهائي، لم يتم تعيين حد أقصى للصك، ولم يتم اعتماد Oracle على السلسلة لإجراء تحقق ثانٍ، بل تم الوثوق بجميع المعلمات المقدمة من SERVICE_ROLE مباشرة.

الوقاية أيضًا غير كافية

بجانب الافتراضات حول أسباب الهجوم، أشار YAM أيضًا إلى عدم استعداد الجهة المسؤولة عن التعامل مع الأزمة بشكل كافٍ.

أفاد YAM على X أن Resolv Labs قامت بتعليق البروتوكول بعد 3 ساعات من الهجوم الأول، حيث كان هناك تأخير لمدة ساعة تقريبًا نتيجة الحاجة إلى جمع 4 توقيعات للمعاملة متعددة التوقيع. ويعتقد YAM أن التعليق الطارئ ينبغي أن يتطلب توقيعًا واحدًا فقط، وأن يتم توزيع الصلاحيات على أعضاء الفريق، أو أفراد موثوق بهم من خارج الفريق، مما يزيد من الانتباه للحالات الشاذة على السلسلة، ويعزز احتمال التعليق السريع، ويغطي بشكل أفضل المناطق الزمنية المختلفة.

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

لقد تجاوزت هجمات القراصنة على بروتوكولات DeFi بالفعل الثغرات التعاقدية، وتقدم حادث Resolv Labs تحذيرًا للمشاريع بأن الفرضيات حول أمان البروتوكول يجب ألا تثق بأي حلقة، وكل عنصر مرتبط بالمعلمات يجب أن يتم التحقق منه على الأقل مرتين، حتى لو كان ذلك بالنسبة للجزء الخلفي الذي تديره الجهة المسؤولة عن المشروع.