Error Oracle Pragma Dua Menit Picu Likuidasi US$3 Juta di Vesu

Gangguan data harga selama sekitar dua menit cukup untuk memicu likuidasi tidak normal atas agunan senilai kira-kira US$3 juta di Vesu, protokol pinjam-meminjam di Starknet. Pada 4 September 2026, feed harga upstream dari Pragma mengirimkan data keliru antara pukul 04.08 dan 04.10 UTC. Akibatnya, 47 posisi pinjaman di beberapa pool Vesu tampak memenuhi syarat untuk dilikuidasi. 32

Poin pentingnya: Vesu menyebut peristiwa ini sebagai kegagalan input oracle, bukan celah keamanan pada kontrak pintarnya. Mesin likuidasi menjalankan aturan yang diterimanya, tetapi dasar harga yang dipakai aturan tersebut salah. 32

Apa yang terjadi dalam dua menit itu?

Di pasar pinjaman DeFi, protokol terus membandingkan nilai agunan pengguna dengan nilai utangnya. Jika nilai posisi turun melewati ambang rasio agunan yang dipersyaratkan, pihak ketiga yang disebut likuidator dapat menjalankan proses likuidasi sesuai aturan pasar tersebut.

Dalam kasus Vesu, harga keliru dari Pragma membuat 47 posisi terlihat kekurangan agunan. Likuidator otomatis lalu mengeksekusi jalur likuidasi normal dan mengambil sekitar US$3 juta agunan, sebelum feed harga kembali normal. 2032

Karena itu, pernyataan bahwa “kontrak berjalan sesuai rancangan” tidak sama dengan hasil ekonomi yang benar. Kontrak pintar dapat memverifikasi serta mengeksekusi data yang tersedia di blockchain, tetapi tidak otomatis mengetahui apakah harga yang dikirim oracle benar-benar mencerminkan harga pasar.

Mengapa oracle yang salah dapat melikuidasi peminjam yang sehat?

Logika likuidasi pada protokol pinjaman memang dibuat mekanis dan cepat. Bila nilai agunan sungguh anjlok, protokol harus bertindak agar pemberi pinjaman tidak menanggung kredit macet. Namun, otomatisasi yang sama dapat mendorong posisi melewati ambang likuidasi ketika harga yang dilaporkan ternyata keliru.

Urutannya sederhana:

1. Oracle mengirim harga yang dipakai pasar pinjaman.
2. Protokol menghitung ulang kesehatan posisi berdasarkan harga tersebut.
3. Posisi terlihat melanggar ambang agunan minimum.
4. Likuidator menjalankan mekanisme likuidasi yang biasa.

Pada insiden Vesu, masalahnya berada pada langkah pertama—data harga salah—bukan karena jalur likuidasi dibobol atau dieksploitasi. Vesu mengatakan tidak diperlukan perbaikan kontrak di sisi protokol. 32

Upaya pemulihan, jeda pool, dan arahan bagi pengguna

Vesu menyatakan Pragma bersama pihak-pihak terkait telah menerapkan perbaikan untuk akar masalah, sementara feed harga telah mengoreksi dirinya dalam jendela insiden dua menit itu. Vesu saat itu memperkirakan curator pool akan membuka kembali pool terdampak setelah mitigasi dilakukan. 32

Protokol ini juga mengatakan sedang bekerja sama dengan Pragma, StarkWare, Starknet Foundation, dan curator pool untuk mengupayakan pemulihan dana pengguna terdampak. Ini adalah upaya pemulihan, bukan konfirmasi bahwa semua pengguna sudah menerima penggantian dana. 2432

Bagi pengguna terdampak, panduan yang dilaporkan dari Vesu adalah:

• mempertahankan posisi Earn tetap terbuka, karena penarikan dapat memengaruhi kelayakan dalam proses pemulihan; dan
• mengirim tiket dukungan melalui Discord Vesu jika posisinya terlikuidasi dalam insiden tersebut. 2734

Status pool dapat berubah saat curator mencabut atau mempertahankan langkah pencegahan. Pengguna sebaiknya merujuk pada pengumuman insiden dan kanal dukungan resmi Vesu terbaru, alih-alih mengasumsikan semua pasar terdampak atau semua pool berstatus sama.

Apa yang sudah diketahui soal perbaikan—dan apa yang belum?

Pengungkapan publik menetapkan beberapa fakta utama: sumber masalah adalah feed harga upstream Pragma, gangguan berlangsung sekitar dua menit, feed kemudian pulih sendiri, dan perbaikan akar masalah telah diterapkan bersama pihak terkait. 2332

Namun, pengungkapan tersebut belum menjelaskan mekanisme teknis lengkap yang menghasilkan nilai harga salah maupun skema kompensasi final. Vesu menyatakan laporan teknis lengkap akan menyusul. Sampai laporan itu tersedia, klaim mengenai cacat perangkat lunak spesifik, pihak yang bertanggung jawab di luar isu feed upstream yang telah diungkap, atau hasil akhir pemulihan dana harus dianggap belum terkonfirmasi. 27

Pelajaran DeFi: kode yang benar tetap membutuhkan data yang benar

Kasus Vesu menunjukkan persoalan mendasar oracle. Aplikasi terdesentralisasi dapat bersifat transparan dan deterministis di blockchain, tetapi keputusan finansialnya tetap bergantung pada fakta dari luar kontrak—terutama harga aset.

Dua kejadian lain pada 2026 memperlihatkan bentuk risiko serupa, meski tidak identik.

Ketidakselarasan oracle wstETH Aave pada Maret 2026

Pada 10 Maret, insiden oracle risiko CAPO di pasar Ethereum Core dan Prime milik Aave menekan kurs efektif wstETH/stETH sekitar 2,85%. Valuasi yang salah tersebut memicu volume likuidasi sekitar US$26,6 juta. Post-mortem Aave mengaitkannya dengan ketidakkonsistenan antara rasio snapshot dan timestamp snapshot, bukan kejatuhan pasar yang meluas. 1011

Seperti pada Vesu, aturan likuidasi Aave tidak berhenti bekerja. Masalahnya, aturan itu diterapkan pada valuasi yang keliru.

Dugaan kompromi lingkungan Move milik Switchboard

Dalam kategori risiko oracle yang berbeda dan berpotensi lebih serius, Switchboard menghentikan operasi oracle pada Aptos, Sui, IOTA, dan Movement setelah adanya laporan kemungkinan kompromi keamanan pada implementasi berbasis Move. Penghentian itu bersifat pencegahan dan tidak menghentikan produksi blok pada jaringan-jaringan tersebut. 34

Sejumlah laporan menghubungkan kejadian itu dengan manipulasi data harga IOTA, pencetakan VUSD yang tidak normal, dan likuidasi. Namun, insiden ini tetap perlu disebut sebagai dugaan kompromi sampai investigasi definitif menetapkan penyebab serta cakupannya. 25

Seperti apa pengamanan oracle yang lebih kuat?

Tidak ada satu pengamanan yang menjamin pasar pinjaman selalu menolak seluruh input harga yang buruk. Tujuan praktisnya adalah mengurangi kemungkinan anomali harga sesaat langsung menciptakan kerugian yang sulit dipulihkan. Sejumlah pendekatan yang umum digunakan meliputi:

• memakai sumber harga independen, bukan satu jalur input saja;
• menerapkan batas deviasi untuk menolak atau menjeda perubahan harga yang tidak lazim;
• menggunakan pemeriksaan staleness agar data lama tidak dianggap sebagai harga terkini;
• menambahkan circuit breaker dan jeda darurat pada level pool;
• menunda atau meninjau perubahan konfigurasi oracle yang berdampak besar; serta
• menetapkan parameter agunan secara konservatif untuk aset yang volatil atau kompleks.

Komprominya tidak bisa dihindari: pengamanan yang lebih ketat dapat memperlambat respons terhadap pergerakan pasar yang nyata, sedangkan pengamanan yang longgar membuat likuidasi otomatis lebih mudah bereaksi terhadap data yang keliru. Insiden dua menit di Vesu memperlihatkan mengapa keseimbangan ini menjadi inti desain risiko DeFi.

Bagi peminjam, pelajaran praktisnya adalah risiko likuidasi bukan hanya datang dari volatilitas pasar atau eksploitasi kontrak. Risiko itu juga mencakup integritas, konfigurasi, dan ketahanan operasional sistem oracle yang menentukan kesehatan posisi mereka di blockchain.