فشل أوراكل Aave يؤدي إلى تصفيات بقيمة 21.7 مليون دولار في DeFi

في 10 مارس، أدى خطأ تقني في البنية التحتية لـ oracle في Aave إلى تصفيات قسرية، مما اختبر اعتماد DeFi (التمويل اللامركزي) على أنظمة إدارة المخاطر الآلية.

حدث التصفية بقيمة 21.7 مليون دولار على Aave

تكبد مستخدمو Aave خسائر تصفية بلغت تقريباً 21.7 مليون دولار في 10 مارس بعد أن تسبب قيد على السلسلة في وكيل المخاطر الخاص بـ Wrapped stETH (wstETH) في التقليل من قيم أصول ضمانية. في المجمل، تمت تصفية 34 حساباً لأن البروتوكول قيّم wstETH بنسبة 2.85% تقريباً أقل من سعره الحقيقي في السوق.

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

وفقاً لبيانات ما بعد الحادث، بدا أن المستخدمين الذين يحتفظون بـ wstETH كضمانات مقابل ديون WETH لديهم ضمانات غير كافية فقط بسبب التقييم غير الصحيح. علاوة على ذلك، كانت مراكزهم ستبقى آمنة بأسعار السوق الفعلية، مما يؤكد أن الفشل كان في البنية التحتية وليس مدفوعاً بالسوق.

آليات فشل CAPO

نشأ الحادث في نظام CAPO (Correlated Asset Price Oracle) الخاص بـ Aave، المصمم للحماية من التلاعب بالأصول ذات الأسعار المترابطة، مثل wstETH و stETH. يقوم CAPO بجلب نسبة wstETH/stETH من Lido، ويطبق حداً أقصى وقائياً من خلال WstETHPriceCapAdapter، ثم يضرب النتيجة بسعر ETH للحصول على تقييم بالدولار الأمريكي.

في الساعة 12:47 بتوقيت UTC في 10 مارس، أوصى محرك Edge Risk خارج السلسلة التابع لـ Chaos Labs بتحديث السعر الأقصى لـ CAPO إلى 1.1933947 wstETH/ETH. في تلك اللحظة، كانت النسبة الفعلية في السوق 1.2285، مما يعني أن الحد الأقصى المقترح كان بالفعل أقل بكثير من الأسعار السائدة.

نفذت AgentHub التابعة لـ BGD هذه التوصية بعد كتلة واحدة عبر نظام Oracle Automation الخاص بها، دون أي فترة مراجعة بين التوصية خارج السلسلة والتنفيذ على السلسلة. ومع ذلك، فإن هذا المسار الفوري هو بالضبط ما حوّل خطأ التكوين إلى حدث فوري يؤثر على المستخدم.

تسبب عدم التوافق الناتج بنسبة 2.85% في قيام البروتوكول بالتقليل من قيمة ضمانات wstETH. ونتيجة لذلك، تم وضع علامة على الحسابات التي كان يجب أن تكون آمنة وفقاً لبيانات السوق الفعلية على أنها ذات ضمانات غير كافية وتمت تصفيتها. عالجت السلسلة 10,938 wstETH عبر 34 حساباً وأنتجت ما يقرب من 512 ETH في مكافآت التصفية للمصفين قبل اكتشاف المشكلة وعكسها.

السبب الجذري التقني: عدم توافق اللقطة

نشأ الفشل التقني من عدم تطابق المعاملات بين snapshotRatio و snapshotTimestamp داخل CAPO. حسب وكيل المخاطر خارج السلسلة التابع لـ Chaos Labs نسبة مستهدفة تبلغ تقريباً 1.2282، مثبتة بلقطة عمرها 7 أيام. ومع ذلك، قيد النظام على السلسلة مدى سرعة تحرك النسبة.

بموجب القواعد الوقائية لـ CAPO، يمكن للقيمة السابقة على السلسلة البالغة تقريباً 1.1572 أن تزيد فقط بنسبة 3% كل 3 أيام. عملياً، يعني هذا أن النسبة يمكن أن ترتفع فقط إلى حوالي 1.1919 في تحديث واحد، حتى لو كان الهدف خارج السلسلة قد انجرف إلى مستوى أعلى. علاوة على ذلك، لم يتم مواءمة التحديث مع هذه القيود مع منطق الطابع الزمني.

تم تعيين snapshotTimestamp كما لو أن المرساة على السلسلة تعكس بالفعل النسبة خارج السلسلة البالغة 1.2282 والتي عمرها 7 أيام. أدى هذا إلى عدم اتساق حاسم بين مراجع الوقت والسعر. وبالتالي، حسب CAPO سعر صرف أقصى يبلغ تقريباً 1.1939، حوالي 2.85% أقل من سعر السوق الحقيقي البالغ 1.2285.

مثّل هذا الحادث أول تحديث تلقائي تم دفعه على السلسلة بواسطة CAPO Risk Agent التابع لـ Chaos Labs منذ نشره. ومع ذلك، فإن حقيقة أن التنفيذ الافتتاحي أنتج تصفيات للمستخدمين جعلت الخطأ في التكوين مثيراً للقلق بشكل خاص لكل من الحوكمة والمستخدمين.

سلسلة التنفيذ الآلي من Edge Risk إلى AgentHub

Edge Risk هو محرك المخاطر الخاص خارج السلسلة التابع لـ Chaos Labs الذي يعد ويدفع تغييرات المعاملات من عنوان محدد. AgentHub، الذي طورته BGD، يستمع لهذه التغييرات باستخدام Oracle Automation ثم ينشرها إلى البروتوكول.

تحرك تغيير المعامل الخاطئ عبر مجموعة المخاطر الآلية لـ Chaos Labs في تسلسل من معاملتين. أولاً، أوصى محرك Edge Risk بتغيير الحد الأقصى إلى 1.191926 wstETH/ETH في المعاملة 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. بعد ذلك، نفذت AgentHub التغيير بعد كتلة واحدة عبر المعاملة 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.

كانت التصفيات اليومية عبر Aave في فبراير متواضعة نسبياً، ونادراً ما تجاوزت 5 ملايين دولار، حيث ظلت ظروف السوق مستقرة. يبرز ارتفاع 10 مارس إلى 21.6 مليون دولار كحالة شاذة معزولة، بقفزة تبلغ تقريباً 4 أضعاف من المستويات المعتادة. علاوة على ذلك، عادت أحجام التصفية بسرعة إلى خط الأساس بعد التصحيح، مما يؤكد أن الضغط جاء من مسار oracle بدلاً من إعسار البروتوكول الأوسع.

عزز هذا السلوك الاستنتاج بأن مشكلة تسعير wstETH كانت فشلاً منفصلاً في التكوين. لم تكن أعراضاً لتدهور جودة الضمانات أو مشاكل السيولة أو التقصير التلقائي (ADL) النظامي داخل نظام Aave البيئي.

الكشف والتخفيف وخطة تعويض التصفية

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

من خلال تدخل Risk Steward اليدوي، أعاد الفريق مواءمة snapshotRatio مع snapshotTimestamp المباشر، واستعادة موجز oracle إلى قيمته الصحيحة. تم دفع تصحيح oracle عبر المعاملة 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d، بينما تم تنفيذ تغييرات حد الاقتراض لتعيين سعة اقتراض wstETH إلى 1 wstETH عبر المعاملة 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.

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

لتعويض الحسابات المتأثرة، استعاد Aave 141.5 ETH في مكافآت التصفية من خلال استردادات BuilderNet. ثم غطت خزينة DAO الفجوة المتبقية، مع تحديد سقف إعادة المستخدم الإجمالية عند 358 ETH. والأهم من ذلك، تم تنفيذ الخطة عبر مقترح تحسين Aave (AIP) مباشر، مما يضمن حصول المستخدمين المتأثرين على تعويض كامل على الرغم من أن الخطأ نشأ في البنية التحتية.

سياق السوق حول حادث 10 مارس

أظهر النشاط العابر للسلاسل على Aave نمواً قوياً للمستخدمين خلال فترة فبراير-مارس. على سبيل المثال، سجلت Avalanche 38,445 مستخدماً مودعاً في 10 فبراير، بينما سجلت Base 31,763 مستخدماً مودعاً في 6 مارس، قبل أربعة أيام فقط من حدث التصفية المدفوع بـ oracle.

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

يؤكد استقرار الودائع، إلى جانب التطبيع السريع للتصفيات، أن التسعير الخاطئ لـ wstETH نشأ من مشاكل التكوين، وليس من الضغط الأساسي في أسواق الضمانات. ومع ذلك، تظل مخاطر التركيز في مقدمي الأتمتة ومسارات oracle مصدر قلق هيكلي لمنصات DeFi (التمويل اللامركزي) بحجم Aave.

الحوكمة والشفافية ومستقبل تنفيذ oracle الآلي

يوضح حادث 10 مارس المقايضات في الحوكمة التي أنشأها تنفيذ oracle الآلي في بروتوكولات الإقراض الرئيسية لـ DeFi (التمويل اللامركزي). أوصى Edge Risk التابع لـ Chaos Labs بحد أدنى من السوق، ونفذته AgentHub التابعة لـ BGD بعد كتلة واحدة، وتبعت التصفيات في غضون دقائق، مما ترك وقتاً ضئيلاً للتدخل البشري.

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

مع تبني المزيد من بروتوكولات DeFi (التمويل اللامركزي) لأطر CAPO Risk Agent الآلية والأنظمة المماثلة، يُظهر الحادث أن الحوكمة يجب أن تتضمن اختباراً قوياً ونوافذ مراجعة صريحة ورقابة شفافة. علاوة على ذلك، من المحتمل أن تحتاج بنية oracle الأوسع لـ Aave إلى طبقات أمان إضافية، مثل فحوصات متقاطعة متعددة المصادر أو آليات طرح على مراحل، لضمان عدم ترجمة الأخطاء التقنية المستقبلية مباشرة إلى خسائر للمستخدمين.

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