Hari ini saya menelusuri kisaran bug bounty yang baru diperbarui Babylon pada 27 Juli, dan setelah membacanya justru saya jadi semakin tidak tenang.
Hadiah maksimum 500 ribu dolar, 16 aset dimasukkan dalam cakupan—dari permukaannya terlihat investasi keamanan tidak rendah. Namun, setelah ditelusuri lebih jauh, beberapa jenis risiko yang benar-benar dapat menyeret sistem ke insiden besar justru secara tegas dikecualikan: risiko terpusat, relay sementara berhenti di antara Bitcoin dan Babylon, lebih dari sepertiga Finality Provider yang berniat jahat, Dewan Covenant mencapai mayoritas jahat atau tidak dapat mengumpulkan tanda tangan yang cukup, serta pengaturan parameter kedalaman konfirmasi yang terlalu rendah.
Yang patut diperhatikan juga, aturan bug bounty melarang pengujian terhadap oracle dan kontrak pintar pihak ketiga.
Ini jelas bertentangan dengan arah yang baru-baru ini didorong oleh @BabylonLabs_io . Babylon sudah mengumumkan akan mengintegrasikan Trustless Bitcoin Vaults ke Aave V4 dan Aegis, dengan rencana meluncurkan pinjaman dengan suku bunga tetap berbasis jaminan native BTC pada kuartal keempat.
Rangkaian produknya akan menjadi: Babylon mengelola infrastruktur jaminan BTC, Aave mengelola pasar pinjaman, Aegis mengelola produk suku bunga tetap—dan di luar itu, kemungkinan masih perlu ditambah wallet, front-end, oracle, serta mekanisme kliring.
Yang dilihat pengguna adalah “native BTC, self-custody, tanpa perlu bridging”. Tapi yang dilihat penyerang adalah celah tanggung jawab di antara banyak sistem.
Isu keamanan Babylon yang diungkap OpenZeppelin tahun ini justru terpusat pada jenis celah seperti ini: jaminan yang kedaluwarsa tetap memiliki hak suara, Finality Provider mem-bypass penahanan, pencatatan Co-Staking yang abnormal menyebabkan dana membeku, bahkan memicu kerusakan pada validator. Pemerintah/otoritas memang memperbaikinya secara cepat, tetapi itu justru semakin menunjukkan bahwa masalah batas bukanlah risiko teoretis.
Saya mempertanyakan bukan apakah Babylon diaudit, melainkan ketika bisnis terus menumpuk komponen pihak ketiga, siapa yang bertanggung jawab atas insiden “antar-komponen” itu?
Keamanan tidak bisa hanya dilihat apakah ada celah pada satu repositori. Saat benar-benar terjadi masalah, sering kali setiap pihak bisa membuktikan bahwa kode mereka tidak bermasalah, namun pada akhirnya tidak ada yang benar-benar bisa menjamin bahwa uang pengguna aman.
#baby $BABY @BabylonLabs_io
Hadiah maksimum 500 ribu dolar, 16 aset dimasukkan dalam cakupan—dari permukaannya terlihat investasi keamanan tidak rendah. Namun, setelah ditelusuri lebih jauh, beberapa jenis risiko yang benar-benar dapat menyeret sistem ke insiden besar justru secara tegas dikecualikan: risiko terpusat, relay sementara berhenti di antara Bitcoin dan Babylon, lebih dari sepertiga Finality Provider yang berniat jahat, Dewan Covenant mencapai mayoritas jahat atau tidak dapat mengumpulkan tanda tangan yang cukup, serta pengaturan parameter kedalaman konfirmasi yang terlalu rendah.
Yang patut diperhatikan juga, aturan bug bounty melarang pengujian terhadap oracle dan kontrak pintar pihak ketiga.
Ini jelas bertentangan dengan arah yang baru-baru ini didorong oleh @BabylonLabs_io . Babylon sudah mengumumkan akan mengintegrasikan Trustless Bitcoin Vaults ke Aave V4 dan Aegis, dengan rencana meluncurkan pinjaman dengan suku bunga tetap berbasis jaminan native BTC pada kuartal keempat.
Rangkaian produknya akan menjadi: Babylon mengelola infrastruktur jaminan BTC, Aave mengelola pasar pinjaman, Aegis mengelola produk suku bunga tetap—dan di luar itu, kemungkinan masih perlu ditambah wallet, front-end, oracle, serta mekanisme kliring.
Yang dilihat pengguna adalah “native BTC, self-custody, tanpa perlu bridging”. Tapi yang dilihat penyerang adalah celah tanggung jawab di antara banyak sistem.
Isu keamanan Babylon yang diungkap OpenZeppelin tahun ini justru terpusat pada jenis celah seperti ini: jaminan yang kedaluwarsa tetap memiliki hak suara, Finality Provider mem-bypass penahanan, pencatatan Co-Staking yang abnormal menyebabkan dana membeku, bahkan memicu kerusakan pada validator. Pemerintah/otoritas memang memperbaikinya secara cepat, tetapi itu justru semakin menunjukkan bahwa masalah batas bukanlah risiko teoretis.
Saya mempertanyakan bukan apakah Babylon diaudit, melainkan ketika bisnis terus menumpuk komponen pihak ketiga, siapa yang bertanggung jawab atas insiden “antar-komponen” itu?
Keamanan tidak bisa hanya dilihat apakah ada celah pada satu repositori. Saat benar-benar terjadi masalah, sering kali setiap pihak bisa membuktikan bahwa kode mereka tidak bermasalah, namun pada akhirnya tidak ada yang benar-benar bisa menjamin bahwa uang pengguna aman.
#baby $BABY @BabylonLabs_io