العقود الآجلة
وصول إلى مئات العقود الدائمة
TradFi
الذهب
منصّة واحدة للأصول التقليدية العالمية
الخیارات المتاحة
Hot
تداول خيارات الفانيلا على الطريقة الأوروبية
الحساب الموحد
زيادة كفاءة رأس المال إلى أقصى حد
التداول التجريبي
مقدمة حول تداول العقود الآجلة
استعد لتداول العقود الآجلة
أحداث مستقبلية
"انضم إلى الفعاليات لكسب المكافآت "
التداول التجريبي
استخدم الأموال الافتراضية لتجربة التداول بدون مخاطر
إطلاق
CandyDrop
اجمع الحلوى لتحصل على توزيعات مجانية.
منصة الإطلاق
-التخزين السريع، واربح رموزًا مميزة جديدة محتملة!
HODLer Airdrop
احتفظ بـ GT واحصل على توزيعات مجانية ضخمة مجانًا
منصة الإطلاق
كن من الأوائل في الانضمام إلى مشروع التوكن الكبير القادم
نقاط Alpha
تداول الأصول على السلسلة واكسب التوزيعات المجانية
نقاط العقود الآجلة
اكسب نقاط العقود الآجلة وطالب بمكافآت التوزيع المجاني
كيف أدى فشل أوراكل Aave إلى تصفيات بقيمة 21.7 مليون دولار واختبر حوكمة المخاطر في التمويل اللامركزي
في 10 مارس، أدى خطأ تقني في بنية أوراكل في آيف إلى عمليات تصفية قسرية، مما اختبر اعتماد التمويل اللامركزي على أنظمة المخاطر الآلية.
حادثة تصفية بقيمة 21.7 مليون دولار على آيف
تضرر مستخدمو آيف بما يقرب من 21.7 مليون دولار من عمليات التصفية في 10 مارس بعد أن تسبب قيد على السلسلة في وكيل مخاطر Wrapped stETH (wstETH) في تقليل قيمة الضمان بشكل غير صحيح. في المجمل، تم تصفية 34 حسابًا لأن البروتوكول قدر قيمة wstETH بأقل حوالي 2.85% من سعر السوق الحقيقي.
في النهاية، لم يتحمل البروتوكول ديونًا سيئة وقدم تعويضات للمستخدمين المتضررين. ومع ذلك، كشفت الحادثة عن ضعف هيكلي في كيفية تنفيذ إدارة مخاطر التمويل اللامركزي الآلية للتغييرات بدون تدخل بشري. كما أظهرت مدى سرعة تحول معلمة غير مضبوطة إلى عمليات تصفية واسعة النطاق لمراكز كانت صحية بخلاف ذلك.
وفقًا لبيانات ما بعد الحادث، بدا أن المستخدمين الذين يحملون wstETH كضمان مقابل ديون WETH غير مغطين بشكل كافٍ فقط بسبب التقييم غير الصحيح. علاوة على ذلك، كانت مراكزهم ستظل آمنة عند الأسعار الحقيقية للسوق، مما يؤكد أن الفشل كان بنيويًا وليس ناتجًا عن السوق.
آلية فشل CAPO
بدأت الحادثة في نظام CAPO (أوراكل أسعار الأصول المرتبطة) الخاص بآيف، المصمم للحماية من التلاعب بأسعار الأصول المرتبطة، مثل wstETH و stETH. يقوم CAPO بجلب نسبة wstETH/stETH من ليدو، ويطبق حد حماية عبر WstETHPriceCapAdapter، ثم يضرب الناتج في سعر ETH للحصول على تقييم بالدولار الأمريكي.
في 10 مارس، الساعة 12:47 بالتوقيت العالمي، أوصى محرك المخاطر الخارجي Chaos Labs بتحديث الحد الأقصى لسعر CAPO إلى 1.1933947 wstETH/ETH. في ذلك الوقت، كانت النسبة السوقية الفعلية عند 1.2285، مما يعني أن الحد المقترح كان أقل بشكل كبير من الأسعار السائدة.
نفذ AgentHub التوصية بعد بلوك واحد عبر نظام الأوراكل الآلي، دون مراجعة بين التوصية على السلسلة والتنفيذ. هذا التدفق الفوري هو ما حول خطأ التكوين إلى حدث يؤثر مباشرة على المستخدمين.
الاختلاف البالغ 2.85% أدى إلى تقليل قيمة الضمان wstETH بشكل غير صحيح. ونتيجة لذلك، تم تصنيف حسابات كانت آمنة وفقًا لبيانات السوق الحقيقية على أنها غير مغطاة وتم تصفيتها. شمل هذا التدفق 10,938 wstETH عبر 34 حسابًا وحقق حوالي 512 ETH كمكافآت تصفية للمصفين قبل اكتشاف المشكلة وعكسها.
السبب الفني: عدم توافق اللقطة
نشأ الفشل التقني من عدم تطابق بين parameter snapshotRatio و snapshotTimestamp داخل CAPO. حسب محرك المخاطر الخارجي Chaos Labs، كان الهدف هو نسبة حوالي 1.2282 مستندة إلى لقطة قديمة عمرها 7 أيام. لكن النظام على السلسلة قيد سرعة تغير النسبة.
وفقًا لقواعد حماية CAPO، كانت القيمة السابقة على السلسلة حوالي 1.1572 يمكن أن تزيد بنسبة 3% فقط كل 3 أيام. عمليًا، كان يمكن أن ترتفع النسبة إلى حوالي 1.1919 في تحديث واحد، حتى لو كانت الهدف الخارجي أعلى. والأهم أن التحديث لم يدمج هذه القيود مع منطق الطابع الزمني.
تم ضبط snapshotTimestamp كما لو أن المرجع على السلسلة يعكس بالفعل النسبة القديمة 1.2282، مما أدى إلى عدم توافق حاسم بين الوقت والسعر. ونتيجة لذلك، حسب CAPO معدل تبادل أقصى حوالي 1.1939، أقل بنسبة 2.85% من السعر الحقيقي 1.2285.
كانت هذه أول عملية تحديث آلية يتم دفعها على السلسلة بواسطة وكيل مخاطر CAPO الخاص بـ Chaos Labs منذ إطلاقه. ومع أن التنفيذ الأول أدى إلى تصفية المستخدمين، إلا أن ذلك زاد من قلق الحوكمة والمستخدمين بشأن خطورة التكوين غير الصحيح.
سلسلة التنفيذ الآلي من Edge Risk إلى AgentHub
Edge Risk هو محرك المخاطر الخارجي المملوك لـ Chaos Labs، الذي يجهز ويدفع تغييرات المعلمات من عنوان معين. يستمع AgentHub، الذي طورته BGD، لهذه التغييرات عبر Oracle Automation ثم ينشرها على البروتوكول.
انتقلت التغييرات الخاطئة عبر سلسلة المخاطر الآلية في خطوتين. أولاً، أوصى محرك Edge Risk بتغيير الحد إلى 1.191926 wstETH/ETH في المعاملة 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. ثم نفذ AgentHub التغيير بعد بلوك واحد عبر المعاملة 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.
كانت عمليات التصفية اليومية على آيف في فبراير معتدلة، نادراً ما تجاوزت 5 ملايين دولار، مع استقرار ظروف السوق. أما في 10 مارس، فبلغت القيمة 21.6 مليون دولار، وهو ارتفاع كبير يقارب أربعة أضعاف المستويات المعتادة. وبعد التصحيح، عادت أحجام التصفية إلى المستويات الطبيعية، مما يؤكد أن الضغط جاء من مسار الأوراكل وليس من أزمة عامة في البروتوكول.
هذا السلوك عزز الاستنتاج أن مشكلة تسعير wstETH كانت فشل تكوين منفصل، وليس علامة على تدهور جودة الضمان أو مشاكل السيولة أو تقليل الرافعة المالية بشكل منهجي في نظام آيف.
التعرف على المشكلة، والتخفيف، وخطة تعويض التصفية
تم اكتشاف التكوين غير الصحيح خلال دقائق، مما دفع فريق آيف ومزودي المخاطر إلى استجابة سريعة. لاحتواء المزيد من التعرض، تم تقليل حدود اقتراض wstETH على كل من آيف كور و آيف برايم إلى 1، مما أوقف بشكل فعال عمليات الاقتراض الجديدة ضد هذا الأصل.
بواسطة تدخل يدوي من Risk Steward، أعاد الفريق ضبط نسبة اللقطة لتتوافق مع الطابع الزمني المباشر، واستعاد تغذية الأوراكل إلى قيمتها الصحيحة. تم دفع تصحيح الأوراكل عبر المعاملة 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d، بينما تم تنفيذ تغييرات حد الاقتراض لتحديد قدرة اقتراض wstETH إلى 1 عبر المعاملة 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.
على الرغم من البيع القسري، لم يتحمل البروتوكول ديونًا سيئة وقدم تقريرًا تفصيليًا بعد الحادث إلى منتديات حوكمة آيف. ومع ذلك، استلزمت خسائر المستخدمين من التصفية خطة تعويض منظمة، وأدت إلى خطة تعويض مبرم.
لتعويض الحسابات المتضررة، استعاد آيف 141.5 ETH كمكافآت تصفية عبر استردادات BuilderNet. ثم غطت خزينة DAO الفجوة المتبقية، مع حد أقصى لتعويض المستخدمين يبلغ 358 ETH. والأهم أن الخطة نفذت عبر اقتراح تحسين مباشر لآيف (AIP)، لضمان تعويض كامل للمستخدمين المتضررين رغم أن الخطأ نشأ في البنية التحتية.
السياق السوقي حول حادثة 10 مارس
أظهرت أنشطة التبادل عبر السلاسل على آيف نموًا قويًا للمستخدمين خلال الفترة من فبراير إلى مارس. على سبيل المثال، سجلت Avalanche 38,445 مستخدمًا يودعون في 10 فبراير، بينما سجلت Base 31,763 مستخدمًا في 6 مارس، قبل أربعة أيام من حادثة التصفية المدفوعة بالأوراكل.
تسلط هذه الارتفاعات الضوء على تزايد تفاعل المستخدمين عبر شبكات آيف المدعومة، حتى مع تصدي البروتوكول لحادث تقني معقد. علاوة على ذلك، ظلت إجماليات الودائع والاقتراضات مستقرة طوال أوائل 2026، مما يشير إلى أن الثقة في تصميم البروتوكول لم تتراجع بشكل جوهري بعد الحادث.
ثبات الودائع، مع عودة التصفية بسرعة إلى المستويات الطبيعية، يؤكد أن مشكلة تسعير wstETH كانت ناتجة عن أخطاء تكوينية، وليس عن ضغوط أساسية في أسواق الضمان. ومع ذلك، يبقى خطر التركيز في مزودي الأتمتة ومسارات الأوراكل مشكلة هيكلية لمنصات التمويل اللامركزي على نطاق آيف.
الحوكمة، الشفافية، ومستقبل تنفيذ الأوراكل الآلي
توضح حادثة 10 مارس التحديات التي تفرضها الحوكمة عند الاعتماد على تنفيذ الأوراكل الآلي في بروتوكولات الإقراض اللامركزي الكبرى. أوصى Chaos Labs’ Edge Risk بحد أدنى أقل من السوق، نفذه AgentHub بعد بلوك واحد، وتبع ذلك عمليات تصفية خلال دقائق، مع عدم وجود وقت كافٍ للتدخل البشري.
استجابت آيف بسرعة من خلال الكشف المبكر، واتخاذ إجراءات تصحيحية حاسمة، وتعويض كامل للمستخدمين، تم تمويل جزء منه من خزينة DAO. ومع ذلك، أظهرت الحادثة قصورًا في التحقق قبل التنفيذ وأبرزت مخاطر الاعتماد المفرط على محرك مخاطر خاص واحد. خاصة أن الطبيعة المغلقة لحسابات Chaos Labs Edge Risk تحد من التحقق المستقل وتضع السيطرة التشغيلية الكبرى في يد مقدمي الخدمات الخارجيين.
مع تبني المزيد من بروتوكولات التمويل اللامركزي لنُظم وكيل مخاطر CAPO الآلي وأنظمة مماثلة، تظهر الحادثة أن الحوكمة يجب أن تتضمن اختبارات قوية، وفترات مراجعة واضحة، وشفافية في الرقابة. بالإضافة إلى ذلك، من المحتمل أن يحتاج بنية أوراكل آيف إلى طبقات أمان إضافية، مثل التحقق من مصادر متعددة أو آليات نشر تدريجي، لضمان عدم ترجمة الأخطاء التقنية المستقبلية مباشرة إلى خسائر للمستخدمين.
باختصار، لم تكن تصفيات 10 مارس أزمة سوق، بل كانت اختبارًا لضغط الحوكمة والبنية التحتية. إن الجمع بين الأتمتة والتنفيذ السريع والنماذج غير الشفافة للمخاطر يبرز أهمية موازنة كفاءة العمليات مع تدابير شفافة وقابلة للمراجعة لحماية المستخدمين.