Seiring waktu yang lama di atas rantai, Anda pasti pernah mendengar kata "oracle". Kata ini ada di mana-mana—hampir di setiap arsitektur protokol DeFi tidak lepas dari itu. Tapi sejujurnya, kebanyakan orang hanya menganggapnya sebagai alat yang mengirimkan harga dari luar rantai ke dalam rantai. Hanya itu saja.

Hingga baru-baru ini, saat pasar berangsur dari era volatilitas tinggi dan narasi konsep yang kuat, menuju tahap pencarian stabilitas dan pertumbuhan berkelanjutan, saya mulai meninjau kembali infrastruktur dasar ini. Dalam proses ini, saya mulai mendalami masalah nyata dari oracle—dan bukan sekadar penilaian permukaannya tentang "akur tidaknya".

Banyak proyek terbiasa memulai dengan "Apa yang ingin saya lakukan", tetapi proyek yang benar-benar layak dipikirkan justru memulai dari masalah kebalikannya: di mana sistem paling rentan terhadap keruntuhan?

Risiko utama dari oracle bukanlah kesalahan sesaat, melainkan **apakah selama operasi jangka panjang dan sering dipanggil, deviasi ini diserap oleh sistem, atau justru diperbesar secara tak terbatas?**

Bayangkan oracle sebagai sistem navigasi di jalan raya yang cepat. Sesekali salah petunjuk? Mungkin hanya memutar beberapa kilometer lebih jauh, tidak masalah besar. Tapi ketika dalam skenario frekuensi tinggi dan skala besar, output deviasi yang terus-menerus muncul, itu bukan lagi masalah pengalaman—melainkan menjadi kecelakaan sistemik.

Dalam beberapa tahun terakhir, reaksi berantai yang dipicu oleh masalah oracle di rantai terus bermunculan: likuidasi yang tidak normal, mekanisme arbitrase yang dimanfaatkan, protokol yang mengalami kerugian. Jika diperhatikan dengan seksama, pelaku utama dari insiden-insiden ini seringkali bukanlah deviasi harga yang ekstrem, melainkan kurangnya mekanisme verifikasi dan lapisan buffer yang cukup di saat-saat kritis. Inilah yang perlu didesain ulang.