Saat saya membongkar alur penyelesaian TBV milik @BabylonLabs_io , kesan paling langsung saya adalah: penyelesai tidak menghasilkan uang dari “arbitrase tingkat detik”, melainkan dari menanggung risiko selama satu periode waktu.
Misalkan BTC jatuh ke harga likuidasi, liquidator terlebih dulu menggelontorkan USDC untuk melunasi utang peminjam. Alur kontrak dan tanda tangan mungkin sangat cepat. Namun masalahnya ada di bagian selanjutnya—dokumen menyebut claim delay dan challenge period, yang berarti liquidator tidak langsung menerima aset jaminan BTC, melainkan harus menunggu hingga jendela berakhir. Uang sudah dikeluarkan, BTC belum juga didapat; selama itu harga bergerak seperti apa—risiko pada dasarnya ditanggung oleh liquidator.$BTC
Ini sangat berbeda dengan logika likuidasi DeFi tradisional. Banyak protokol pinjam-meminjam bisa selesai dalam satu langkah: melunasi utang, mengambil jaminan, lalu menikmati diskon. Jendela risiko relatif sangat singkat. TBV, karena harus mempertahankan mekanisme tantangan BitVM3, memecah proses menjadi dua tahap: bayar dulu, lalu klaim. Batas keamanan lebih kuat, tetapi pembukuan ekonomi liquidator juga menjadi lebih kompleks.$BABY
Jadi, tidak bisa hanya melihat BitVM3 untuk menilai bahwa biaya sengketa ditekan set rendah mungkin. Sengketa on-chain memang murah, tetapi bukan berarti likuidasi juga murah. Yang benar-benar diperhatikan liquidator adalah penggunaan dana, volatilitas BTC, Gas, opportunity cost, serta apakah masa tunggu ini mendapat kompensasi yang memadai.#baby
Jika kompensasinya tidak cukup, liquidator mungkin meminta diskon yang lebih tinggi; diskon terlalu tinggi membuat peminjam makin tertekan. Jika diskon terlalu rendah, bisa jadi tidak ada yang mau melakukan likuidasi, dan risiko bad debt akan menumpuk di dalam sistem.
Desain likuidasi Babylon TBV bukan untuk meniru pengalaman “tingkat detik” seperti Aave, melainkan menukar model keamanan yang lebih kuat dengan ambang partisipasi yang lebih berat. Hanya pihak yang bersedia menghadapi masa tunggu dan volatilitas harga yang mau menjadi liquidator ini.$ETH
Misalkan BTC jatuh ke harga likuidasi, liquidator terlebih dulu menggelontorkan USDC untuk melunasi utang peminjam. Alur kontrak dan tanda tangan mungkin sangat cepat. Namun masalahnya ada di bagian selanjutnya—dokumen menyebut claim delay dan challenge period, yang berarti liquidator tidak langsung menerima aset jaminan BTC, melainkan harus menunggu hingga jendela berakhir. Uang sudah dikeluarkan, BTC belum juga didapat; selama itu harga bergerak seperti apa—risiko pada dasarnya ditanggung oleh liquidator.$BTC
Ini sangat berbeda dengan logika likuidasi DeFi tradisional. Banyak protokol pinjam-meminjam bisa selesai dalam satu langkah: melunasi utang, mengambil jaminan, lalu menikmati diskon. Jendela risiko relatif sangat singkat. TBV, karena harus mempertahankan mekanisme tantangan BitVM3, memecah proses menjadi dua tahap: bayar dulu, lalu klaim. Batas keamanan lebih kuat, tetapi pembukuan ekonomi liquidator juga menjadi lebih kompleks.$BABY
Jadi, tidak bisa hanya melihat BitVM3 untuk menilai bahwa biaya sengketa ditekan set rendah mungkin. Sengketa on-chain memang murah, tetapi bukan berarti likuidasi juga murah. Yang benar-benar diperhatikan liquidator adalah penggunaan dana, volatilitas BTC, Gas, opportunity cost, serta apakah masa tunggu ini mendapat kompensasi yang memadai.#baby
Jika kompensasinya tidak cukup, liquidator mungkin meminta diskon yang lebih tinggi; diskon terlalu tinggi membuat peminjam makin tertekan. Jika diskon terlalu rendah, bisa jadi tidak ada yang mau melakukan likuidasi, dan risiko bad debt akan menumpuk di dalam sistem.
Desain likuidasi Babylon TBV bukan untuk meniru pengalaman “tingkat detik” seperti Aave, melainkan menukar model keamanan yang lebih kuat dengan ambang partisipasi yang lebih berat. Hanya pihak yang bersedia menghadapi masa tunggu dan volatilitas harga yang mau menjadi liquidator ini.$ETH