Saya mengambil @BabylonLabs_io kerangka risiko SCRIPT yang dirilis sendiri, lalu membandingkannya dengan parameter testnet TBV. Yang paling menarik adalah di satu sisi tertulis “siklus hidup agunan harus tanpa izin”, sementara di sisi lain justru tercantum ambang darurat Security Council 3/5.
Ini belum tentu kontradiktif, tetapi tepat menjadi celah untuk menguji seberapa “trustless” sistem ini.
SCRIPT menuntut enam hal: pengguna mempertahankan kedaulatan, aturan likuidasi jelas, tidak boleh dijadikan jaminan ulang tanpa persetujuan, setiap posisi dipisahkan, pihak ketiga tidak bisa mengaudit, dan status agunan transparan. Ibarat memberi daftar enam kriteria pemeriksaan sebuah brankas: kuncinya milik siapa, syarat membukanya apa, boleh tidak dipakai untuk jaminan kedua, apakah isinya tercampur, siapa yang bisa menghalangi Anda, dan apakah orang luar bisa mengecek saldo.
TBV punya pendekatan yang cukup jelas pada pemisahan dan transparansi: BTC tiap pengguna disimpan di Bitcoin Vault yang terpisah, aplikasi eksternal memverifikasi status, dan tidak semua koin digabung ke dalam satu pool kustodian. Namun parameter testnet publik saat ini juga menyebut bahwa Security Council terdiri dari 5 kursi, dan 3 tanda tangan dapat menjalankan intervensi darurat seperti CouncilNoPayout.
Di sini perlu ditegaskan batasnya: 3/5 adalah parameter testnet publik, dan tidak bisa langsung disimpulkan bahwa mainnet ke depannya juga akan sama. Justru karena jawaban untuk mainnet belum bisa dipastikan dari halaman parameter ini, perubahan atau keberlangsungan komite dan hak aksesnya harus diperlakukan sebagai poin pengamatan jangka panjang, bukan dijadikan kesimpulan bagi proyek.
Menurut saya, rem darurat memang punya nilai praktis selama fase test. Sistem baru melibatkan script Bitcoin, koordinasi off-chain, dan kontrak Ethereum; saat ditemukan kegagalan serius, sama sekali tidak punya tombol penghenti kerugian belum tentu lebih aman daripada punya tombol itu. Masalahnya, setelah tombol ada, kita harus terus bertanya: siapa anggotanya, dalam kondisi apa tombol itu boleh ditekan, apakah aksinya diumumkan dengan jeda, dan apakah pengguna punya jalur keluar yang tidak bergantung pada komite.
Inilah juga hal yang seharusnya benar-benar diawasi oleh $BABY dalam tata kelola. Bukan sekadar melihat kata “tata kelola komunitas” lalu menganggap kekuasaan sudah tersebar, tetapi melihat hak darurat apa saja yang akan dipertahankan di mainnet nanti, siapa yang bisa mengubah ambang batas, dan apakah setiap tindakan dapat ditelusuri on-chain. Para pemegang #baby tidak membeli visi abstrak, melainkan batas kewenangan yang konkret.
Sikap saya: komite darurat bisa menjadi pagar pengaman selama masa konstruksi, tetapi tidak boleh selamanya lolos pemeriksaan hanya dengan alasan “demi keamanan”. Periksa sendiri dulu. Apakah Anda bersedia menerima rem 3/5 sebagai imbalan atas respons terhadap kegagalan, atau menurut Anda sistem tanpa izin memang tidak seharusnya menyisakan saklar utama seperti itu? Mari dibahas di kolom komentar.
Ini belum tentu kontradiktif, tetapi tepat menjadi celah untuk menguji seberapa “trustless” sistem ini.
SCRIPT menuntut enam hal: pengguna mempertahankan kedaulatan, aturan likuidasi jelas, tidak boleh dijadikan jaminan ulang tanpa persetujuan, setiap posisi dipisahkan, pihak ketiga tidak bisa mengaudit, dan status agunan transparan. Ibarat memberi daftar enam kriteria pemeriksaan sebuah brankas: kuncinya milik siapa, syarat membukanya apa, boleh tidak dipakai untuk jaminan kedua, apakah isinya tercampur, siapa yang bisa menghalangi Anda, dan apakah orang luar bisa mengecek saldo.
TBV punya pendekatan yang cukup jelas pada pemisahan dan transparansi: BTC tiap pengguna disimpan di Bitcoin Vault yang terpisah, aplikasi eksternal memverifikasi status, dan tidak semua koin digabung ke dalam satu pool kustodian. Namun parameter testnet publik saat ini juga menyebut bahwa Security Council terdiri dari 5 kursi, dan 3 tanda tangan dapat menjalankan intervensi darurat seperti CouncilNoPayout.
Di sini perlu ditegaskan batasnya: 3/5 adalah parameter testnet publik, dan tidak bisa langsung disimpulkan bahwa mainnet ke depannya juga akan sama. Justru karena jawaban untuk mainnet belum bisa dipastikan dari halaman parameter ini, perubahan atau keberlangsungan komite dan hak aksesnya harus diperlakukan sebagai poin pengamatan jangka panjang, bukan dijadikan kesimpulan bagi proyek.
Menurut saya, rem darurat memang punya nilai praktis selama fase test. Sistem baru melibatkan script Bitcoin, koordinasi off-chain, dan kontrak Ethereum; saat ditemukan kegagalan serius, sama sekali tidak punya tombol penghenti kerugian belum tentu lebih aman daripada punya tombol itu. Masalahnya, setelah tombol ada, kita harus terus bertanya: siapa anggotanya, dalam kondisi apa tombol itu boleh ditekan, apakah aksinya diumumkan dengan jeda, dan apakah pengguna punya jalur keluar yang tidak bergantung pada komite.
Inilah juga hal yang seharusnya benar-benar diawasi oleh $BABY dalam tata kelola. Bukan sekadar melihat kata “tata kelola komunitas” lalu menganggap kekuasaan sudah tersebar, tetapi melihat hak darurat apa saja yang akan dipertahankan di mainnet nanti, siapa yang bisa mengubah ambang batas, dan apakah setiap tindakan dapat ditelusuri on-chain. Para pemegang #baby tidak membeli visi abstrak, melainkan batas kewenangan yang konkret.
Sikap saya: komite darurat bisa menjadi pagar pengaman selama masa konstruksi, tetapi tidak boleh selamanya lolos pemeriksaan hanya dengan alasan “demi keamanan”. Periksa sendiri dulu. Apakah Anda bersedia menerima rem 3/5 sebagai imbalan atas respons terhadap kegagalan, atau menurut Anda sistem tanpa izin memang tidak seharusnya menyisakan saklar utama seperti itu? Mari dibahas di kolom komentar.
