Bagaimana kegagalan oracle Aave memicu likuidasi senilai $21.7M dan menguji tata kelola risiko DeFi

Pada 10 Maret, kesalahan konfigurasi teknis dalam infrastruktur oracle aave menyebabkan likuidasi paksa, menguji ketergantungan DeFi pada sistem risiko otomatis.

Peristiwa likuidasi sebesar $21,7 juta di Aave

Pengguna Aave mengalami sekitar $21,7 juta dalam likuidasi pada 10 Maret setelah adanya kendala di rantai dalam agen risiko Wrapped stETH (wstETH) yang menyebabkan nilai jaminan diremehkan. Secara total, 34 akun dilikuidasi karena protokol menilai wstETH sekitar 2,85% di bawah harga pasar sebenarnya.

Pada akhirnya, protokol tidak mengalami kerugian buruk dan memberikan kompensasi kepada pengguna yang terdampak. Namun, peristiwa ini mengungkap kelemahan struktural dalam cara manajemen risiko otomatis DeFi melakukan perubahan tanpa intervensi manusia. Ini juga menunjukkan betapa cepat parameter yang salah konfigurasi dapat menyebabkan likuidasi besar-besaran terhadap posisi yang sebenarnya sehat.

Menurut data pasca-insiden, pengguna yang memegang wstETH sebagai jaminan terhadap utang WETH tampak kekurangan jaminan hanya karena penilaian yang salah. Selain itu, posisi mereka akan tetap aman pada harga pasar sebenarnya, menegaskan bahwa kegagalan ini bersifat infrastruktur, bukan disebabkan oleh kondisi pasar.

Mekanisme kegagalan CAPO

Insiden ini berasal dari sistem CAPO (Correlated Asset Price Oracle) Aave, yang dibangun untuk melindungi terhadap manipulasi aset dengan harga berkorelasi, seperti wstETH dan stETH. CAPO mengambil rasio wstETH/stETH dari Lido, menerapkan batas perlindungan melalui WstETHPriceCapAdapter, lalu mengalikan hasilnya dengan harga ETH untuk mendapatkan valuasi dalam USD.

Pada pukul 12:47 UTC tanggal 10 Maret, mesin risiko off-chain Chaos Labs merekomendasikan pembaruan harga maksimum CAPO menjadi 1,1933947 wstETH/ETH. Saat itu, rasio pasar sebenarnya adalah 1,2285, yang berarti batas yang diusulkan sudah secara material di bawah harga yang berlaku.

AgentHub dari BGD mengeksekusi rekomendasi ini satu blok kemudian melalui sistem Otomatisasi Oracle-nya, tanpa adanya buffer review antara rekomendasi off-chain dan implementasi on-chain. Proses pipeline yang instan ini justru yang mengubah kesalahan konfigurasi menjadi kejadian yang langsung berdampak pada pengguna.

Ketidaksesuaian sebesar 2,85% ini menyebabkan protokol menilai wstETH sebagai jaminan yang kurang dari nilai sebenarnya. Akibatnya, akun yang seharusnya aman berdasarkan data pasar nyata ditandai sebagai kekurangan jaminan dan dilikuidasi. Rantai likuidasi ini memproses 10.938 wstETH dari 34 akun dan menghasilkan sekitar 512 ETH dalam bonus likuidasi bagi likuidator sebelum masalah terdeteksi dan dibalikkan.

Akar penyebab teknis: ketidaksesuaian snapshot

Kegagalan teknis ini berasal dari ketidaksesuaian parameter antara snapshotRatio dan snapshotTimestamp dalam CAPO. Agen Risiko off-chain Chaos Labs menghitung rasio target sekitar 1,2282 yang didasarkan pada snapshot berumur 7 hari. Namun, sistem on-chain membatasi seberapa cepat rasio ini dapat bergerak.

Di bawah aturan perlindungan CAPO, nilai on-chain sebelumnya sekitar 1,1572 hanya bisa meningkat 3% setiap 3 hari. Dalam praktiknya, ini berarti rasio hanya bisa naik ke sekitar 1,1919 dalam satu pembaruan, meskipun target off-chain telah meningkat lebih tinggi. Selain itu, pembaruan ini tidak menyelaraskan batasan tersebut dengan logika timestamp.

SnapshotTimestamp diatur seolah-olah anchor on-chain sudah mencerminkan rasio off-chain berumur 7 hari sebesar 1,2282. Ini menciptakan ketidaksesuaian kritis antara referensi waktu dan harga. Akibatnya, CAPO menghitung rasio maksimum sekitar 1,1939, sekitar 2,85% di bawah tingkat pasar sebenarnya sebesar 1,2285.

Insiden ini menandai pembaruan otomatis pertama yang didorong ke on-chain oleh Agen Risiko CAPO Chaos Labs sejak peluncurannya. Meski begitu, fakta bahwa eksekusi perdana ini menyebabkan likuidasi pengguna membuat konfigurasi yang salah ini menjadi sangat mengkhawatirkan baik bagi tata kelola maupun pengguna.

Rantai eksekusi otomatis dari Edge Risk ke AgentHub

Edge Risk adalah mesin risiko off-chain milik Chaos Labs yang menyiapkan dan mendorong perubahan parameter dari alamat tertentu. AgentHub, yang dikembangkan oleh BGD, mendengarkan perubahan ini menggunakan Oracle Automation dan kemudian menyebarkannya ke protokol.

Perubahan parameter yang salah ini melewati tumpukan risiko otomatis Chaos Labs dalam urutan dua transaksi. Pertama, mesin Edge Risk merekomendasikan perubahan batas menjadi 1,191926 wstETH/ETH dalam transaksi 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95. Kemudian, AgentHub mengeksekusi perubahan ini satu blok kemudian melalui transaksi 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e.

Likuidasi harian di Aave selama Februari relatif kecil, jarang melebihi $5 juta, karena kondisi pasar tetap stabil. Lonjakan pada 10 Maret menjadi $21,6 juta merupakan outlier yang terisolasi, sekitar 4 kali lipat dari level normal. Selain itu, volume likuidasi dengan cepat kembali ke tingkat normal setelah koreksi, menegaskan bahwa stres berasal dari jalur oracle, bukan dari insolvensi protokol secara umum.

Perilaku ini memperkuat kesimpulan bahwa masalah harga wstETH adalah kegagalan konfigurasi yang terpisah. Ini bukan gejala menurunnya kualitas jaminan, masalah likuiditas, atau deleveraging sistemik dalam ekosistem Aave.

Rencana deteksi, mitigasi, dan kompensasi likuidasi

Kesalahan konfigurasi ini terdeteksi dalam hitungan menit, memicu respons insiden yang dipercepat dari tim Aave dan penyedia risiko. Untuk membatasi eksposur lebih lanjut, batas pinjaman wstETH di Aave Core dan Aave Prime segera dikurangi menjadi 1, secara efektif membekukan aktivitas pinjaman baru terhadap aset tersebut.

Melalui intervensi manual Risk Steward, tim menyelaraskan kembali snapshotRatio dengan snapshotTimestamp yang aktif, mengembalikan feed oracle ke nilai yang benar. Koreksi oracle dilakukan melalui transaksi 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d, sementara perubahan batas pinjaman untuk menetapkan kapasitas pinjaman wstETH menjadi 1 wstETH dieksekusi melalui transaksi 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8.

Meskipun terjadi penjualan paksa, protokol tidak mengalami kerugian buruk dan merilis laporan pasca-insiden secara rinci ke forum tata kelola Aave. Namun, kerugian pengguna akibat likuidasi memerlukan respons kebijakan terpisah, yang akhirnya menghasilkan rencana kompensasi likuidasi yang terstruktur.

Untuk mengompensasi akun yang terdampak, Aave merekapitulasi 141,5 ETH dalam bonus likuidasi melalui pengembalian BuilderNet. Perbendaharaan DAO kemudian menutup kekurangan sisanya, dengan total restitusi pengguna dibatasi hingga 358 ETH. Penting untuk dicatat, rencana ini dilaksanakan melalui Proposal Peningkatan Aave langsung (AIP), memastikan pengguna yang terdampak menerima kompensasi penuh meskipun kesalahan berasal dari infrastruktur.

Konteks pasar sekitar insiden 10 Maret

Aktivitas lintas rantai di Aave menunjukkan pertumbuhan pengguna yang kuat selama periode Februari–Maret. Misalnya, Avalanche mencatat 38.445 pengguna yang melakukan deposit pada 10 Februari, sementara Base mencatat 31.763 pengguna deposit pada 6 Maret, empat hari sebelum kejadian likuidasi yang dipicu oracle.

Lonjakan ini menyoroti peningkatan keterlibatan pengguna di berbagai jaringan yang didukung Aave, meskipun protokol menghadapi insiden teknis yang kompleks. Selain itu, total deposit dan pinjaman Aave tetap stabil sepanjang awal 2026, menunjukkan bahwa kepercayaan terhadap desain inti protokol tidak melemah secara material setelah kejadian.

Stabilitas deposit, dikombinasikan dengan normalisasi cepat dari likuidasi, menegaskan bahwa kesalahan harga wstETH berasal dari masalah konfigurasi, bukan dari tekanan fundamental di pasar jaminan. Meski begitu, risiko konsentrasi pada penyedia otomatisasi dan jalur oracle tetap menjadi kekhawatiran struktural bagi platform DeFi sebesar Aave.

Tata kelola, transparansi, dan masa depan eksekusi oracle otomatis

Insiden 10 Maret menggambarkan trade-off tata kelola yang dibuat oleh eksekusi oracle otomatis di protokol pinjaman DeFi utama. Edge Risk dari Chaos Labs merekomendasikan batas di bawah pasar, AgentHub dari BGD mengeksekusinya satu blok kemudian, dan likuidasi terjadi dalam hitungan menit, hampir tanpa waktu untuk intervensi manusia.

Aave merespons dengan deteksi cepat, tindakan korektif tegas, dan kompensasi penuh pengguna yang didanai sebagian oleh perbendaharaan DAO. Namun, episode ini mengungkap kekurangan dalam validasi pra-eksekusi dan menyoroti risiko ketergantungan berlebihan pada satu mesin risiko milik pihak ketiga. Khususnya, sifat tertutup dari perhitungan Edge Risk Chaos Labs membatasi verifikasi independen dan menempatkan kendali operasional yang signifikan di tangan penyedia layanan eksternal.

Seiring semakin banyak protokol DeFi mengadopsi kerangka Agen Risiko CAPO otomatis dan sistem serupa, insiden ini menunjukkan bahwa tata kelola harus memasukkan pengujian yang ketat, jendela review yang eksplisit, dan pengawasan transparan. Selain itu, arsitektur oracle Aave secara umum kemungkinan akan membutuhkan lapisan pengamanan tambahan, seperti pemeriksaan silang multi-sumber atau mekanisme peluncuran bertahap, untuk memastikan kesalahan teknis di masa depan tidak langsung menyebabkan kerugian pengguna.

Singkatnya, likuidasi 10 Maret bukanlah krisis pasar, melainkan ujian stres tata kelola dan infrastruktur. Kombinasi otomatisasi, eksekusi cepat, dan pemodelan risiko yang tidak transparan menegaskan mengapa protokol DeFi harus menyeimbangkan efisiensi dengan perlindungan yang transparan dan dapat diaudit untuk melindungi pengguna.