Baru saja saya mengikuti apa yang terjadi dengan kejadian likuidasi Aave pada bulan Maret lalu, dan jujur saja penyebab utamanya cukup gila. Chaos Labs merilis analisis mereka dan pada dasarnya mengonfirmasi bahwa ini adalah masalah konfigurasi oracle klasik - jenis masalah yang bisa menyebabkan masalah serius jika tidak diawasi dengan ketat.

Jadi begini yang terjadi: oracle risiko CAPO mengalami masalah batasan di mana parameter snapshotRatio dibatasi hanya 3% pertumbuhan setiap 3 hari. Parameter ini perlu melonjak dari sekitar 1.1572 menjadi 1.2282, tetapi hanya bisa naik hingga 1.1919. Sementara itu, snapshotTimestamp hanya diperbarui secara normal ke timestamp dari 7 hari yang lalu. Ketidaksesuaian antara kedua parameter ini? Di situlah semuanya mulai gagal.

Karena ketidaksesuaian itu, batas kurs tukar yang dihitung oleh CAPO akhirnya sekitar 2.85% lebih rendah dari kurs pasar sebenarnya - sekitar 1.1939 versus kenyataan. Celah ini memicu likuidasi sekitar 10.938 wstETH. Tidak kecil juga. Bagian yang gila adalah protokol itu sendiri tidak mengalami kerugian utang buruk, jadi setidaknya ada itu.

Yang menarik adalah seberapa cepat responsnya. Chaos Labs dan BGD Labs langsung menanggapi, menurunkan batas pinjaman wstETH menjadi 1 untuk menghentikan rantai likuidasi lebih lanjut, dan secara manual menyelaraskan parameter melalui Risk Steward. Mereka mendapatkan kembali 141.5 ETH melalui BuilderNet untuk mulai mengompensasi pengguna, dengan cadangan Aave menanggung sisanya. Total kompensasi DAO yang dibutuhkan? Diperkirakan di bawah 345 ETH.

Seluruh skenario likuidasi ini menjadi pengingat yang solid tentang betapa sensitifnya sistem oracle ini. Satu kesalahan konfigurasi dan tiba-tiba Anda menghadapi puluhan juta dalam pergerakan tak terduga. Pastinya sesuatu yang perlu dipantau jika Anda memegang posisi di protokol ini.