HIP-3（Hyperliquid Improvement Proposal 3） telah diluncurkan di mainnet selama sekitar 3 bulan, sejak peluncurannya, volume transaksi pasar kustom pihak ketiga telah menembus 13 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: jenis aset apa yang dapat diperdagangkan, kapan diluncurkan, parameter apa yang ditetapkan, semuanya sebagian besar ditentukan oleh proses operasional dan manajemen risiko. Bahkan di on-chain, kategori kontrak perpetual yang merupakan infrastruktur dasar ini juga 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 men-deploy pasar kontrak perpetual baru di atas basis trading dan clearing yang sama, sehingga kekuasaan penambahan produk secara terpusat dapat secara sistematis dialihdayakan ke ekosistem. Perbaikan ini tidak hanya menurunkan ambang inovasi, tetapi juga memperkuat skalabilitas pasar. Namun, risiko keamanan potensial dari antarmuka terbuka tidak boleh diabaikan, bagaimana memastikan 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 chain miliknya sendiri. Untuk HIP-3, hal terpenting adalah: matching, clearing, dan settlement disediakan secara terpusat oleh protokol dasar, kemampuan pasar dapat digunakan kembali, bukan membangun sistem trading dari nol.
**Hyperliquid mengadopsi arsitektur dua lapis: #HyperCore：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。#HyperEVM：**Lapisan aplikasi, dapat menjalankan smart contract yang kompatibel dengan EVM.
Pasar perp native Hyperliquid (validator-operated perps) masih lebih mirip proses tradisional CEX saat listing: resmi menambahkan kontrak perpetual sesuai keinginan komunitas; sedangkan delisting dilakukan oleh voting node validator.
Protokol Hyperliquid akan mendukung builder-deployed perps (HIP-3), sebuah tonggak penting menuju desentralisasi penuh proses listing perpetual.
Protokol Hyperliquid akan mendukung kontrak perpetual yang di-deploy oleh builder (HIP-3), ini adalah tonggak utama untuk mewujudkan proses listing kontrak perpetual yang benar-benar terdesentralisasi.
0x2 HIP-3：Pasar yang di-deploy pengembang
Konsep HIP-3 sangat sederhana: tanpa mengubah basis trading dan clearing Hyperliquid, membuka kemampuan “penambahan pasar perpetual” kepada builder yang memenuhi syarat. Builder bertanggung jawab mendefinisikan parameter utama pasar dan harga feed/operasi, sementara protokol menggunakan mekanisme margin dan clearing yang seragam untuk eksekusi dan manajemen risiko; dengan demikian, “penambahan produk” dari proses platform menjadi antarmuka standar yang dapat dipanggil.
Secara sederhana: builder dapat menambahkan pasar kontrak perpetual berbasis mesin HyperCore, mengatur harga feed dan parameter pasar secara mandiri.
Batas tanggung jawab builder: dalam HIP-3, builder bertanggung jawab atas dua hal untuk sebuah pasar perp (market): mendefinisikan pasar dan mengoperasikan pasar.
Definisi pasar (Market definition): resmi dirangkum sebagai oracle definition + contract specifications. Secara operasional, minimal mencakup:
Definisi oracle: termasuk initial oraclePx dan sumber harga. Saat mendefinisikan pasar, builder harus secara jelas mendefinisikan aset atau sumber data yang memiliki kejelasan, manipulasi yang sulit, dan substansi ekonomi; saat mendaftarkan aset, harus menyediakan initial oraclePx.
Spesifikasi kontrak: secara API mendefinisikan parameter pasar seperti “simbol aset / unit terkecil / leverage maksimum” (coin, szDecimals, maxLeverage, dll).
Pemilihan DEX: builder pertama-tama men-deploy sebuah perp DEX (setiap DEX memiliki margin, order book, dan pengaturan deployer yang terpisah), dan dapat memilih aset quote apa pun sebagai jaminan DEX tersebut (misalnya USDC), setiap pasar perp akan terkait dengan satu DEX.
Operasi pasar (Market operation): yang disebutkan resmi adalah pengaturan harga oracle / batas leverage / settlement jika diperlukan, secara rinci:
Update feed harga: melalui antarmuka setOracle untuk terus mengupdate Oracle Price pasar.
Batas leverage: melalui penyesuaian margin table yang sesuai untuk aset, membatasi leverage maksimum—batas leverage diatur berdasarkan ukuran posisi, membatasi leverage yang tersedia dalam batas yang telah ditetapkan.
Settlement bila 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 lengkap listing pasar
-
Stake: mainnet mensyaratkan builder menahan staking 500k HYPE; dan meskipun builder men-stop semua pasar di DEX-nya, syarat staking harus dipertahankan selama 30 hari.
-
Build: setelah memenuhi ambang staking, builder dapat men-deploy satu perp DEX. Setiap perp DEX adalah domain trading independen: margin, order book, dan pengaturan deployer terpisah.
-
Set collateral: collateral DEX ini dapat memilih aset quote apa saja, tetapi jika aset quote tersebut kehilangan status permissionless quote asset (diputuskan oleh voting validator), maka perp DEX yang menggunakan aset tersebut sebagai collateral akan dinonaktifkan.
-
Add markets: tiga pasar pertama dapat langsung diluncurkan; untuk menambah pasar selanjutnya, harus melalui Dutch auction untuk mendapatkan “kuota tambahan”.
-
Operasikan pasar: setelah pasar diluncurkan, pekerjaan builder beralih ke “menjaga kestabilan pasar”, yaitu pengoperasian pasar.
-
Unstake: setelah semua pasar di DEX selesai diselesaikan, staking 500k HYPE dapat dicabut, dan proses unstake akan masuk ke antrean unstaking selama 7 hari, selama waktu ini staking tetap berisiko dikenai penalti.
Dutch auction: siklus saat ini adalah 31 jam per putaran, harga awal adalah 2x harga akhir terakhir (harga transaksi / harga terendah).
SetOracle：Tiga jenis input harga
Di HyperCore, oracle price terutama digunakan untuk mengaitkan dan menghitung biaya dana (funding), sedangkan mark price digunakan sebagai harga penanda dalam skenario manajemen risiko seperti margin dan liquidation (juga untuk trigger TP/SL).
Di pasar native, mark price bukan hasil langsung feed harga tertentu, melainkan median dari tiga harga berikut:
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (harga order book lokal)
Harga tengah dari beberapa CEX perpetual contract (perp mid prices) yang berbobot
Namun di HIP-3, fungsi oracle price dan mark price tidak berubah, tetapi mekanisme perhitungannya berubah:
1. Input setOracle
a. oraclePx (harus )
Definisi inti sesuai HyperCore.
b. markPx (opsional)
Dapat mengirimkan 0–2 set harga mark eksternal sebagai kandidat harga mark yang sebenarnya.
c. externalPerpPx (harus)
Sebagai referensi harga mark, digunakan untuk mencegah mark price menyimpang secara tiba-tiba.
Builder biasanya men-deploy relayer node untuk feed harga, oraclePx
dihitung oleh relayer berdasarkan sumber harga eksternal; markPx dihitung dengan algoritma kustom relayer; externalPerpPx berasal dari bobot median harga perp dari beberapa CEX.
2. Harga mark aktual
Mark price di HIP-3 tidak langsung menggunakan feed dari setOracle:
Menghitung local mark: median(best bid, best ask, last trade).
Gabungkan local mark dan markPx (0–2 set), lalu ambil median, hasilnya adalah mark price baru.
3. Pembatasan setOracle
Frekuensi update: minimal jarak 2.5 detik antar panggilan, jika dalam 10 detik markPx tidak diupdate, akan kembali ke local mark.
Batas perubahan: setiap perubahan markPx tidak lebih dari ±1%; semua harga akan dikunci (clamp) dalam rentang 10× dari nilai pembukaan hari itu.
Mekanisme penetapan harga 7×24H & non 7×24H
Di HIP-3, pasar perpetual mendukung listing aset apa saja, yang terbagi menjadi aset 7×24H (perdagangan nonstop 24 jam) dan non 7×24H (hanya aktif di jam tertentu, pasar spot di luar jam tidak bisa diperdagangkan). Karakteristik waktu perdagangan ini menentukan cara pengambilan harga yang berbeda.
Untuk aset 7×24H (misalnya BTC), harga dapat diperoleh dari CEX/DEX atau oracle terpercaya yang menyediakan harga stabil:
Untuk aset non 7×24H (misalnya saham), hanya saat jam pasar terbuka dapat memperoleh harga dari pasar eksternal yang cukup likuid dan stabil; untuk menjaga agar aset ini tetap berjalan nonstop di HIP-3, selama jam tutup pasar harus menggunakan mekanisme penetapan harga lain.
Sebagai contoh pasar perpetual saham di trade.xyz:
Saat jam pasar terbuka, gunakan feed harga stabil dari oracle eksternal seperti Pyth.
Saat pasar tutup, gunakan harga penutupan terakhir dari saham tersebut, dikombinasikan dengan tekanan order internal untuk penyesuaian harga. Harga mark dibatasi dalam rentang ±1 dari harga penutupan terakhir / max leverage (misalnya, Tesla 10x -> 10%).
Liquidasi
Pasar HIP-3 sebagian besar menggunakan logika liquidasi HyperCore, sehingga trigger liquidasi mengikuti platform: ketika nilai posisi bersih (isolated position value) tidak cukup menutupi margin pemeliharaan, posisi masuk status dapat dilikuidasi.
Penilaian liquidasi didasarkan pada mark price, bukan harga transaksi tertentu.
Rumus harga liquidasi:
side = 1 (long), -1 (short)
l : yaitu tingkat margin pemeliharaan
dan MAINTENANCE_LEVERAGE diambil dari tier margin posisi terkait: baca terlebih dahulu tingkat margin pemeliharaan (mmr):
Jika ada tier, harga liquidasi sesuai tier posisi tersebut, gunakan margin requirement dari tier itu.
margin_available
isolated：isolated_margin - maintenance_margin_required
Setelah masuk status likuidasi, sistem akan terlebih dahulu menutup posisi dengan order pasar dari order book; jika risiko dapat dikembalikan ke zona aman, sisa margin tetap milik trader.
Namun, dalam kedalaman pasar yang kurang atau lonjakan harga, harga transaksi penutupan bisa jauh lebih tinggi atau rendah dari mark price, menyebabkan “celah likuidasi”.
Nilai posisi isolated: nilai bersih posisi isolated pada mark price saat ini (termasuk profit/loss posisi dikurangi margin yang terikat).
ADL:
Pada kondisi ekstrem, mekanisme ADL (Auto-Deleveraging) dapat digunakan sebagai langkah penanggulangan:
Ketika nilai posisi isolated menjadi negatif, ADL akan dipicu, posisi lawan akan dipaksa mengurangi/menutup posisi berdasarkan unrealized profit/loss dan leverage, di harga previous mark, untuk menutup celah dan mencegah kerugian sistemik.
Pengurutan dilakukan berdasarkan:
previous mark price: harga mark terakhir yang dicatat sebelum ADL dipicu.
Contoh:
Sebelum ADL, harga mark = 3.000.
Karena batas setOracle, harga mark terbaru maksimal 2.970 (-1%).
Namun, order book tipis, setelah order market liquidasi masuk, harga transaksi rata-rata = 2.910 (-3%).
Kerugian posisi long dihitung di 2.910, bisa menyebabkan nilai posisi isolated turun di bawah nol (celah), sehingga ADL dipicu.
ADL kemudian memilih posisi dari lawan (yang profit), dan menutupnya di harga previous mark = 3.000, memindahkan celah ke pihak yang profit, mengurangi kerugian sistemik.
0x3 Gambaran risiko: batasan akuntabilitas dan risiko utama
Sistem penalti (Slashing): hak yang dapat dipertanggungjawabkan
HIP-3 menyerahkan “kekuasaan penambahan dan pengoperasian” kepada builder, sekaligus mengatur tanggung jawab melalui aturan penalti yang dapat dieksekusi: builder harus melakukan staking HYPE, dan jika terbukti melakukan operasi tidak tepat, validator dapat melakukan voting untuk penalti dan membakar (burn) stake tersebut.
Persyaratan staking
Mainnet mensyaratkan builder menahan staking 500k HYPE, bahkan jika builder men-stop semua pasar, syarat ini harus dipertahankan selama 30 hari (tanggung jawab tidak hilang secara otomatis saat pasar dihentikan).
Pemungutan suara dan pengambilan keputusan
Saat terjadi operasi pasar yang jahat, validator dapat menginisiasi dan menjalankan voting berbobot berdasarkan staking untuk memutuskan apakah stake builder harus dikenai penalti.
Prinsip penilaian
Resmi dinyatakan: penalti tidak membedakan alasan “jahat / kurang kemampuan / kunci privat dicuri”, yang utama adalah apakah perilaku builder menyebabkan kondisi tidak valid, downtime berkepanjangan, atau penurunan performa.
Besaran penalti
Persentase penalti diputuskan oleh voting validator, dengan batas maksimum:
Untuk kondisi tidak valid atau downtime panjang: maksimal 100%
Untuk downtime singkat: maksimal 50%
Untuk penurunan performa: maksimal 20%
Token stake 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 terkena serangan DDoS, harga oracle di pasar bisa dimanipulasi secara jahat atau terlepas dari anchor dalam waktu lama.
haltTrading
Builder dapat menggunakan haltTrading untuk membatalkan semua order di pasar dan menutup posisi berdasarkan harga mark saat ini.
Operasi ini harus digunakan dengan hati-hati, misalnya:
Saat terdeteksi adanya manipulasi jahat, memanggil haltTrading untuk menutup posisi di harga mark akan langsung mengakibatkan keuntungan tak terduga dari penyerang (, dan bisa menyebabkan kerugian besar.
setMarginTableIds / InsertMarginTable
InsertMarginTable: mendefinisikan tabel margin baru, termasuk persyaratan margin dan leverage maksimum untuk jenis aset tertentu.
setMarginTableIds: mengikat sebuah pasar ke marginTableId tertentu.
Untuk pasar dengan likuiditas rendah / kemampuan market making terbatas, pengaturan leverage maksimum terlalu tinggi akan meningkatkan kemungkinan trigger ADL.
Peralihan mendadak ke marginTableId yang berbeda sama artinya dengan mengubah margin maintenance, yang bisa menyebabkan banyak akun berubah dari aman 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, bisa ada pasar dengan likuiditas tinggi dan rendah, mode cross margin dapat menularkan risiko dari pasar likuiditas rendah ke pasar likuiditas tinggi. Oleh karena itu, sebelum ada solusi matang dari pihak resmi, tidak disarankan builder menggunakan cross margin.
Risiko oracle
Untuk aset 7×24H, risiko utama adalah ketergantungan pada keakuratan dan stabilitas layanan oracle eksternal, serta risiko terpusat dari relayer.
Untuk aset non 7×24H, risiko lebih besar adalah pengambilan atau perhitungan harga oracle selama jam non perdagangan.
Sebagai contoh trade.xyz, selama jam non perdagangan, harga diambil dari harga oracle eksternal terakhir dan harga internal pasar. Saat akhir pekan, pasar saham perpetual kekurangan likuiditas (order book menipis dan market maker berkurang), tanpa harga oracle eksternal sebagai anchor. Meskipun ada batasan fluktuasi harga (1/max_leverage), batas ini tetap terlalu tinggi untuk aset dengan volatilitas rendah, sehingga fluktuasi harga dalam batas ini tetap bisa menyebabkan likuidasi besar dan ADL.
Pada 14 Desember 2025, trade.xyz mengalami manipulasi pasar pada XYZ100-USDC ) yang terhubung ke NASDAQ100(, dengan pembukaan posisi short 398 XYZ100 (~10 juta USDC), menyebabkan harga menyimpang dari anchor, banyak posisi long dilikuidasi, dan harga terus turun, akhirnya sekitar 13 juta USDC posisi long dilikuidasi.
![图片])https://img-cdn.gateio.im/webp-social/moments-46485922603bcc451881e82987685518.webp(![图片])https://img-cdn.gateio.im/webp-social/moments-3f11b34efd760ad2a07f657c92b39ba7.webp(
https://x.com/bartdothl/status/2000292798755684839
Di sisi lain, selama jam non perdagangan, kekurangan harga oracle yang stabil dan dapat di-anchor, pasar biasanya hanya mengandalkan “harga terakhir dari luar + internal order book” yang terbatas, misalnya trade.xyz membatasi fluktuasi maksimal 1/max_leverage.
Risiko muncul saat pasar dibuka kembali: pasar eksternal secara tiba-tiba memberikan harga yang jelas, dan jika ada loncatan signifikan dari harga internal selama tutup pasar, sistem bisa tetap dikunci (clamp) sehingga harga eksternal dan harga yang bisa diperdagangkan menyimpang jauh, atau saat kembali ke anchor eksternal, terjadi re-pricing cepat; kedua skenario ini dapat memicu tekanan likuidasi secara masif dalam waktu singkat, bahkan meningkatkan kejadian ADL.
0x4 Strategi pengendalian risiko
- Harga oracle yang stabil
Untuk aset non 24 jam seperti saham, tantangannya terutama pada harga selama tutup pasar: kurangnya harga anchor eksternal yang stabil, pasar lebih rentan dimanipulasi atau drift saat volume tipis.
Solusi umum saat ini terbagi menjadi dua:
Langsung menghentikan update harga oracle, membatasi atau menangguhkan perdagangan selama jam tersebut (misalnya Lighter protocol saat tutup pasar hanya mengizinkan pengurangan posisi). Protocol Optium juga menurunkan leverage maksimum selama tutup pasar, dan memaksa penutupan posisi yang melebihi batas.
Menggunakan mekanisme “penetapan harga internal” seperti trade.xyz, yang mengandalkan likuiditas dan algoritma internal saat data eksternal hilang.
Kedua solusi ini mencerminkan trade-off antara keamanan dan pengalaman pengguna. Solusi pertama lebih ketat dalam pengendalian risiko tetapi mengorbankan kenyamanan trading, sedangkan solusi kedua menjaga kontinuitas trading tetapi berisiko harga internal menyimpang dari nilai aset sebenarnya.
Selama masa tutup pasar, sebaiknya tidak membiarkan penetapan harga sepenuhnya bergantung pada “harga internal murni”, melainkan memperkenalkan anchor eksternal yang dapat dijadikan referensi, untuk mengurangi risiko pelepasan anchor dan lonjakan harga. Referensi yang dapat dipilih meliputi:
Blue Ocean ATS
Sebagai tempat trading setelah jam pasar/ malam, dapat menyediakan referensi harga kontinu selama masa tutup pasar (lebih cepat dari harga penutupan terakhir), membantu pembuatan oracle harga selama tutup pasar atau sebagai indikator risiko pelepasan anchor.
IG weekend CFD quotes
Quote CFD akhir pekan dapat memberikan sinyal ekspektasi pasar akhir pekan, cocok sebagai anchor eksternal selama tutup pasar atau sebagai alat monitoring, membantu mendeteksi potensi loncatan harga saat pasar dibuka kembali.
Kedua sumber ini sama-sama dapat menyediakan sinyal harga selama masa tutup pasar, tetapi tidak sama dengan pasar spot saham secara langsung, lebih cocok sebagai anchor/monitoring dan sinyal peringatan risiko, bukan pengganti mutlak.
- Verifikasi harga
Harga oracle HIP-3 berasal dari relayer server yang disetting builder, berpotensi terpusat. Untuk mengatasi ini, disarankan builder membangun mekanisme verifikasi harga yang memungkinkan siapa saja, termasuk pengguna dan institusi, melakukan verifikasi off-chain terhadap keaslian dan keadilan harga(seperti RedStone, mengemas nilai harga beserta sumber data dan tanda tangan ke dalam proof yang diunggah ke chain).
Data terbuka
Spesifikasi algoritma: mengungkapkan algoritma dan mekanisme secara detail
Daftar sumber data: setiap sumber data harus terbuka dan tidak dapat diintervensi oleh builder, serta mengungkapkan API dan parameter secara lengkap
Spesifikasi pengiriman harga: hak akses panggilan setOracle, frekuensi trigger, dan batas fluktuasi
b. Bukti harga
Setiap panggilan setOracle harus menghasilkan bukti yang sesuai )Proof(, yang mencakup:
Inputs: respons asli dari setiap sumber data pada waktu tersebut (atau field yang dinormalisasi), dan timestamp pengambilan.
Perhitungan: nilai tengah yang dapat dihitung ulang, hasil perhitungan intermediate di setiap langkah.
Outputs: harga oracle yang di-unggah ke chain.
Proof harus diserialisasi, menghasilkan proofHash, dan signer dari oracleUpdater menandatangani proofHash tersebut.
c. Pengunggahan bukti ke chain
Memelihara daftar, menulis setiap proofHash secara berurutan ke dalam Merkle tree.
Setiap periode tertentu (misalnya setiap jam/hari), menerbitkan MerkleRoot dan mengunggah ke chain.
d. Verifikasi
Menyediakan tools open-source atau web interface, pengguna dapat memasukkan rentang waktu atau tx hash dari setOracle tertentu, dan mendapatkan semua data di atas.
Verifikasi tanda tangan, timestamp, MerkleRoot, dan membandingkan harga oracle berdasarkan algoritma terbuka.
- Monitoring risiko
Verifikasi harga mengubah proses setOracle menjadi “dapat dihitung ulang dan diaudit”, menyelesaikan masalah kepercayaan feed harga; tetapi tidak dapat mencegah pasar menjadi tidak terkendali saat berjalan—gangguan feed harga, deviasi harga, dan kedalaman pasar yang menurun, jika ditambah dengan volume posisi terbuka yang besar (OI), sangat rentan menyebabkan evolusi abnormal menjadi rangkaian likuidasi dan ADL. Oleh karena itu, harus mendeteksi dini sinyal abnormal pasar dan memicu tindakan selama window, untuk menekan risiko dalam batas terkendali.
- Sisi harga
a. Kegagalan feed harga oracle
Indikator pemantauan:
Langsung menggunakan data on-chain untuk menilai apakah feed harga terhambat:
![图片])https://img-cdn.gateio.im/webp-social/moments-0b00e6148b093547c349b784ee8a5d73.webp(
Batasan threshold:
![图片])https://img-cdn.gateio.im/webp-social/moments-91427ad8a0b81cb032ef1301a8f1480b.webp(
Tindakan:
Level 1: melakukan health check relayer, beralih ke relayer cadangan; mengirim peringatan berisi laporan kesehatan dan info semua relayer.
Level 2: memanggil setOpenInterestCaps untuk menurunkan OI cap:
b. Pelepasan anchor harga
Indikator pemantauan:
![图片])https://img-cdn.gateio.im/webp-social/moments-7c1c3c62517dea1a5e3d2212cf94d88e.webp(
Threshold:
Level 1: di antara A, B, D, ≥ 2 melebihi threshold
Level 2: di antara A, B, C, D, ≥ 3 melebihi threshold dan berlangsung X detik
Tindakan:
Level 1: panggil setOpenInterestCaps untuk menurunkan batas OI
Level 2: jika deviasi berlangsung lama, secara bertahap perbarui margin table, turunkan leverage secara bertahap; relayer aktifkan mekanisme clamp
Level 3: jika kondisi Level 2 berlangsung terus, kirim peringatan, dan akhirnya builder yang memutuskan apakah akan panggil haltTrading untuk hentikan pasar.
- Sisi order book
a. Pengurangan kedalaman
Pemantauan:
depth_band)±x%(: volume order nyata dalam rentang harga ±x% di sekitar mid
spread = bestAsk - bestBid: selisih harga, untuk mengukur apakah order book “pecah”
aggressiveVolume_Δt: volume order aktif selama Δt (taker volume), digabungkan berdasarkan side trade
impact_ratio = aggressiveVolume_Δt / depth_band: rasio penyerapan
![图片])https://img-cdn.gateio.im/webp-social/moments-9f4243068d7d93570f6f2b0b2b12b845.webp(Deteksi: risiko meningkat saat kombinasi berikut muncul:
depth_band menurun, diikuti kenaikan spread dan impact_ratio
Tindakan:
Level 1: panggil setOpenInterestCaps untuk menurunkan OI cap = OI saat ini
Level 2: panggil setMarginTableIds untuk memaksa penurunan leverage, menghindari posisi leverage tinggi yang berisiko tinggi, dan paksa penutupan posisi berisiko tinggi tersebut.
b. Order palsu
Pemantauan:
depth_band tiba-tiba naik dan turun secara cepat dalam waktu singkat
Tindakan:
Level 1: panggil setOpenInterestCaps untuk menurunkan OI cap = OI saat ini
Level 2: jika disertai deviasi harga yang signifikan, pertimbangkan hentikan pasar.
- Sisi posisi
Tujuan pemantauan posisi bukan untuk “memprediksi arah”, tetapi untuk mendeteksi apakah pasar beralih dari trading driven ke posisi bertaruh: saat OI cepat bertambah, posisi terkonsentrasi tinggi, dan mayoritas posisi profit/loss mendekati ekstrem, setiap gangguan eksternal akan lebih mudah memperbesar rangkaian likuidasi / ADL. Oleh karena itu, tindakan di sisi posisi biasanya prioritasnya lebih rendah dibandingkan sisi harga dan order book.
a. OI berat dalam waktu singkat
Pemantauan:
OI_notional: volume posisi terbuka
Volume_24h_notional: volume transaksi 24 jam
Menghitung OI_notional / Volume_24h_notional, rasio yang meningkat cepat menandakan pasar beralih dari posisi jangka pendek ke posisi bertaruh, biasanya menandai potensi volatilitas besar.
![图片])https://img-cdn.gateio.im/webp-social/moments-cef36719cbaa5d3842ab96fa3706077c.webp(
Tindakan:
Level 1: beri peringatan saat batas tercapai.
b. Profit/loss mayoritas
Pemantauan:
Majority Side: pihak dengan posisi terbanyak dalam jangka waktu tertentu (Long atau Short)
avgEntry_major: rata-rata harga masuk posisi mayoritas
size_major: ukuran posisi mayoritas
Profit/loss mayoritas:
![图片])https://img-cdn.gateio.im/webp-social/moments-99f20a460fd512544a4857f863e5b4b5.webp(
Rasio profit/loss mayoritas:
![图片])https://img-cdn.gateio.im/webp-social/moments-bef3f769bd6715e3607d810b785185f8.webp(
Tindakan:
Level 1: beri peringatan saat batas tercapai.
Level 2: jika terus menerus tercapai batas, pertimbangkan panggil setOpenInterestCaps untuk menurunkan OI cap.
)# Penutup
Inti narasi HIP-3 sebenarnya adalah: mengubah proses “penambahan produk baru” dari keputusan segelintir orang menjadi kemampuan protokol yang dapat dipanggil sesuai syarat—builder cukup melakukan staking untuk memulai DEX perpetual sendiri di HyperCore, meluncurkan pasar secara gratis, dan kemudian melalui auction mendapatkan kuota lebih banyak, sehingga ekspansi pasar bertransformasi dari “menunggu persetujuan” menjadi “berkembang sesuai aturan”.
Namun yang sama jelas, HIP-3 tidak menghilangkan risiko, melainkan mengubah posisi dan bentuk risiko tersebut. Bagian yang sebelumnya ditanggung platform melalui governance dan risk management kini lebih banyak bergantung pada input dan kualitas operasi builder: feed harga dan frekuensi feed, pemilihan dan pembatasan markPx, tier leverage margin table, mekanisme penetapan harga non 7×24H selama masa tutup pasar, serta kekuasaan haltTrading yang bisa memperbesar kerugian sekaligus membatasi kerugian. Setiap langkah yang tidak tepat bisa memperbesar celah likuidasi, memicu celah dan ADL—permasalahan bukan lagi “bisa listing” atau tidak, tetapi “setelah listing, bisa berjalan stabil atau tidak”.
Inti dari protokol untuk mengatasi “outsourcing risiko” ini adalah mengubah hak akses menjadi hak yang dapat dipertanggungjawabkan: staking + voting validator untuk penalti memberi batasan biaya yang jelas atas operasi yang tidak tepat; sekaligus, pembatasan harga dan leverage (clamp, interval update, batas fluktuasi, isolasi per posisi) berusaha mengendalikan risiko ekstrem agar terkonsentrasi dalam batas yang dapat dikendalikan. Dengan demikian, proposisi utama HIP-3 menjadi: ekspansi melalui keterbukaan, keamanan melalui pembatasan, dan keberlanjutan melalui verifikasi dan akuntabilitas.
HIP-3 bukan untuk membuat penambahan produk baru lebih bebas, tetapi lebih standar—dapat di-deploy, dioperasikan, dan dipertanggungjawabkan. Agar standar ini benar-benar stabil, keberhasilannya sangat bergantung pada kualitas implementasi oracle/leverage/risk parameter dan monitoring saat berjalan. Jika Anda membangun parameter market, template parameter, sistem peringatan dan penanganan darurat berdasarkan HIP-3, atau membutuhkan audit dan dukungan keamanan berkelanjutan, silakan hubungi BlockSec.
