Tulisan: Blocksec
HIP-3 (Hyperliquid Improvement Proposal 3) telah diluncurkan di mainnet selama sekitar 3 bulan, sejak peluncurannya, volume transaksi pasar kustom pihak ketiga telah menembus lebih dari 130 miliar dolar AS, yang berarti bahwa “penambahan produk baru” sedang bertransformasi dari proses internal bursa menjadi sebuah infrastruktur dasar yang dapat langsung dipanggil oleh pengembang eksternal.
Di bursa terpusat, “penambahan produk baru” secara alami adalah kekuasaan platform: aset apa yang dapat diperdagangkan, kapan diluncurkan, parameter apa yang ditetapkan, semuanya biasanya ditentukan oleh proses operasional dan manajemen risiko. Bahkan di on-chain, kategori kontrak perpetual yang bersifat fundamental ini sering dibatasi oleh ritme deployment dan governance dari tim tertentu.
Inovasi HIP-3 terletak pada mengubah proses ini dari “persetujuan platform” menjadi “antarmuka terbuka”: selama memenuhi syarat, pihak ketiga dapat meng-deploy pasar kontrak perpetual baru di atas basis trading dan clearing yang sama, sehingga kekuasaan penambahan produk secara terpusat dialihkan secara sistematis ke ekosistem. Perbaikan ini tidak hanya menurunkan ambang inovasi, tetapi juga memperkuat skalabilitas pasar. Namun, membuka antarmuka juga membawa risiko keamanan potensial yang tidak bisa diabaikan, bagaimana memastikan bahwa operasi pasar ini sesuai regulasi dan bebas dari tindakan jahat tetap menjadi isu utama dalam desain HIP-3 yang harus diawasi secara ketat.
0x1 Hyperliquid: Dasar HIP-3
Hyperliquid adalah infrastruktur trading perpetual yang berjalan di atas blockchain miliknya sendiri. Untuk HIP-3, hal terpenting adalah: matching, clearing, dan settlement disediakan secara terpusat oleh dasar protokol, sehingga kemampuan pasar dapat digunakan kembali, bukan dibangun dari nol.
Hyperliquid mengadopsi arsitektur dua lapis:
HyperCore: blockchain L1 yang dikustomisasi untuk mengoptimalkan kontrak trading, mampu memproses 200.000 order per detik, dan memiliki finalitas deterministik.
HyperEVM: lapisan aplikasi yang dapat menjalankan smart contract, kompatibel dengan EVM.
Market native perp (validator-operated perps) Hyperliquid tetap lebih mirip proses tradisional CEX saat listing: resmi berdasarkan keinginan komunitas untuk listing kontrak perpetual; sedangkan delisting dilakukan melalui voting node validator.
Protocol Hyperliquid akan mendukung builder-deployed perps (HIP-3), sebuah tonggak penting menuju desentralisasi penuh proses listing perp.
Protocol Hyperliquid akan mendukung kontrak perpetual yang di-deploy oleh builder (HIP-3), ini adalah tonggak utama dalam mewujudkan proses listing kontrak perpetual yang benar-benar terdesentralisasi.
0x2 HIP-3: Pasar yang Dideploy Pengembang
Konsep HIP-3 sangat sederhana: tanpa mengubah dasar trading dan clearing Hyperliquid, membuka kemampuan “penambahan pasar perpetual” kepada builder yang memenuhi syarat. Builder bertanggung jawab mendefinisikan parameter utama pasar dan tanggung jawab pengelolaan harga/operasi, sementara protokol menggunakan margin dan mesin clearing yang seragam untuk eksekusi dan manajemen risiko; sehingga “penambahan” dari proses platform menjadi antarmuka standar yang dapat dipanggil.
Secara sederhana: builder dapat menambahkan pasar kontrak perpetual berbasis mesin HyperCore, mengatur harga dan parameter pasar secara mandiri.
Batas Tanggung Jawab Builder
Dalam HIP-3, builder bertanggung jawab atas dua hal terkait sebuah pasar perpetual (market): mendefinisikan pasar dan mengoperasikan pasar.
Definisi pasar (Market definition):
Dijelaskan resmi sebagai oracle definition + contract specifications. Secara operasional, minimal mencakup:
Definisi oracle:
Termasuk definisi oraclePx awal dan sumber harga. Builder saat mendefinisikan pasar harus secara jelas menentukan aset atau sumber data yang memiliki kejelasan, manipulasi yang sulit, dan substansi ekonomi; saat mendaftarkan aset harus menyediakan oraclePx awal.
Spesifikasi kontrak:
Dalam API, secara tegas mendefinisikan parameter pasar seperti “simbol aset / unit terkecil / leverage maksimum” (coin, szDecimals, maxLeverage, dll).
Pemilihan DEX:
Builder pertama-tama meng-deploy sebuah DEX perpetual (setiap DEX memiliki margin, order book, dan pengaturan deployer yang terpisah), dan dapat memilih aset quote apa saja sebagai jaminan DEX tersebut (misalnya USDC), setiap pasar perpetual akan terkait dengan satu DEX.
Operasi pasar (Market operation):
Dijelaskan secara resmi sebagai pengaturan harga oracle / batas leverage / penyelesaian pasar jika diperlukan, secara rinci:
Update harga feed:
Melalui antarmuka setOracle untuk terus-menerus memberi harga oracle pada pasar.
Batas leverage:
Menggunakan tabel margin yang sesuai untuk aset, membatasi leverage maksimum—batas leverage diatur berdasarkan ukuran posisi, membatasi leverage dalam rentang yang telah ditetapkan.
Settlement jika perlu:
Builder dapat menggunakan antarmuka haltTrading untuk menghentikan pasar, memicu settlement—membatalkan semua order, dan menyelesaikan posisi berdasarkan harga mark saat ini; tindakan yang sama juga dapat digunakan untuk mengembalikan perdagangan.
Saat ini, pasar HIP-3 hanya mendukung isolated-only, kemungkinan akan mendukung cross margin di masa depan.
Proses Peluncuran Pasar
- Stake
Mainnet mensyaratkan builder menahan staking 500k HYPE; dan meskipun semua pasar di DEX dihentikan, staking harus dipertahankan selama 30 hari.
- Build
Setelah memenuhi syarat staking, builder dapat meng-deploy satu DEX perpetual. Setiap DEX adalah domain trading independen: margin, order book, dan pengaturan deployer terpisah.
- Set collateral
Collateral DEX dapat memilih aset quote apa saja, tetapi jika aset quote tersebut kehilangan status permissionless quote asset (diputuskan oleh voting validator), maka DEX tersebut akan dinonaktifkan.
- Tambah pasar
Tiga pasar pertama dapat langsung di-deploy;
Untuk menambah pasar selanjutnya, harus melalui lelang Belanda (Dutch auction) untuk mendapatkan “kuota tambahan”.
- Operasikan pasar
Setelah pasar aktif, tugas builder adalah “menjaga kestabilan pasar”, yaitu mengelola operasi pasar.
- Unstake
Setelah semua pasar di DEX diselesaikan, staking 500k HYPE dapat dilepas, dan proses unstake akan masuk ke antrean unstaking selama 7 hari, selama waktu ini staking masih berisiko dikenai penalti.
Lelang Belanda: siklus saat ini adalah 31 jam per putaran, harga awal adalah 2x harga akhir (harga transaksi/harga terendah sebelumnya).
SetOracle: Tiga jenis input harga
Di HyperCore, harga oracle terutama digunakan untuk mengaitkan dan menghitung biaya dana (funding), sedangkan harga mark digunakan sebagai harga penanda dalam skenario manajemen risiko seperti margin dan liquidation (juga untuk trigger TP/SL).
Dalam pasar native, harga mark bukan hasil langsung feed harga tertentu, melainkan median dari tiga harga:
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (harga order book lokal)
Harga tengah dari beberapa CEX perpetual (perp mid prices) (perp mid prices) yang berbobot.
Namun di HIP-3, fungsi harga oracle dan harga mark tidak berubah, tetapi mekanisme perhitungannya berubah:
Input setOracle
a. oraclePx (harus )
Definisi inti sesuai HyperCore.
b. markPx (opsional)
Dapat mengirim 0–2 set harga mark eksternal sebagai kandidat harga mark yang sebenarnya.
c. externalPerpPx (harus)
Sebagai referensi harga mark, untuk mencegah harga mark menyimpang secara tiba-tiba.
Relayer biasanya akan meng-deploy node relayer untuk feed harga, dan menggabungkan sumber harga eksternal:
oraclePx dihitung oleh relayer berdasarkan sumber eksternal;
markPx dihitung oleh relayer dengan algoritma kustom;
externalPerpPx berasal dari median tertimbang dari beberapa harga tengah perp dari berbagai CEX.
- Harga mark aktual
Harga mark HIP-3 tidak langsung menggunakan feed dari setOracle:
Menghitung local mark: median(best bid, best ask, last trade).
Gabungkan local mark dan beberapa set markPx (0–2), lalu ambil median untuk mendapatkan harga mark baru.
- Pembatasan setOracle
Frekuensi update: minimal jarak 2.5 detik antar panggilan, jika dalam 10 detik markPx tidak diperbarui, akan kembali ke local mark.
Batasan fluktuasi: setiap perubahan markPx tidak lebih dari ±1%; semua harga dibatasi dalam rentang 10× dari nilai pembukaan hari itu.
7×24H & Non 7×24H: Perbedaan Mekanisme Penetapan Harga
Dalam HIP-3, pasar kontrak perpetual mendukung aset apa saja yang dapat diluncurkan, dan aset ini terbagi menjadi aset 7×24H (perdagangan sepanjang waktu) dan non-7×24H (hanya pada jam tertentu, pasar spot di luar jam perdagangan tidak aktif). Karakteristik waktu perdagangan ini mempengaruhi cara pengambilan harga.
Untuk aset 7×24H (misalnya BTC), harga dapat diperoleh dari CEX/DEX atau oracle terpercaya secara stabil:
Untuk aset non-7×24H (misalnya saham), hanya saat jam pasar terbuka harga pasar eksternal yang cukup likuid dan stabil dapat diperoleh; selama jam tutup pasar, perlu mekanisme penetapan harga lain.
Contoh pasar perpetual saham di trade.xyz:
Saat pasar saham buka, gunakan feed harga stabil dari oracle seperti Pyth.
Saat pasar tutup, gunakan harga penutupan terakhir dan sesuaikan berdasarkan tekanan order internal. Harga mark dibatasi dalam rentang 1 / max_leverage dari harga penutupan terakhir (misalnya, Tesla 10x -> 10%).
Likuidasi
HIP-3 umumnya menggunakan logika likuidasi HyperCore, sehingga trigger likuidasi mengikuti platform: saat nilai posisi bersih (isolated position value) tidak cukup memenuhi margin maintenance, posisi masuk status likuidasi.
Pengambilan keputusan likuidasi didasarkan pada harga mark, bukan harga transaksi tertentu.
Rumus harga likuidasi:
side = 1 (long), -1 (short)
l: tingkat margin maintenance
Nilai MMR diambil dari margin tier posisi terkait: baca dari margin tier tersebut untuk mendapatkan margin maintenance (mmr):
Jika ada tier, harga likuidasi sesuai dengan tier posisi tersebut dan menggunakan margin yang berlaku.
margin_available
isolated: isolated_margin - maintenance_margin_required
Setelah masuk status likuidasi, sistem akan prioritas menutup posisi dengan order pasar; jika risiko dapat dikendalikan, sisa margin tetap milik trader.
Namun, dalam kedalaman pasar yang kurang atau lonjakan harga, harga eksekusi nyata bisa jauh dari harga mark, menyebabkan “celah likuidasi”.
Nilai posisi isolated: nilai bersih posisi isolated pada harga mark saat ini (setelah laba/rugi posisi dikurangi margin yang terkait).
ADL (Auto-Deleveraging):
Dalam kondisi ekstrem, mekanisme ADL( dapat digunakan sebagai langkah penanggulangan:
Jika nilai posisi isolated menjadi negatif, trigger ADL, dan posisi lawan di order book akan dipaksa untuk mengurangi/menutup posisi berdasarkan unrealized PnL dan leverage, mengisi kekurangan dengan keuntungan lawan, mencegah kerugian sistemik.
Pengurutan dilakukan berdasarkan:
previous mark price: harga mark terakhir sebelum ADL dipicu.
Contoh:
Sebelum ADL, harga mark = 3.000.
Karena batas feed oracle, harga mark terbaru maksimal 2.970 (-1%).
Namun, order book tipis, dan saat order pasar likuidasi masuk, harga eksekusi rata-rata = 2.910 (-3%).
Kerugian posisi long dihitung di 2.910, bisa menyebabkan nilai posisi bersih turun di bawah nol (celah), sehingga ADL dipicu.
ADL akan memilih posisi lawan (yang profit) dan menutup posisi secara paksa di harga previous mark = 3.000, mengalihkan kerugian ke pihak yang berlawanan.
0x3 Risiko Umum:
Pengawasan dan Risiko Kunci
Sistem penalti (Slashing): hak untuk menuntut tanggung jawab
HIP-3 menyerahkan hak “penambahan dan pengoperasian” kepada builder, sekaligus mengatur aturan penalti yang dapat dieksekusi: builder harus staking HYPE, dan jika terbukti melakukan operasi tidak tepat, validator dapat melakukan voting untuk penalti dan membakar stake-nya.
Persyaratan staking
Mainnet mensyaratkan builder menahan staking 500k HYPE, bahkan jika semua pasar dihentikan, harus dipertahankan selama 30 hari (tanggung jawab tidak hilang langsung saat dihentikan).
Proses dan voting
Jika terjadi operasi pasar jahat, validator dapat menginisiasi voting berbobot staking untuk memutuskan penalti terhadap builder.
Prinsip penilaian
Resmi dinyatakan: penalti tidak dibedakan berdasarkan “malicious / kurang kompeten / key stolen”, tetapi berdasarkan apakah tindakan builder menyebabkan status tidak valid, downtime berkepanjangan, atau penurunan performa.
Persentase penalti
Persentase penalti diputuskan oleh voting validator, dengan batas atas:
Untuk invalid atau downtime panjang: maksimal 100%
Downtime singkat: maksimal 50%
Penurunan performa: maksimal 20%
Token staking yang dikenai penalti akan dihancurkan, bukan dikembalikan ke pengguna.
Risiko parameter konfigurasi
setOracle
Harga oracle biasanya berasal dari relayer builder, berpotensi terpusat. Jika kunci privat bocor atau diserang DDoS, harga oracle di pasar bisa dimanipulasi secara jahat atau kehilangan sinkronisasi jangka panjang.
haltTrading
Builder dapat menggunakan haltTrading untuk membatalkan semua order dan menutup posisi berdasarkan harga mark saat ini.
Operasi ini harus digunakan dengan hati-hati, misalnya:
Jika terdeteksi pasar diserang dan haltTrading dipakai untuk menutup posisi di harga mark, akan mengeksekusi keuntungan tak terduga dari penyerang), dan berisiko menyebabkan kerugian besar.
setMarginTableIds / InsertMarginTable
InsertMarginTable: mendefinisikan tabel margin baru, termasuk persyaratan margin dan leverage maksimum untuk aset tertentu.
setMarginTableIds: mengikat sebuah pasar ke margin table tertentu.
Pasar dengan likuiditas rendah dan kemampuan market making terbatas, jika leverage terlalu tinggi, meningkatkan risiko trigger ADL.
Perubahan mendadak pada marginTableId setara dengan mengubah margin maintenance, bisa menyebabkan banyak akun menjadi likuidasi secara bersamaan, memicu rangkaian likuidasi.
setMarginModes
Saat ini HIP-3 hanya mendukung isolated margin, di masa depan mungkin mendukung cross margin. Dalam satu DEX, pasar dengan likuiditas tinggi dan rendah bisa ada secara bersamaan, dan mode cross margin bisa menyebarkan risiko dari pasar likuiditas rendah ke pasar likuiditas tinggi. Sebelum ada solusi matang, tidak disarankan builder mengaktifkan cross margin.
Risiko oracle
Untuk aset 7×24H, risiko utama adalah ketergantungan pada keakuratan dan stabilitas oracle eksternal serta risiko terpusat relayer.
Untuk aset non-7×24H, risiko utama adalah pengambilan harga oracle selama jam non-perdagangan, yang bisa kurang likuid dan stabil.
Contoh trade.xyz: selama non-perdagangan, harga dihitung dari harga terakhir dan internal order book. Jika pasar saham tutup dan tidak ada oracle eksternal, harga bisa menyimpang jauh dari nilai sebenarnya, berpotensi menyebabkan likuidasi besar dan ADL.
Pada 14 Desember 2025, trade.xyz mengalami manipulasi pasar pada XYZ100-USDC(, dengan posisi short sekitar 398 XYZ100 (~10 juta USDC), menyebabkan harga menyimpang dan banyak posisi long dilikuidasi, yang kemudian memperparah penurunan harga dan likuidasi sekitar 13 juta USDC posisi long.
Risiko lain adalah kekurangan harga oracle yang stabil dan kontinu selama non-perdagangan, sehingga sistem bergantung pada harga terakhir dan internal order book, yang berpotensi menyebabkan lonjakan likuidasi saat pasar dibuka kembali.
Risiko ini bisa muncul saat pasar dibuka kembali, jika harga eksternal jauh berbeda dari harga internal selama non-perdagangan, menyebabkan ketidakseimbangan dan potensi likuidasi massal atau ADL.
0x4 Strategi Pengendalian Risiko
- Harga Oracle Stabil
Untuk aset non-24H seperti saham, tantangannya adalah harga selama non-perdagangan: kurangnya oracle stabil dan risiko manipulasi.
Solusi umum meliputi:
Menghentikan update harga oracle selama non-perdagangan, membatasi transaksi (misalnya, Lighter hanya mengizinkan pengurangan posisi saat non-perdagangan). Protocol seperti Optium menurunkan leverage maksimum selama non-perdagangan dan memaksa penutupan posisi yang melebihi batas.
Menggunakan mekanisme penetapan harga internal seperti trade.xyz, yang mengandalkan likuiditas internal dan algoritma saat data eksternal hilang.
Kedua solusi ini adalah kompromi antara keamanan dan pengalaman pengguna. Pendekatan pertama lebih ketat dalam manajemen risiko tetapi mengurangi pengalaman trading, sedangkan pendekatan kedua menjaga kontinuitas tetapi berisiko deviasi harga dari nilai sebenarnya.
Selama non-perdagangan, hindari sistem penetapan harga yang sepenuhnya internal, dan gunakan referensi eksternal untuk mengurangi risiko deviasi dan lonjakan harga. Referensi yang bisa dipakai:
Blue Ocean ATS
Sebagai pasar after-hours/night trading, menyediakan harga kontinu yang lebih cepat dari penutupan terakhir, membantu penetapan oracle selama non-perdagangan atau sebagai indikator risiko.
IG weekend CFD quotes
Harga CFD akhir pekan sebagai sinyal ekspektasi pasar, bisa digunakan sebagai referensi eksternal selama non-perdagangan dan sebagai alat monitoring.
Kedua sumber ini mampu memberikan sinyal harga selama non-perdagangan, tetapi bukan pengganti langsung pasar spot utama, melainkan sebagai acuan dan peringatan risiko.
2( Verifikasi Harga
Harga oracle HIP-3 berasal dari relayer builder, berpotensi terpusat. Disarankan membangun mekanisme verifikasi harga yang memungkinkan pengguna atau institusi melakukan validasi off-chain terhadap keabsahan dan keadilan harga)seperti RedStone, mengemas harga beserta sumber dan tanda tangan ke dalam data on-chain.
Data Publik
Spesifikasi algoritma: mengungkapkan algoritma dan mekanisme secara detail.
Daftar sumber data: harus terbuka dan tidak bisa diintervensi builder, serta menyediakan API dan parameter secara lengkap.
Standar pengiriman harga: hak akses panggilan setOracle, frekuensi trigger, dan batas fluktuasi.
b. Bukti Harga
Setiap panggilan setOracle harus menghasilkan bukti ()Proof(), yang mencakup:
Input: respons asli dari sumber data di waktu tertentu dan timestamp.
Perhitungan: nilai tengah yang dapat dihitung ulang, hasil perhitungan intermediate.
Output: harga oracle yang diunggah ke chain.
Buat serialisasi Proof, dapatkan proofHash, dan tanda tangan dari oracleUpdater.
c. Unggah Bukti ke Chain
Kelola daftar ProofHash secara berurutan, buat Merkle tree, dan unggah MerkleRoot secara periodik (misalnya setiap jam/hari).
d. Verifikasi
Sediakan alat open-source atau web, masukkan timestamp atau tx hash setOracle, dan verifikasi semua data terkait, termasuk tanda tangan, timestamp, dan MerkleRoot, serta lakukan perhitungan harga oracle berdasarkan algoritma terbuka.
- Pengawasan Risiko
Verifikasi harga menjadikan proses setOracle dapat dihitung ulang dan diaudit, mengatasi kepercayaan terhadap feed harga; tetapi tidak mampu mencegah pasar menjadi tidak terkendali—gangguan feed, deviasi harga, dan penurunan kedalaman, terutama saat volume posisi terbuka besar ()OI(), sangat rentan menyebabkan likuidasi berantai dan ADL. Oleh karena itu, deteksi dini kondisi abnormal pasar dan tindakan preventif harus dilakukan untuk menjaga risiko tetap dalam batas terkendali.
- Aspek Harga
a. Kegagalan Feed Oracle
Indikator pemantauan:
Menggunakan data on-chain untuk mendeteksi feed yang terblokir:
Batasan tingkat:
Tindakan:
Level 1: Deteksi kesehatan relayer, beralih ke relayer cadangan, dan kirim peringatan lengkap dengan laporan kesehatan dan info relayer.
Level 2: Turunkan batas OI melalui setOpenInterestCaps:
b. Deviasi Harga
Indikator:
Batasan:
Level 1: Jika ≥ 2 dari A, B, D melebihi batas
Level 2: Jika ≥ 3 dari A, B, C, D melebihi batas dan berlangsung X detik
Tindakan:
Level 1: Turunkan batas OI
Level 2: Jika deviasi berlanjut, perbarui margin table secara bertahap, turunkan leverage, aktifkan mekanisme clamp relayer
Level 3: Jika deviasi terus berlanjut, kirim peringatan terakhir, dan akhirnya builder memutuskan hentikan pasar (haltTrading).
- Aspek Order Book
a. Kedalaman Pasar
Pemantauan:
depth_band)±x%(: volume order nyata dalam rentang harga sekitar mid ±x%.
spread = bestAsk - bestBid: selisih harga, indikator potensi keretakan order book.
aggressiveVolume_Δt: volume order agresif dalam Δt (taker volume).
impact_ratio = aggressiveVolume_Δt / depth_band: rasio penyerapan.
Deteksi:
Jika kombinasi berikut muncul, risiko meningkat:
penurunan depth_band, disertai kenaikan spread dan impact_ratio.
Tindakan:
Level 1: Turunkan batas OI
Level 2: Paksa turunkan leverage melalui setMarginTableIds dan kurangi posisi berisiko tinggi.
b. Order Palsu
Pemantauan:
lonjakan dan penurunan mendadak pada depth_band dalam waktu singkat.
Tindakan:
Level 1: Turunkan batas OI
Level 2: Jika deviasi harga parah, pertimbangkan hentikan pasar.
- Aspek Posisi
Tujuan pemantauan posisi bukan memprediksi arah, tetapi mendeteksi apakah pasar beralih dari trading ke posisi spekulatif: saat OI cepat meningkat, posisi terkonsentrasi, dan PnL mayoritas mendekati batas ekstrem, setiap gangguan eksternal bisa memperbesar risiko likuidasi dan ADL. Oleh karena itu, prioritas tindakan posisi biasanya lebih rendah dibandingkan aspek harga dan order book.
a. OI Berlebih dalam Jangka Pendek
Pemantauan:
OI_notional: volume posisi terbuka
Volume_24h_notional: volume transaksi 24 jam
Rasio: OI_notional / Volume_24h_notional, meningkat tajam menandakan pasar beralih dari posisi jangka pendek ke posisi spekulatif, biasanya menandai potensi volatilitas besar.
Tindakan:
Level 1: Peringatan saat batas tercapai.
b. PnL Mayoritas
Pemantauan:
Majority Side: pihak dengan posisi terbanyak (Long atau Short)
avgEntry_major: rata-rata harga masuk posisi mayoritas
size_major: ukuran posisi mayoritas
PnL mayoritas:
Rasio PnL mayoritas:
Tindakan:
Level 1: Peringatan saat batas tercapai.
Level 2: Jika terus menerus, turunkan batas OI melalui setOpenInterestCaps.
0x5 Penutup
Inti narasi HIP-3 sebenarnya adalah: mengubah proses “penambahan produk baru” dari keputusan segelintir orang menjadi kemampuan protokol yang bisa dipanggil selama memenuhi syarat—builder cukup melakukan staking untuk memulai DEX perpetual mereka sendiri di HyperCore, meluncurkan pasar secara gratis, lalu melalui lelang mendapatkan kuota lebih banyak, sehingga ekspansi pasar bertransformasi dari “menunggu persetujuan” menjadi “berkembang sesuai aturan”.
Namun yang sama penting, HIP-3 tidak menghilangkan risiko, melainkan mengubah posisi dan bentuk risiko tersebut. Bagian yang sebelumnya ditanggung oleh governance platform kini lebih banyak bergantung pada kualitas input dan operasi builder: feed harga setOracle dan frekuensinya, pilihan dan pembatasan markPx, pengaturan leverage berdasarkan tier margin, mekanisme penetapan harga non-24H selama non-perdagangan, serta kekuasaan haltTrading yang bisa memperbesar kerugian sekaligus membatasi kerugian. Setiap langkah yang tidak tepat bisa memperbesar risiko likuidasi berantai dan ADL, sehingga masalahnya bukan lagi “bisa listing” tetapi “setelah listing, bisa berjalan stabil”.
Inti dari pengelolaan risiko di level protokol adalah mengubah hak akses menjadi hak yang dapat dipertanggungjawabkan: staking + voting validator untuk penalti memberi batasan biaya atas operasi tidak tepat; sekaligus pembatasan harga dan leverage (clamp, interval update, batas fluktuasi, isolasi posisi) berusaha mengendalikan risiko ekstrem agar tetap dalam batas aman. Dengan demikian, sebenarnya HIP-3 mengusung prinsip: ekspansi melalui keterbukaan, keamanan melalui pembatasan, dan keberlanjutan melalui verifikasi serta akuntabilitas.
