Definisi Oracle dan Stabilitas Pasar: Membangun Pasar Perpetual yang Terpercaya di HIP-3

Perkembangan cara peluncuran kontrak perpetual telah mengalami perubahan mendasar. Di masa lalu, platform mengendalikan aset apa yang dapat diperdagangkan dan dengan syarat apa, HIP-3 telah mendistribusikan kekuasaan tersebut kepada builder yang memenuhi syarat yang beroperasi dalam parameter yang ditentukan. Sejak peluncuran mainnet-nya, lebih dari $13 miliar volume transaksi mengalir melalui pasar yang dioperasikan pihak ketiga, menandakan demokratisasi nyata dalam penciptaan pasar. Namun, pergeseran ini dari gatekeeper ke sistem berbasis aturan menciptakan paradoks penting: fleksibilitas pasar yang lebih besar menuntut disiplin operasional yang lebih ketat. Di pusat tantangan ini terletak konsep yang tampaknya sederhana namun memiliki konsekuensi besar—definisi oracle.

Arsitektur Di Balik Listing Terdesentralisasi: Berpindah dari Persetujuan ke Standar

Bursa terpusat tradisional mengendalikan listing kontrak perpetual melalui proses internal yang tidak transparan. Tim produk mengevaluasi aset, membuat keputusan bisnis, dan meluncurkannya. Pengendalian risiko berada dalam infrastruktur bursa. HIP-3 membalik model ini. Alih-alih mempertahankan katalog yang dikurasi, Hyperliquid menyediakan infrastruktur—HyperCore menangani pencocokan dan penyelesaian secara skala besar, HyperEVM menjalankan smart contracts—dan mengundang builder untuk menambahkan pasar di atasnya.

Mekanismenya sederhana di permukaan: stake 500k token HYPE, deploy DEX (yang memegang margin dan order book sendiri), luncurkan tiga pasar secara gratis, lalu peroleh slot pasar tambahan melalui lelang Belanda. Tetapi kesederhanaan struktural ini menyembunyikan kompleksitas mendalam dalam eksekusi. Sekarang, builder tidak hanya memiliki kendali atas penciptaan pasar tetapi juga operasi pasar—pengisian harga, pengelolaan parameter, pemantauan stabilitas berkelanjutan. Apa yang dulunya menjadi tanggung jawab platform kini menjadi tanggung jawab builder.

Pergeseran ini membuka ketegangan utama: desentralisasi membutuhkan standarisasi. Sistem harus menetapkan antarmuka dan batasan yang jelas; jika tidak, risiko tidak hilang—melainkan terfragmentasi di antara puluhan operator independen dengan kemampuan yang berbeda-beda.

Definisi Oracle: Keputusan Pertama yang Krusial

Ketika builder memulai penciptaan pasar, keputusan pertama dan paling penting melibatkan definisi oracle. Ini bukan sekadar memilih feed harga; mencakup seluruh kerangka konseptual tentang bagaimana peserta pasar akan menentukan apakah posisi mereka menguntungkan, menghadapi likuidasi, atau memicu mekanisme darurat.

Apa yang Sebenarnya Ditentukan oleh Definisi Oracle:

Definisi oracle dalam HIP-3 mencakup tiga komponen: oraclePx (harga mentah dari sumber eksternal), opsi markPx (harga tanda khusus yang disediakan builder), dan externalPerpPx (median tertimbang dari harga perpetual bursa terpusat). Ini bukan input yang dapat dipertukarkan—mereka memiliki fungsi berbeda dalam hierarki perhitungan risiko HIP-3.

oraclePx menjadi dasar biaya pendanaan dan sebagai referensi batas harga. markPx dihitung oleh relayer builder yang menggabungkan sinyal on-chain dan off-chain. externalPerpPx menyediakan referensi cadangan. HIP-3 kemudian menggabungkan ketiganya menjadi harga tanda aktual melalui perhitungan median: pertama median order book lokal, kemudian digabungkan dengan tanda eksternal yang disediakan builder, lalu dibandingkan dengan externalPerpPx. Pendekatan multi-sumber ini secara teori mencegah satu sumber harga tunggal menentukan likuidasi.

Secara teori.

Mengapa Definisi Oracle Lebih Penting Daripada Teknologi:

Komposisi teknis definisi oracle kurang penting dibandingkan kapasitas operasional builder untuk mempertahankannya. Seorang builder yang memilih definisi oracle yang bergantung pada relayer server terpusat mewarisi ketersediaan, keamanan, dan frekuensi pembaruan server tersebut sebagai batasan. Jika kunci privat yang mengamankan relayer dikompromikan, atau serangan DDoS mencegah pembaruan harga, oraclePx akan stagnan. Dengan harga tanda yang tidak dapat diperbarui, sistem kembali ke median order book lokal—tepat saat likuiditas paling tipis dan risiko manipulasi memuncak.

Insiden 14 Desember 2025 di trade.xyz menunjukkan dinamika ini. Penyerang mengakumulasi posisi pendek sekitar 398 kontrak XYZ100 (~$10M), secara sengaja menciptakan ketidakseimbangan. Harga terlepas dari sumber eksternal karena kedalaman order book yang tidak memadai. Pemegang posisi panjang menghadapi likuidasi berantai, dengan sekitar $13M posisi ditutup. Mekanisme secara teknis berjalan—likuidasi dieksekusi—tetapi sistem memindahkan kerugian ke peserta yang paling tidak siap daripada mencegah dislokasi awal.

Situasi ini menjadi jauh lebih mungkin terjadi ketika definisi oracle mengasumsikan anchor harga eksternal yang stabil selama jam non-market.

Divisi Aset 24/7 vs Non-24/7: Dimana Definisi Oracle Menjadi Krusial

Fleksibilitas HIP-3 untuk listing aset apa pun menciptakan perbedaan kategoris dalam kebutuhan definisi oracle.

Aset 24/7 (Cryptocurrency Perpetual):

Untuk Bitcoin, Ethereum, dan aset yang diperdagangkan 24 jam lainnya, definisi oracle dapat mengandalkan beberapa feed harga dari CEX/DEX yang digabungkan dengan layanan oracle khusus seperti Pyth. Aset ini diperdagangkan secara kontinu di berbagai venue. Builder dapat mengakumulasi beberapa sumber harga, menerapkan perhitungan median, dan mendeteksi outlier. Ketika satu sumber menyimpang, yang lain memberikan anchor langsung.

Definisi oracle untuk aset 24/7 tetap menantang—memilih sumber berbobot, mengelola frekuensi pembaruan, menangani gangguan exchange—namun pasar eksternal yang mendasari menyediakan sinyal konsisten bahkan jika satu feed gagal.

Aset Non-24/7 (Saham dan Komoditas):

Definisi oracle untuk perpetual saham memerlukan asumsi yang berbeda secara fundamental. Selama jam pasar, feed harga dari layanan seperti Pyth memberikan anchor eksternal yang stabil. Tetapi saat Bursa Saham New York tutup, builder menghadapi pilihan: menghentikan feed harga (dan membatasi perdagangan), atau melanjutkan penetapan harga berdasarkan sinyal pasar internal dengan referensi eksternal hanya pada “harga penutupan sebelumnya.”

Sebagian besar builder yang mengimplementasikan aset non-24/7 saat ini menggunakan mekanisme penetapan harga internal yang mirip trade.xyz—menggabungkan harga oracle eksternal terakhir dengan dinamika order book internal, dibatasi untuk mencegah drift berlebihan (biasanya 1/max_leverage fluktuasi). Secara matematis benar; secara operasional berbahaya.

Selama penutupan pasar, kedalaman order book biasanya menyusut. Market maker mengurangi kutipan, peserta ritel tidur, dan pasar menjadi sangat tipis. Definisi oracle yang membatasi pergerakan harga ke “1/10 dari penutupan sebelumnya” (untuk leverage 10x) terdengar konservatif. Ketika likuiditas menghilang, bahkan volume order yang modest dapat menciptakan pergerakan harga yang tidak proporsional dalam rentang terbatas tersebut. Ketika pasar dibuka kembali Senin pagi dan data eksternal kembali meng-anchor, muncul celah. Celah ini memicu likuidasi berantai atau, dalam kasus parah, kejadian ADL (pengurangan posisi otomatis) di mana perdagangan yang menguntungkan dipaksa ditutup untuk menutup kerugian dari posisi insolven.

Membangun Kerangka Defensible untuk Definisi Oracle

Builder yang berusaha mengoperasikan pasar yang stabil perlu strategi definisi oracle yang mengantisipasi mode kegagalan daripada mengasumsikan stabilitas terus-menerus.

Anchor Harga Tambahan Saat Penutupan Pasar:

Untuk aset non-24/7, memperkenalkan sinyal harga eksternal bahkan selama penutupan pasar secara signifikan meningkatkan definisi oracle. Opsi termasuk:

• Blue Ocean ATS dan venue perdagangan setelah jam pasar: Memberikan penemuan harga kontinu di luar jam perdagangan reguler, menawarkan sinyal yang lebih mutakhir daripada “harga penutupan sebelumnya.” Builder dapat memberi bobot data Blue Ocean ATS ke dalam definisi oracle selama penutupan pasar, menciptakan referensi yang kurang manipulatif.

• Kutipan CFD akhir pekan dari penyedia seperti IG: Meramalkan ekspektasi pasar untuk pembukaan minggu berikutnya. Meskipun bukan pengganti langsung harga spot, mereka berfungsi sebagai anchor arah untuk “celah pembukaan yang diharapkan” dalam definisi oracle.

Sumber-sumber ini memiliki karakteristik penting: tersedia selama penutupan pasar tetapi berbeda secara struktural dari pasar spot. Definisi oracle harus memperlakukannya sebagai referensi dan sinyal risiko, bukan sebagai setara mutlak.

Merancang Derivasi Harga yang Transparan dan Terbukti Audit:

Kerentanan utama dalam implementasi definisi oracle saat ini adalah sentralisasi relayer. Jika feed harga berasal secara eksklusif dari server pribadi builder, server tersebut menjadi titik kegagalan dan serangan tunggal. Builder harus membangun sistem verifikasi definisi oracle yang memungkinkan pihak eksternal mengaudit keaslian harga.

Ini memerlukan pengungkapan publik: sumber data yang memberi feed oracle, algoritma tepat yang menggabungkan sumber tersebut, cap waktu sampling untuk setiap input, dan harga tanda yang dihasilkan. Untuk setiap panggilan setOracle, hasilkan bukti kriptografi yang mencakup data mentah, langkah perhitungan, dan output akhir. Serialize ini ke dalam proofHash, yang ditandatangani relayer. Secara berkala, kumpulkan hash ini ke dalam pohon Merkle dan publikasikan root-nya di chain.

Pendekatan ini mengubah definisi oracle dari “percayai server harga builder” menjadi “verifikasi metodologi builder.” Setiap pengguna dapat mengambil data harga historis, menghitung ulang output menggunakan algoritma yang dipublikasikan, dan mengonfirmasi apakah feed builder sesuai sumber yang dinyatakan.

Ketika Definisi Oracle Gagal: Pemantauan dan Intervensi

Bahkan definisi oracle yang dirancang dengan baik pun gagal di bawah tekanan pasar ekstrem. Builder yang beroperasi di HIP-3 perlu kerangka pemantauan yang mendeteksi penurunan sebelum meluas.

Pemantauan Sisi Harga: Deteksi Drift Oracle:

Kegagalan feed harga oracle muncul pertama kali sebagai diskontinuitas—relayer berhenti memperbarui. Builder harus memantau observables on-chain: jika dua pembaruan oracle berturut-turut lebih dari 10 detik, sistem menandai peringatan Level 1. Pemeriksaan kesehatan builder terhadap infrastruktur relayer mereka, berpotensi beralih ke node cadangan.

Lebih berbahaya adalah de-anchoring harga: harga oracle secara perlahan menyimpang dari benchmark eksternal. Definisi oracle builder mungkin bergantung pada Pyth untuk perpetual saham, tetapi data input Pyth (yang menggunakan harga gabungan exchange) menyimpang dari kondisi pasar saat ini. Definisi oracle menjadi usang tanpa tampak rusak. Ambang pemantauan harus membandingkan beberapa sumber eksternal terhadap oracle builder: jika dua atau lebih menyimpang >X%, tingkatkan peringatan.

Pada Level 1, batasi kenaikan open interest dengan setOpenInterestCaps. Pada Level 2 (deviasi berkelanjutan), perbarui margin tier untuk secara bertahap mengurangi leverage maksimum. Pada Level 3, aktifkan penghentian darurat melalui haltTrading.

Pemantauan Order Book: Deteksi Keruntuhan Likuiditas:

Definisi oracle hanya sebaik struktur likuiditas pasar. Jika order book menyempit, spread melebar, dan impact order agresif meningkat, harga yang akurat pun berbahaya. Builder harus memantau depth_band (volume kumulatif dalam ±x% dari harga tengah), spread (selisih ask terbaik dan bid terbaik), dan impact_ratio (volume agresif / depth_band). Ketika kedalaman menyusut sementara spread dan impact ratio membesar secara bersamaan, risiko likuidasi meningkat tajam.

Pada Level 1, batasi pertumbuhan open interest. Pada Level 2, secara paksa kurangi leverage pada posisi berisiko tinggi.

Pemantauan Konsentrasi Posisi: Deteksi Kaskade Spekulasi:

Akhirnya, pantau apakah pasar beralih dari hedging yang nyata ke spekulasi murni. Lacak rasio notional open interest terhadap volume perdagangan 24 jam. Ketika OI tumbuh jauh lebih cepat dari volume, pasar beralih ke eksposur satu sisi yang terkumpul. Dikombinasikan dengan profit/loss mayoritas yang ekstrem, ini mendahului kaskade likuidasi. Builder harus memberi peringatan saat rasio melampaui ambang batas; jika terus-menerus, turunkan batas OI.

Governansi Melalui Staking: Akuntabilitas Keputusan Definisi Oracle

Mekanisme HIP-3 untuk menahan builder bertanggung jawab berpusat pada staking. Builder harus mempertahankan stake 500k HYPE yang selalu terkunci. Validator dapat memilih untuk mengurangi stake ini jika tindakan builder menciptakan kondisi pasar tidak valid, downtime berkepanjangan, atau penurunan performa.

Mekanisme staking ini membuat pilihan definisi oracle memiliki konsekuensi finansial nyata. Builder yang mengimplementasikan definisi oracle yang ceroboh—menggunakan feed harga terpusat tunggal, gagal memantau drift, atau mengabaikan risiko harga di luar jam—menciptakan kaskade likuidasi. Validator yang mengamati kegagalan berulang atau keruntuhan pasar yang secara langsung dapat dilacak ke kekurangan definisi oracle dapat memilih untuk mengurangi seluruh stake builder.

Ini mengubah definisi oracle dari keputusan teknis menjadi keputusan governance. Validator secara implisit meratifikasi atau memberi sanksi terhadap pilihan oracle builder melalui voting slashing. Seiring waktu, ini menciptakan tekanan evolusioner: builder yang mengimplementasikan definisi oracle yang kokoh akan bertahan; yang mengabaikan akan mengumpulkan voting slashing.

Mekanisme ini tidak sempurna—validator mungkin kurang keahlian teknis untuk menilai pilihan definisi oracle secara adil, atau mungkin voting tanpa mempertimbangkan kualitas operasional sebenarnya. Tetapi ini menetapkan ambang akuntabilitas minimum.

Implikasi Lebih Luas: Desentralisasi Sebagai Redistribusi Risiko

Inovasi utama HIP-3 bukanlah menghilangkan risiko; melainkan mendistribusikannya. Di mana bursa terpusat menginternalisasi risiko operasional (memelihara feed harga, mencegah manipulasi, mengelola likuidasi), HIP-3 mengeksternalisasi tanggung jawab ini kepada builder. Protocol menyediakan infrastruktur; builder menyediakan keunggulan operasional.

Ini hanya berhasil jika builder memahami apa yang sebenarnya mereka tanggung jawabkan. Definisi oracle adalah salah satu permukaan serangan yang paling diremehkan. Tampaknya sederhana—memilih feed harga—tetapi mencakup pemilihan feed, pengelolaan relayer, penetapan harga di luar jam, mekanisme fallback, kerangka verifikasi, pemantauan berkelanjutan, dan akuntabilitas governance.

Pasar yang dibangun di atas definisi oracle yang ceroboh akan gagal. Pasar yang dibangun di atas definisi oracle yang dipikirkan matang, dengan pemantauan yang tepat, dan mekanisme verifikasi yang transparan dapat menopang aktivitas perdagangan yang substansial. Volume perdagangan $13 miliar melalui pasar HIP-3 menunjukkan builder yang memadai ada. Tetapi setiap pasar yang gagal—setiap kaskade likuidasi yang dapat dilacak ke kegagalan definisi oracle—memindahkan modal dari trader yang tidak sadar ke operator platform dan arbitrageurs yang canggih.

Builder yang memasuki HIP-3 harus memandang definisi oracle bukan sebagai detail teknis, tetapi sebagai keputusan arsitektural dasar yang menentukan apakah pasar mereka akan beroperasi dengan integritas atau gagal di bawah tekanan.

Menavigasi Jalan ke Depan

Bagi builder yang merancang akses pasar, template parameter, sistem peringatan, dan prosedur tanggap darurat berbasis HIP-3, keberhasilan bergantung pada memperlakukan definisi oracle sebagai masalah desain dari prinsip pertama. Ini berarti secara eksplisit memodelkan bagaimana perilaku definisi oracle Anda dalam skenario: gangguan exchange, serangan DDoS pada relayer Anda, celah harga antara internal dan eksternal di luar jam, dan kaskade likuidasi saat volume tipis.

Ini berarti menerapkan kerangka verifikasi yang memungkinkan audit eksternal terhadap metodologi harga Anda. Ini berarti menetapkan ambang pemantauan dan prosedur eskalasi dengan aturan pengambilan keputusan yang jelas. Yang paling penting, ini berarti menyadari bahwa kompleksitas menjaga definisi oracle yang terpercaya di bawah tekanan belum hilang—hanya berpindah dari bursa ke builder.

Mereka yang memandang serius definisi oracle akan mengoperasikan pasar yang stabil dan terpercaya. Mereka yang tidak akan menjadi studi kasus tentang bagaimana sistem desentralisasi gagal.