Robot kliring tidak punya gunting—ia hanya memindahkan satu kardus penuh. Setelah melihat @BabylonLabs_io pada testnet saat ini yang mendesain setiap Vault menjadi UTXO yang independen, saya baru paham: dual-Vault bukan opsi simpanan yang sekadar terlihat bagus, melainkan cara untuk memotong kerugian kliring menjadi butiran.
Jaminan di DeFi biasa bisa dipotong proporsional, tetapi transaksi Bitcoin hanya bisa membelanjakan satu output secara utuh. Misalkan posisi berisi 0,4 BTC, maka kliring hanya perlu menangani sekitar 0,25 BTC saja. Namun jika seluruh 0,4 BTC dipaketkan ke dalam satu Vault, protokol juga tidak bisa memotong 0,25 BTC; ia hanya bisa memasukkan seluruh Vault tersebut ke dalam kliring. Nilai yang “lebih” tidak lenyap begitu saja: mekanisme fairness akan lebih dulu mengurangi utang tersisa pengguna, dan jika masih ada sisa barulah mengembalikan dengan WBTC. Tapi “mendapat kompensasi senilai” dan “BTC asli tetap tersimpan di vault milik sendiri” jelas bukan hal yang sama.
Di sinilah dual-Vault benar-benar berguna. Berdasarkan parameter testnet publik saat ini, faktor jaminan 78%, target health factor 1,24. Perkiraan dokumen saat posisi baru saja memicu kliring, porsi yang ditargetkan untuk diambil sekitar 62% dari nilai BTC. Portal akan menempatkan Vault dengan pengorbanan yang lebih besar lebih dulu berdasarkan parameter real-time; BTC yang tersisa dimasukkan ke dalam proteksi Vault. Prosedur kliring memeriksa dari bagian teratas daftar, satu per satu: begitu Vault pertama sudah cukup, proses berhenti; Vault kedua tetap dibiarkan berada dalam posisi.
Jadi ini bukan “alat anti-kliring” yang benar-benar mencegah kerugian—lebih seperti pintu sekat di ruang kapal: saat terjadi insiden, tetap ada kerugian, hanya saja diupayakan agar kerugian itu tidak menelan seluruh kapal. Bila penurunan harga terlalu cepat, ukuran Vault pengorbanan tidak cukup, atau urutan penempatan salah, sistem masih mungkin melanjutkan mengambil Vault berikutnya. Angka 62/38 juga bukan rumus permanen; setelah parameter berubah, Anda harus meninjau ulang pembagian yang diberikan Portal.
Saya lebih suka menyebut rancangan ini sebagai manajemen butiran kerugian. Yang benar-benar perlu diawasi peminjam, selain health factor, adalah ukuran Vault mereka sendiri dan urutan penempatannya. Apakah Anda bersedia menerima pengelolaan posisi yang lebih kompleks demi mempertahankan Vault BTC asli kedua?
#baby $BABY
Jaminan di DeFi biasa bisa dipotong proporsional, tetapi transaksi Bitcoin hanya bisa membelanjakan satu output secara utuh. Misalkan posisi berisi 0,4 BTC, maka kliring hanya perlu menangani sekitar 0,25 BTC saja. Namun jika seluruh 0,4 BTC dipaketkan ke dalam satu Vault, protokol juga tidak bisa memotong 0,25 BTC; ia hanya bisa memasukkan seluruh Vault tersebut ke dalam kliring. Nilai yang “lebih” tidak lenyap begitu saja: mekanisme fairness akan lebih dulu mengurangi utang tersisa pengguna, dan jika masih ada sisa barulah mengembalikan dengan WBTC. Tapi “mendapat kompensasi senilai” dan “BTC asli tetap tersimpan di vault milik sendiri” jelas bukan hal yang sama.
Di sinilah dual-Vault benar-benar berguna. Berdasarkan parameter testnet publik saat ini, faktor jaminan 78%, target health factor 1,24. Perkiraan dokumen saat posisi baru saja memicu kliring, porsi yang ditargetkan untuk diambil sekitar 62% dari nilai BTC. Portal akan menempatkan Vault dengan pengorbanan yang lebih besar lebih dulu berdasarkan parameter real-time; BTC yang tersisa dimasukkan ke dalam proteksi Vault. Prosedur kliring memeriksa dari bagian teratas daftar, satu per satu: begitu Vault pertama sudah cukup, proses berhenti; Vault kedua tetap dibiarkan berada dalam posisi.
Jadi ini bukan “alat anti-kliring” yang benar-benar mencegah kerugian—lebih seperti pintu sekat di ruang kapal: saat terjadi insiden, tetap ada kerugian, hanya saja diupayakan agar kerugian itu tidak menelan seluruh kapal. Bila penurunan harga terlalu cepat, ukuran Vault pengorbanan tidak cukup, atau urutan penempatan salah, sistem masih mungkin melanjutkan mengambil Vault berikutnya. Angka 62/38 juga bukan rumus permanen; setelah parameter berubah, Anda harus meninjau ulang pembagian yang diberikan Portal.
Saya lebih suka menyebut rancangan ini sebagai manajemen butiran kerugian. Yang benar-benar perlu diawasi peminjam, selain health factor, adalah ukuran Vault mereka sendiri dan urutan penempatannya. Apakah Anda bersedia menerima pengelolaan posisi yang lebih kompleks demi mempertahankan Vault BTC asli kedua?
#baby $BABY
