Bisakah perp multiaset menjadi sebuah kategori independen? Saat ini tidak ada yang bisa menjawab
Tapi kita bisa menelusuri lewat tiga tantangan desain untuk melihat apakah Hertzflow bisa melewatinya setelah peluncuran mainnet
Tantangan pertama: apakah pool LP perlu diisolasi
Volatilitas kripto tidak berada pada skala yang sama dengan valas. BTC turun 15% dalam sehari adalah hal yang lumrah, sedangkan USDJPY turun 1,5% dalam sehari sudah termasuk pergerakan besar
Jika ditempatkan dalam satu pool LP yang sama, ketika posisi kripto mengalami likuidasi besar (majestik/BOOM), mesin likuidasi akan memakan likuiditas LP, sementara posisi valas belum banyak bergerak—pada akhirnya pool LP “dikendalikan” oleh volatilitas kripto
Rencana @Hertzflow_xyz adalah isolasi berlapis: aset berbeda berjalan di pool masing-masing, dan LP memilih sendiri jenis risiko yang bersedia ditanggung. Arah ini sudah benar
Namun isolasi juga menimbulkan masalah baru. Volatilitas harian valas dan emas relatif kecil, dan volume transaksi jangka panjang cenderung rendah—likuiditas pada pool independen mudah menjadi tipis. Akibatnya, ketika ada order besar masuk, slippage jadi tinggi, bahkan bisa langsung ditolak
Karena itu diperlukan ambang batas minimal kedalaman yang berbeda untuk tiap kategori aset, atau memberi pembagian fee yang lebih tinggi kepada LP pada pool ber-volatilitas rendah untuk menarik mereka—bahkan memungkinkan pinjam-pakai likuiditas lintas pool dalam batas tertentu
Selain itu, lapisan agregasi Vault memiliki masalah keterlambatan rebalancing pada kondisi ekstrem. Strategi pool mendasarnya bergantung pada tiap pool yang terisolasi: ketika pool kripto “meledak”, apakah perintah rebalancing bisa dieksekusi dengan segera, dan apakah akan tersangkut di rantai (on-chain)—perlu pengujian tekanan (stress test) untuk memastikannya
Tantangan kedua: apakah settlement likuidasi lintas aset perlu saling terhubung (linked)
Dokumen menekankan isolasi pasar, tapi di akun yang sama tetap mungkin ada pemeriksaan risiko di level akun
Apakah likuidasi BTC akan memicu pemeriksaan paksa pada posisi emas, atau memicu penurunan posisi terkait (consequent deleveraging)? Jika terhubung, harus ada saklar jaminan margin independen yang jelas untuk trader. Jika tidak terhubung, pastikan ledakan satu pool tidak berdampak tidak langsung pada pool lain melalui shared oracle atau mesin likuidasi
Saat ini, dokumentasi publik belum menjelaskan implementasi akhir isolasi risiko di level akun dan level posisi. Setelah mainnet, harus dipastikan berdasarkan perilaku kontrak yang nyata
Ada laporan dari pengguna testnet: saat melakukan close position dengan leverage tinggi, harga likuidasi yang ditampilkan di frontend dan harga eksekusi aktual mengalami drift 2–3 detik. Alasannya adalah polling frontend tidak bisa mengikuti peristiwa di blockchain
Mainnet harus dioptimalkan sampai level milidetik. Kalau tidak, pengalaman pengguna untuk leverage tinggi langsung ambruk
Skenario “double kill” ekstrem harus dirancang dari awal. Pada 5 Agustus 2024, Nikkei jatuh 12%: BTC hari itu turun dari 60.000 menjadi 49.000, sedangkan USDJPY turun dari 146 menjadi 141
Jika saat itu ada perp multiaset yang sedang berjalan, semua beban harus mampu ditahan: throughput likuidasi, frekuensi pembaruan oracle, dan kemampuan LP untuk menambah likuiditas secara instan. Disarankan memprioritaskan penanganan aset ber-volatilitas tinggi dan menambahkan mekanisme circuit breaker
Tantangan ketiga: apakah oracle bisa melayani begitu banyak aset sekaligus
Hertzflow menggunakan verifikasi silang dengan banyak oracle, terutama Pyth
Tapi untuk valas, saham, dan komoditas, frekuensi pembaruan, aturan hari libur/penutupan pasar, serta penanganan lonjakan (gap) yang tidak normal benar-benar berbeda dengan kripto
Selama testnet, gangguan pada Pyth sudah pernah memicu maintenance. Yang perlu dilakukan adalah menetapkan bobot oracle khusus per kategori aset, penyesuaian dinamis terhadap confidence interval, dan switching sumber cadangan otomatis
Leverage harus dibuat benar-benar “nyata”. Situs resmi mengiklankan maksimal 1000x, GitBook menulis 500x, dan pada praktiknya batasnya berbeda tergantung aset dan mode. Untuk parameter mainnet, patokannya adalah yang resmi
Untuk aset non-kripto sebaiknya turunkan paksa batasnya: valas masuk akal di 100x sampai 200x, sedangkan kripto hanya boleh lebih tinggi. Kalau tidak, keterlambatan oracle di leverage tinggi akan menjadi pengali bencana
Pintu batas yang wajib sebelum peluncuran mainnet
Pertama, hingga awal Agustus 2026, masih belum ada laporan audit pihak ketiga yang dipublikasikan. Pencakupan penuh modul inti seperti likuidasi, rebalancing, pembatasan penarikan, dan role/izin adalah batas minimum. Ini salah satu ambang paling keras sebelum mainnet
Kedua, ketika tingkat pemanfaatan tinggi atau trader memiliki floating profit besar, penarikan memiliki batas. Diperlukan tampilan saldo real-time yang lebih transparan untuk menunjukkan jumlah yang tersedia, serta skenario tekanan mensimulasikan “keuntungan kolektif trader saat yang sama penarikan dilakukan”
Ketiga, seberapa bagus pun angka di testnet, pada awal mainnet kedalaman (depth) mungkin tidak cukup. Insentif LP di tahap awal, pembagian lebih besar (fee share), dan kedalaman penambangan (mining) dengan batas waktu—menentukan apakah setelah mainnet benar-benar ada likuiditas atau sekadar cerita selesai lalu uang ditarik
Kembali ke pertanyaan awal: apakah perp multiaset bisa menjadi kategori independen
Kebutuhannya nyata. Orang yang melakukan trading makro secara alami perlu melihat banyak pasar sekaligus; satu terminal yang mengelola semua posisi akan meningkatkan efisiensi—itu memang ada nilainya
Tapi apakah settlement (likuidasi) dan LP bisa mengendalikan volatilitas berbeda secara bersamaan, itulah garis penentu hidup-mati. Sebelum mainnet benar-benar berjalan di live trading, penyesuaian ini belum dilakukan dengan baik—risikonya jauh lebih besar daripada efisiensi yang terlihat di permukaan
Sebaliknya, jika berhasil dijalankan, itu tidak hanya mendefinisikan Hertzflow, melainkan juga standar untuk seluruh kategori
https://testnet.hertzflow.xyz
@Hertzflow_xyz
Tapi kita bisa menelusuri lewat tiga tantangan desain untuk melihat apakah Hertzflow bisa melewatinya setelah peluncuran mainnet
Tantangan pertama: apakah pool LP perlu diisolasi
Volatilitas kripto tidak berada pada skala yang sama dengan valas. BTC turun 15% dalam sehari adalah hal yang lumrah, sedangkan USDJPY turun 1,5% dalam sehari sudah termasuk pergerakan besar
Jika ditempatkan dalam satu pool LP yang sama, ketika posisi kripto mengalami likuidasi besar (majestik/BOOM), mesin likuidasi akan memakan likuiditas LP, sementara posisi valas belum banyak bergerak—pada akhirnya pool LP “dikendalikan” oleh volatilitas kripto
Rencana @Hertzflow_xyz adalah isolasi berlapis: aset berbeda berjalan di pool masing-masing, dan LP memilih sendiri jenis risiko yang bersedia ditanggung. Arah ini sudah benar
Namun isolasi juga menimbulkan masalah baru. Volatilitas harian valas dan emas relatif kecil, dan volume transaksi jangka panjang cenderung rendah—likuiditas pada pool independen mudah menjadi tipis. Akibatnya, ketika ada order besar masuk, slippage jadi tinggi, bahkan bisa langsung ditolak
Karena itu diperlukan ambang batas minimal kedalaman yang berbeda untuk tiap kategori aset, atau memberi pembagian fee yang lebih tinggi kepada LP pada pool ber-volatilitas rendah untuk menarik mereka—bahkan memungkinkan pinjam-pakai likuiditas lintas pool dalam batas tertentu
Selain itu, lapisan agregasi Vault memiliki masalah keterlambatan rebalancing pada kondisi ekstrem. Strategi pool mendasarnya bergantung pada tiap pool yang terisolasi: ketika pool kripto “meledak”, apakah perintah rebalancing bisa dieksekusi dengan segera, dan apakah akan tersangkut di rantai (on-chain)—perlu pengujian tekanan (stress test) untuk memastikannya
Tantangan kedua: apakah settlement likuidasi lintas aset perlu saling terhubung (linked)
Dokumen menekankan isolasi pasar, tapi di akun yang sama tetap mungkin ada pemeriksaan risiko di level akun
Apakah likuidasi BTC akan memicu pemeriksaan paksa pada posisi emas, atau memicu penurunan posisi terkait (consequent deleveraging)? Jika terhubung, harus ada saklar jaminan margin independen yang jelas untuk trader. Jika tidak terhubung, pastikan ledakan satu pool tidak berdampak tidak langsung pada pool lain melalui shared oracle atau mesin likuidasi
Saat ini, dokumentasi publik belum menjelaskan implementasi akhir isolasi risiko di level akun dan level posisi. Setelah mainnet, harus dipastikan berdasarkan perilaku kontrak yang nyata
Ada laporan dari pengguna testnet: saat melakukan close position dengan leverage tinggi, harga likuidasi yang ditampilkan di frontend dan harga eksekusi aktual mengalami drift 2–3 detik. Alasannya adalah polling frontend tidak bisa mengikuti peristiwa di blockchain
Mainnet harus dioptimalkan sampai level milidetik. Kalau tidak, pengalaman pengguna untuk leverage tinggi langsung ambruk
Skenario “double kill” ekstrem harus dirancang dari awal. Pada 5 Agustus 2024, Nikkei jatuh 12%: BTC hari itu turun dari 60.000 menjadi 49.000, sedangkan USDJPY turun dari 146 menjadi 141
Jika saat itu ada perp multiaset yang sedang berjalan, semua beban harus mampu ditahan: throughput likuidasi, frekuensi pembaruan oracle, dan kemampuan LP untuk menambah likuiditas secara instan. Disarankan memprioritaskan penanganan aset ber-volatilitas tinggi dan menambahkan mekanisme circuit breaker
Tantangan ketiga: apakah oracle bisa melayani begitu banyak aset sekaligus
Hertzflow menggunakan verifikasi silang dengan banyak oracle, terutama Pyth
Tapi untuk valas, saham, dan komoditas, frekuensi pembaruan, aturan hari libur/penutupan pasar, serta penanganan lonjakan (gap) yang tidak normal benar-benar berbeda dengan kripto
Selama testnet, gangguan pada Pyth sudah pernah memicu maintenance. Yang perlu dilakukan adalah menetapkan bobot oracle khusus per kategori aset, penyesuaian dinamis terhadap confidence interval, dan switching sumber cadangan otomatis
Leverage harus dibuat benar-benar “nyata”. Situs resmi mengiklankan maksimal 1000x, GitBook menulis 500x, dan pada praktiknya batasnya berbeda tergantung aset dan mode. Untuk parameter mainnet, patokannya adalah yang resmi
Untuk aset non-kripto sebaiknya turunkan paksa batasnya: valas masuk akal di 100x sampai 200x, sedangkan kripto hanya boleh lebih tinggi. Kalau tidak, keterlambatan oracle di leverage tinggi akan menjadi pengali bencana
Pintu batas yang wajib sebelum peluncuran mainnet
Pertama, hingga awal Agustus 2026, masih belum ada laporan audit pihak ketiga yang dipublikasikan. Pencakupan penuh modul inti seperti likuidasi, rebalancing, pembatasan penarikan, dan role/izin adalah batas minimum. Ini salah satu ambang paling keras sebelum mainnet
Kedua, ketika tingkat pemanfaatan tinggi atau trader memiliki floating profit besar, penarikan memiliki batas. Diperlukan tampilan saldo real-time yang lebih transparan untuk menunjukkan jumlah yang tersedia, serta skenario tekanan mensimulasikan “keuntungan kolektif trader saat yang sama penarikan dilakukan”
Ketiga, seberapa bagus pun angka di testnet, pada awal mainnet kedalaman (depth) mungkin tidak cukup. Insentif LP di tahap awal, pembagian lebih besar (fee share), dan kedalaman penambangan (mining) dengan batas waktu—menentukan apakah setelah mainnet benar-benar ada likuiditas atau sekadar cerita selesai lalu uang ditarik
Kembali ke pertanyaan awal: apakah perp multiaset bisa menjadi kategori independen
Kebutuhannya nyata. Orang yang melakukan trading makro secara alami perlu melihat banyak pasar sekaligus; satu terminal yang mengelola semua posisi akan meningkatkan efisiensi—itu memang ada nilainya
Tapi apakah settlement (likuidasi) dan LP bisa mengendalikan volatilitas berbeda secara bersamaan, itulah garis penentu hidup-mati. Sebelum mainnet benar-benar berjalan di live trading, penyesuaian ini belum dilakukan dengan baik—risikonya jauh lebih besar daripada efisiensi yang terlihat di permukaan
Sebaliknya, jika berhasil dijalankan, itu tidak hanya mendefinisikan Hertzflow, melainkan juga standar untuk seluruh kategori
https://testnet.hertzflow.xyz
@Hertzflow_xyz