Saya mencoba mengunci satu detail spesifik dari desain Trustless Bitcoin Vaults, dan justru mendapatkan dua jawaban berbeda dari dua tulisan berbeda pada Temp Check yang sama. Satu akun mendeskripsikan langkah pasca-liquidation sebagai terbuka bagi likuidator permissionless, yang dapat menukar sebuah vault yang disita menjadi WBTC dengan premi kecil untuk menyelesaikan utang peminjam. Akun lain untuk proposal identik tersebut mendeskripsikannya sebagai kumpulan arbitrageur yang permissioned membeli vault escrow itu. Mekanismenya sama, berkas bertanggal 25 Mei yang sama, tapi dua kata berbeda untuk siapa yang boleh ikut berpartisipasi.
Ini penting karena permissionless dan permissioned bukan sinonim gaya dalam DeFi; keduanya menjelaskan siapa yang perlu mendapat persetujuan untuk memperoleh bagian spread likuidasi. Jika permissionless, siapa pun yang memiliki modal bisa bersaing untuk melakukan likuidasi—lebih dekat dengan cara Aave berjalan saat ini. Jika permissioned, ada kelompok yang masuk allowlist yang berada di antara vault yang gagal bayar dan penyelesaiannya, yang justru menghidupkan kembali jenis gatekeeper yang ingin dihindari oleh seluruh pitch.
Saya cenderung mengarah pada permissionless sebagai desain yang dimaksud, karena materi Babylon sendiri menggambarkan lapisan vault sebagai penghapus signer consortium dan kontrol diskresioner di mana pun di sistem lainnya. Tetapi niat tidak sama dengan spesifikasi yang dipublikasikan, dan rancangan oracle beserta asumsi kepercayaan penuh secara eksplisit didorong ke tahap ARFC berikutnya, bukan diselesaikan sekarang.
Jadi yang mana: seberapa “trustless” sistem ini bisa saya sebutkan, jika pelaporan di luar yang merujuk pada dokumen tata kelolanya saja tidak dapat sepakat tentang siapa yang diizinkan menyentuh langkah terakhirnya?
Desain likuidasi Babylon kemungkinan permissionless secara semangat, tetapi belum sepenuhnya tidak ambigu dalam catatan publik, dan celah antara niat dan dokumentasi inilah yang layak dipantau sebelum tahap ARFC menguncinya secara permanen.
@BabylonLabs_io $BABY #baby $BANK
Ini penting karena permissionless dan permissioned bukan sinonim gaya dalam DeFi; keduanya menjelaskan siapa yang perlu mendapat persetujuan untuk memperoleh bagian spread likuidasi. Jika permissionless, siapa pun yang memiliki modal bisa bersaing untuk melakukan likuidasi—lebih dekat dengan cara Aave berjalan saat ini. Jika permissioned, ada kelompok yang masuk allowlist yang berada di antara vault yang gagal bayar dan penyelesaiannya, yang justru menghidupkan kembali jenis gatekeeper yang ingin dihindari oleh seluruh pitch.
Saya cenderung mengarah pada permissionless sebagai desain yang dimaksud, karena materi Babylon sendiri menggambarkan lapisan vault sebagai penghapus signer consortium dan kontrol diskresioner di mana pun di sistem lainnya. Tetapi niat tidak sama dengan spesifikasi yang dipublikasikan, dan rancangan oracle beserta asumsi kepercayaan penuh secara eksplisit didorong ke tahap ARFC berikutnya, bukan diselesaikan sekarang.
Jadi yang mana: seberapa “trustless” sistem ini bisa saya sebutkan, jika pelaporan di luar yang merujuk pada dokumen tata kelolanya saja tidak dapat sepakat tentang siapa yang diizinkan menyentuh langkah terakhirnya?
Desain likuidasi Babylon kemungkinan permissionless secara semangat, tetapi belum sepenuhnya tidak ambigu dalam catatan publik, dan celah antara niat dan dokumentasi inilah yang layak dipantau sebelum tahap ARFC menguncinya secara permanen.
@BabylonLabs_io $BABY #baby $BANK