Hieu_30
1.6k Posting
Hieu_30
112 Mengikuti
193 Pengikut
1.1K+ Disukai
Posting
PINNED
False "Sudah Dirilis" Klaim, Dia Mengatakan Bahwa Dia Sudah Merilisnya
Seorang penjual pernah memberi tahu saya, di tengah-tengah pesanan, bahwa dia sudah merilis kripto dan keterlambatan itu pasti ada di sisi saya—mungkin dompet saya lambat, mungkin saya sebaiknya membatalkan pesanan dan nanti kita bereskan lewat chat. Selama sekitar satu menit, saya benar-benar mempertimbangkannya. Dompet memang kadang bisa tertinggal. Nada suaranya terdengar lebih kesal daripada tidak jujur, dan entah bagaimana itu membuatnya terasa lebih meyakinkan.
Lalu saya ingat satu hal yang tidak pernah tertinggal: status pesanan. Binance P2P tidak meminta saya percaya begitu saja pada ucapan seseorang tentang rilis—mereka menampilkan statusnya. Klaim adalah sesuatu yang dikatakan seseorang. Status adalah sesuatu yang ditampilkan platform.
Saya masih tidak suka rasa gesekan karena harus meminta bukti ketika seseorang terdengar tulus. Rasanya hampir tidak sopan mengatakan "Saya akan cek status pesanan, bukan pesan Anda" kepada orang yang mungkin benar-benar sedang kesal. Tapi membatalkan berdasarkan ucapan penjual menghilangkan satu-satunya keuntungan saya: begitu pesanan dibatalkan, escrow dilepaskan, dan apa pun klaim yang dia sampaikan ikut hilang bersamanya. Tidak ada cara untuk menyelesaikannya nanti.
Jadi saya tidak membatalkan. Saya cek status pesanan sendiri, melihat tidak ada yang bergerak, lalu membuka Banding alih-alih percakapan pribadi. Dukungan bisa melihat pesanan yang sama seperti yang bisa saya lihat—itulah tujuan menjaga pesanan tetap ada.
Kalau kriptonya memang sudah dirilis tapi hanya terlambat, Banding hanya memakan waktu beberapa menit. Kalau tidak, membatalkan akan menelan semuanya.
#binancep2pantoan @Binance Vietnam $TUT $MMT $BLUAI
Seorang penjual pernah memberi tahu saya, di tengah-tengah pesanan, bahwa dia sudah merilis kripto dan keterlambatan itu pasti ada di sisi saya—mungkin dompet saya lambat, mungkin saya sebaiknya membatalkan pesanan dan nanti kita bereskan lewat chat. Selama sekitar satu menit, saya benar-benar mempertimbangkannya. Dompet memang kadang bisa tertinggal. Nada suaranya terdengar lebih kesal daripada tidak jujur, dan entah bagaimana itu membuatnya terasa lebih meyakinkan.
Lalu saya ingat satu hal yang tidak pernah tertinggal: status pesanan. Binance P2P tidak meminta saya percaya begitu saja pada ucapan seseorang tentang rilis—mereka menampilkan statusnya. Klaim adalah sesuatu yang dikatakan seseorang. Status adalah sesuatu yang ditampilkan platform.
Saya masih tidak suka rasa gesekan karena harus meminta bukti ketika seseorang terdengar tulus. Rasanya hampir tidak sopan mengatakan "Saya akan cek status pesanan, bukan pesan Anda" kepada orang yang mungkin benar-benar sedang kesal. Tapi membatalkan berdasarkan ucapan penjual menghilangkan satu-satunya keuntungan saya: begitu pesanan dibatalkan, escrow dilepaskan, dan apa pun klaim yang dia sampaikan ikut hilang bersamanya. Tidak ada cara untuk menyelesaikannya nanti.
Jadi saya tidak membatalkan. Saya cek status pesanan sendiri, melihat tidak ada yang bergerak, lalu membuka Banding alih-alih percakapan pribadi. Dukungan bisa melihat pesanan yang sama seperti yang bisa saya lihat—itulah tujuan menjaga pesanan tetap ada.
Kalau kriptonya memang sudah dirilis tapi hanya terlambat, Banding hanya memakan waktu beberapa menit. Kalau tidak, membatalkan akan menelan semuanya.
#binancep2pantoan @Binance Vietnam $TUT $MMT $BLUAI
PINNED
Anda Menggulir Melewati 12 Penawaran Hampir Serupa
Harga sama, metode pembayaran sama, lencana "online" yang sama—buku pesanan P2P bisa membuat setiap penawaran terlihat saling bertukar, jadi kebanyakan orang cukup mengetuk yang pertama. Ini kebiasaan yang hampir semua orang lakukan, terutama saat menunggu terasa seperti kehilangan.
Tapi dua trader yang memasang tarif yang sama bisa jadi benar-benar berbeda sebagai pihak lawan. Yang memisahkan keduanya hanya butuh sekitar 30 detik untuk diperiksa, dan itu sudah ada tepat di profil.
Tingkat penyelesaian lebih penting daripada jumlah transaksi. Seseorang dengan 40 pesanan yang selesai dan tingkat penyelesaian 99% punya rekam jejak; seseorang yang masih baru tidak otomatis tidak aman, tapi itu berarti pemeriksaan lainnya jadi lebih berpengaruh—seberapa lama mereka aktif, apakah riwayat mereka cocok dengan lencana yang mereka tampilkan.
Ada juga detail yang paling cepat dilewatkan orang: nama pada akun pembayaran harus sama dengan nama pada pesanan, bukan sekadar terlihat mirip. Perbedaan yang hampir sama, atau permintaan untuk "kirim ke akun rekan kerja saya," patut dihentikan sejenak sebelum apa pun terjadi.
Semua ini tidak menggantikan Escrow—kriptonya tetap terkunci sampai dirilis, apa pun hasilnya. Tapi memverifikasi orang di sisi lain berarti Anda menemukan masalah sebelum ada yang perlu ditangani, bukan mengandalkan Escrow untuk membersihkannya setelahnya.
Jika sebuah profil terasa janggal dan Anda tidak tahu alasannya, itu sudah cukup untuk memilih penawaran lain atau menghubungi Dukungan Binance terlebih dahulu.
#binancep2pantoan @Binance Vietnam $BNB #creatorpad
Harga sama, metode pembayaran sama, lencana "online" yang sama—buku pesanan P2P bisa membuat setiap penawaran terlihat saling bertukar, jadi kebanyakan orang cukup mengetuk yang pertama. Ini kebiasaan yang hampir semua orang lakukan, terutama saat menunggu terasa seperti kehilangan.
Tapi dua trader yang memasang tarif yang sama bisa jadi benar-benar berbeda sebagai pihak lawan. Yang memisahkan keduanya hanya butuh sekitar 30 detik untuk diperiksa, dan itu sudah ada tepat di profil.
Tingkat penyelesaian lebih penting daripada jumlah transaksi. Seseorang dengan 40 pesanan yang selesai dan tingkat penyelesaian 99% punya rekam jejak; seseorang yang masih baru tidak otomatis tidak aman, tapi itu berarti pemeriksaan lainnya jadi lebih berpengaruh—seberapa lama mereka aktif, apakah riwayat mereka cocok dengan lencana yang mereka tampilkan.
Ada juga detail yang paling cepat dilewatkan orang: nama pada akun pembayaran harus sama dengan nama pada pesanan, bukan sekadar terlihat mirip. Perbedaan yang hampir sama, atau permintaan untuk "kirim ke akun rekan kerja saya," patut dihentikan sejenak sebelum apa pun terjadi.
Semua ini tidak menggantikan Escrow—kriptonya tetap terkunci sampai dirilis, apa pun hasilnya. Tapi memverifikasi orang di sisi lain berarti Anda menemukan masalah sebelum ada yang perlu ditangani, bukan mengandalkan Escrow untuk membersihkannya setelahnya.
Jika sebuah profil terasa janggal dan Anda tidak tahu alasannya, itu sudah cukup untuk memilih penawaran lain atau menghubungi Dukungan Binance terlebih dahulu.
#binancep2pantoan @Binance Vietnam $BNB #creatorpad
Kenapa Anda Tidak Pernah Harus Mengalah untuk Trading di Luar Platform
Pola umum di P2P: salah satu pihak mengusulkan pindah ke Telegram "agar lebih cepat selesai." Kedengarannya tidak berbahaya, tetapi satu langkah itu menghilangkan semua perlindungan yang dibangun ke dalam pesanan Binance.
Escrow hanya mengunci kripto yang terkait dengan pesanan yang dibuat dan diselesaikan di dalam Binance. Jika ketentuan sebenarnya diselesaikan di tempat lain, jumlah yang berbeda, dompet yang berbeda, akun pembayaran pihak lain, Escrow tidak lagi mencakup apa yang benar-benar terjadi, karena tidak ada pesanan Binance yang cocok.
Obrolan pesanan juga bekerja dengan cara yang sama. Setiap pesan di dalam pesanan Binance P2P diberi stempel waktu dan disimpan, dan itulah yang persis ditinjau oleh Support selama Proses Banding. Percakapan di Telegram atau WhatsApp sama sekali tidak terlihat oleh Support. Jadi, sejelas apa pun tampilan tangkapan layar Anda, Support tidak bisa memverifikasi apakah itu autentik atau tidak diedit. Dalam sengketa, Anda akhirnya hanya memiliki klaim, bukan bukti.
Ini juga membuat Proses Banding menjadi tidak bisa digunakan. Banding menyelesaikan sengketa yang terkait dengan pesanan Binance tertentu; jika negosiasi sebenarnya terjadi di luar platform, tidak ada data pesanan yang sesuai dengan apa yang Anda sengketakan.
Aturan sederhana: jika pihak lawan ingin memindahkan komunikasi atau pembayaran di luar Binance, anggap itu sebagai alasan untuk memperlambat, bukan mempercepat. Pedagang yang sah tidak punya kebutuhan operasional untuk meninggalkan sistem yang melindungi kedua belah pihak secara setara.
Kenyamanan biasanya menjadi alasan, tetapi sering kali berarti penghapusan perlindungan untuk pihak lain. Menjaga agar transaksi sepenuhnya tetap di Binance tidak memerlukan biaya tambahan dan memastikan Escrow, log obrolan, serta Banding semuanya berfungsi sesuai desain.
#binancep2pantoan @Binance Vietnam #creatorpad $BNB
Pola umum di P2P: salah satu pihak mengusulkan pindah ke Telegram "agar lebih cepat selesai." Kedengarannya tidak berbahaya, tetapi satu langkah itu menghilangkan semua perlindungan yang dibangun ke dalam pesanan Binance.
Escrow hanya mengunci kripto yang terkait dengan pesanan yang dibuat dan diselesaikan di dalam Binance. Jika ketentuan sebenarnya diselesaikan di tempat lain, jumlah yang berbeda, dompet yang berbeda, akun pembayaran pihak lain, Escrow tidak lagi mencakup apa yang benar-benar terjadi, karena tidak ada pesanan Binance yang cocok.
Obrolan pesanan juga bekerja dengan cara yang sama. Setiap pesan di dalam pesanan Binance P2P diberi stempel waktu dan disimpan, dan itulah yang persis ditinjau oleh Support selama Proses Banding. Percakapan di Telegram atau WhatsApp sama sekali tidak terlihat oleh Support. Jadi, sejelas apa pun tampilan tangkapan layar Anda, Support tidak bisa memverifikasi apakah itu autentik atau tidak diedit. Dalam sengketa, Anda akhirnya hanya memiliki klaim, bukan bukti.
Ini juga membuat Proses Banding menjadi tidak bisa digunakan. Banding menyelesaikan sengketa yang terkait dengan pesanan Binance tertentu; jika negosiasi sebenarnya terjadi di luar platform, tidak ada data pesanan yang sesuai dengan apa yang Anda sengketakan.
Aturan sederhana: jika pihak lawan ingin memindahkan komunikasi atau pembayaran di luar Binance, anggap itu sebagai alasan untuk memperlambat, bukan mempercepat. Pedagang yang sah tidak punya kebutuhan operasional untuk meninggalkan sistem yang melindungi kedua belah pihak secara setara.
Kenyamanan biasanya menjadi alasan, tetapi sering kali berarti penghapusan perlindungan untuk pihak lain. Menjaga agar transaksi sepenuhnya tetap di Binance tidak memerlukan biaya tambahan dan memastikan Escrow, log obrolan, serta Banding semuanya berfungsi sesuai desain.
#binancep2pantoan @Binance Vietnam #creatorpad $BNB
Bagian paling berharga dari Babylon bukanlah peminjaman.
Yang terpenting adalah penantian.
Itu mungkin terdengar terbalik sampai Anda benar-benar mengikuti alur penebusan.
Saat Trustless Bitcoin Vault ditebus, Bitcoin tidak langsung melepas jaminannya. Bukti kriptografis harus dibuat, diverifikasi, lalu jendela penantangan (challenge) sekitar tiga hari memberi waktu bagi peserta untuk membantah klaim yang tidak valid sebelum ada BTC yang bergerak.
Awalnya saya mengira tiga hari itu akan terasa seperti hambatan yang tidak perlu.
Namun, itu justru benar-benar mengubah cara saya memandang sistem.
Keterlambatan itu bukan karena protokolnya lambat.
Tapi karena kepastian membutuhkan waktu.
Saat menyelami dokumentasi, saya juga melihat detail lain yang tidak terlalu mendapat perhatian. Jika suatu saat Vault Provider menjadi tidak tersedia, pihak penyetor tidak terkunci untuk menunggu selamanya. Jalur pemulihan self-claim sudah disiapkan sejak pembuatan vault, memungkinkan pemilik memulihkan BTC secara mandiri.
Filosofi itu terlihat di seluruh rancangan.
Fallback bukanlah tambalan darurat yang dipasang belakangan.
Itu memang bagian dari arsitektur sejak hari pertama.
Hari ini, Babylon sudah mengamankan lebih dari 56.000 BTC melalui Bitcoin Staking sambil memperluas model keamanan tersebut ke native Bitcoin-backed lending dengan Trustless Bitcoin Vaults dan Aave v4.
Setelah menghabiskan waktu dengan dokumentasi dan alur testnet, saya sampai pada satu kesimpulan yang sederhana.
Kebanyakan protokol berlomba untuk memindahkan aset secepat mungkin.
Babylon tampaknya lebih tertarik untuk memastikan aset hanya bergerak saat memang seharusnya.
Kecepatan membangun kenyamanan.
Kepastian membangun kepercayaan.
Untuk Bitcoin, saya pikir Babylon memilih yang tepat.
Karena itulah @BabylonLabs_io telah menjadi salah satu proyek infrastruktur yang benar-benar ingin saya terus pantau.
#baby $BABY
Yang terpenting adalah penantian.
Itu mungkin terdengar terbalik sampai Anda benar-benar mengikuti alur penebusan.
Saat Trustless Bitcoin Vault ditebus, Bitcoin tidak langsung melepas jaminannya. Bukti kriptografis harus dibuat, diverifikasi, lalu jendela penantangan (challenge) sekitar tiga hari memberi waktu bagi peserta untuk membantah klaim yang tidak valid sebelum ada BTC yang bergerak.
Awalnya saya mengira tiga hari itu akan terasa seperti hambatan yang tidak perlu.
Namun, itu justru benar-benar mengubah cara saya memandang sistem.
Keterlambatan itu bukan karena protokolnya lambat.
Tapi karena kepastian membutuhkan waktu.
Saat menyelami dokumentasi, saya juga melihat detail lain yang tidak terlalu mendapat perhatian. Jika suatu saat Vault Provider menjadi tidak tersedia, pihak penyetor tidak terkunci untuk menunggu selamanya. Jalur pemulihan self-claim sudah disiapkan sejak pembuatan vault, memungkinkan pemilik memulihkan BTC secara mandiri.
Filosofi itu terlihat di seluruh rancangan.
Fallback bukanlah tambalan darurat yang dipasang belakangan.
Itu memang bagian dari arsitektur sejak hari pertama.
Hari ini, Babylon sudah mengamankan lebih dari 56.000 BTC melalui Bitcoin Staking sambil memperluas model keamanan tersebut ke native Bitcoin-backed lending dengan Trustless Bitcoin Vaults dan Aave v4.
Setelah menghabiskan waktu dengan dokumentasi dan alur testnet, saya sampai pada satu kesimpulan yang sederhana.
Kebanyakan protokol berlomba untuk memindahkan aset secepat mungkin.
Babylon tampaknya lebih tertarik untuk memastikan aset hanya bergerak saat memang seharusnya.
Kecepatan membangun kenyamanan.
Kepastian membangun kepercayaan.
Untuk Bitcoin, saya pikir Babylon memilih yang tepat.
Karena itulah @BabylonLabs_io telah menjadi salah satu proyek infrastruktur yang benar-benar ingin saya terus pantau.
#baby $BABY
Desain paling aman tidak selalu yang terasa paling aman.
Pikiran itu menetap di benak saya saat membaca proses penebusan Babylon.
Kebanyakan orang fokus pada apa yang terjadi ketika BTC dikunci.
Saya justru menemukan hal yang lebih menarik pada bagian keluarnya.
Menebus sebuah brankas tidak instan. Bahkan setelah peristiwa penebusan yang valid dihasilkan di Ethereum, Bitcoin tidak langsung melepas BTC.
Jendela penantang memberi waktu bagi peserta lain untuk membantah klaim yang tidak valid sebelum dana berpindah.
Menunggu tiga hari terdengar tidak efisien jika yang Anda ukur hanya kecepatan.
Namun, keamanan jarang memberikan imbalan kepada ketidaksabaran.
Keuangan tradisional sering kali menyelesaikan proses dengan lambat karena institusi berdiri di antara setiap langkah.
Babylon memperlambat semuanya dengan alasan yang berbeda.
Penundaan ini tidak meminta pengguna untuk mempercayai perantara lain.
Penundaan ini memberi protokol waktu untuk membuktikan bahwa tidak ada penebusan yang tidak valid lolos.
Perbedaan itu terasa penting.
Dua sistem bisa memiliki waktu tunggu yang sama, sementara dibangun di atas asumsi yang sama sekali berbeda.
Satu sistem menunda karena orang perlu memberikan persetujuan.
Sistem lainnya menunda karena matematika perlu waktu untuk dapat ditantang.
Apakah pengguna mau menerima trade-off tersebut masih menjadi pertanyaan terbuka.
Kripto telah menghabiskan bertahun-tahun bersaing siapa yang bisa membuat semuanya terjadi lebih cepat.
Babylon diam-diam bertanya apakah beberapa hal seharusnya terjadi dengan lebih hati-hati.
#baby $BABY @BabylonLabs_io
Pikiran itu menetap di benak saya saat membaca proses penebusan Babylon.
Kebanyakan orang fokus pada apa yang terjadi ketika BTC dikunci.
Saya justru menemukan hal yang lebih menarik pada bagian keluarnya.
Menebus sebuah brankas tidak instan. Bahkan setelah peristiwa penebusan yang valid dihasilkan di Ethereum, Bitcoin tidak langsung melepas BTC.
Jendela penantang memberi waktu bagi peserta lain untuk membantah klaim yang tidak valid sebelum dana berpindah.
Menunggu tiga hari terdengar tidak efisien jika yang Anda ukur hanya kecepatan.
Namun, keamanan jarang memberikan imbalan kepada ketidaksabaran.
Keuangan tradisional sering kali menyelesaikan proses dengan lambat karena institusi berdiri di antara setiap langkah.
Babylon memperlambat semuanya dengan alasan yang berbeda.
Penundaan ini tidak meminta pengguna untuk mempercayai perantara lain.
Penundaan ini memberi protokol waktu untuk membuktikan bahwa tidak ada penebusan yang tidak valid lolos.
Perbedaan itu terasa penting.
Dua sistem bisa memiliki waktu tunggu yang sama, sementara dibangun di atas asumsi yang sama sekali berbeda.
Satu sistem menunda karena orang perlu memberikan persetujuan.
Sistem lainnya menunda karena matematika perlu waktu untuk dapat ditantang.
Apakah pengguna mau menerima trade-off tersebut masih menjadi pertanyaan terbuka.
Kripto telah menghabiskan bertahun-tahun bersaing siapa yang bisa membuat semuanya terjadi lebih cepat.
Babylon diam-diam bertanya apakah beberapa hal seharusnya terjadi dengan lebih hati-hati.
#baby $BABY @BabylonLabs_io
Terverifikasi
Terkubur dalam asumsi keamanan milik @BabylonLabs_io sendiri ada sebuah kalimat yang terdengar sangat berbeda begitu Anda duduk dengan itu: seluruh sistem checkpoint berbasis Bitcoin membutuhkan "setidaknya satu pengirim vigilante yang jujur" agar tetap online, dan itu dicantumkan sebagai asumsi, bukan sesuatu yang dipaksakan oleh protokol.
Setiap asumsi lain dalam daftar tersebut memerlukan mayoritas yang jujur—kedalaman konfirmasi Bitcoin, set validator milik Babylon, set validator dari chain-chain yang terhubung. Mayoritas itu sulit untuk dirusak karena Anda perlu membuat sebagian besar kerumunan jatuh pada saat yang sama. Asumsi pengirim berbeda jenisnya. Ia hanya perlu satu contoh yang jujur di mana saja, yang terdengar seperti ambang batas paling rendah untuk dilewati, dan dalam beberapa hal memang demikian. Tetapi itu juga berarti bahwa seluruh rangkaian keamanan berbasis Bitcoin—bagian yang membuat penulisan ulang sejarah menjadi tidak rasional secara ekonomi—berjalan melalui apakah bahkan satu salinan dari program daemon spesifik yang dijalankan itu sedang dioperasikan dengan jujur pada setiap saat.
Menjalankannya bersifat permissionless, siapa pun bisa melakukannya, tetapi tidak ada yang saya temukan yang menjelaskan adanya imbalan khusus untuk melakukannya selain alamat opsional untuk mengklaim insentif di masa depan yang belum aktif. Pengirim juga membayar biaya transaksi Bitcoin yang nyata dari kantong sendiri setiap kali ia mengirim.
Saya terus bolak-balik menilai apakah ambang satu pihak yang jujur itu tahan terhadap gangguan karena begitu mudah untuk dilewati, atau justru sebuah ketergantungan yang lebih sunyi daripada komite perjanjian (covenant) dulu, karena setidaknya kegagalan komite akan terlihat. Jika pengiriman checkpoint suatu saat berhenti diam-diam, apakah Anda bahkan akan menyadarinya sebelum hal itu memengaruhi taruhan Anda sendiri?
#baby $BABY
Setiap asumsi lain dalam daftar tersebut memerlukan mayoritas yang jujur—kedalaman konfirmasi Bitcoin, set validator milik Babylon, set validator dari chain-chain yang terhubung. Mayoritas itu sulit untuk dirusak karena Anda perlu membuat sebagian besar kerumunan jatuh pada saat yang sama. Asumsi pengirim berbeda jenisnya. Ia hanya perlu satu contoh yang jujur di mana saja, yang terdengar seperti ambang batas paling rendah untuk dilewati, dan dalam beberapa hal memang demikian. Tetapi itu juga berarti bahwa seluruh rangkaian keamanan berbasis Bitcoin—bagian yang membuat penulisan ulang sejarah menjadi tidak rasional secara ekonomi—berjalan melalui apakah bahkan satu salinan dari program daemon spesifik yang dijalankan itu sedang dioperasikan dengan jujur pada setiap saat.
Menjalankannya bersifat permissionless, siapa pun bisa melakukannya, tetapi tidak ada yang saya temukan yang menjelaskan adanya imbalan khusus untuk melakukannya selain alamat opsional untuk mengklaim insentif di masa depan yang belum aktif. Pengirim juga membayar biaya transaksi Bitcoin yang nyata dari kantong sendiri setiap kali ia mengirim.
Saya terus bolak-balik menilai apakah ambang satu pihak yang jujur itu tahan terhadap gangguan karena begitu mudah untuk dilewati, atau justru sebuah ketergantungan yang lebih sunyi daripada komite perjanjian (covenant) dulu, karena setidaknya kegagalan komite akan terlihat. Jika pengiriman checkpoint suatu saat berhenti diam-diam, apakah Anda bahkan akan menyadarinya sebelum hal itu memengaruhi taruhan Anda sendiri?
#baby $BABY
Pinjaman dengan suku bunga tetap terdengar seperti pilihan yang lebih aman sampai Anda ingat mengapa suku bunga mengambang ada sejak awal.
Aegis sedang membangun pinjaman dengan suku bunga tetap di atas Trustless Bitcoin Vaults dari @BabylonLabs_io , yang diperkirakan akan diluncurkan akhir tahun ini. Dengan ini, suku bunga dikunci alih-alih membiarkannya bergerak mengikuti pemanfaatan seperti yang sudah dilakukan oleh pasar lending Aave v4 pada vault yang persis sama. Daya tariknya jelas: Anda mengetahui biaya Anda sejak awal, tanpa lonjakan suku bunga yang tak terduga di tengah posisi. Hal yang kurang mendapat sorotan adalah bagaimana suku bunga tetap bekerja saat permintaan benar-benar bergeser. Suku bunga mengambang memang ada khusus untuk menarik likuiditas ke tempat yang paling dibutuhkan secara real time. Suku bunga tetap tidak bisa melakukan itu—ia hanya “terpasang” pada angka yang sudah ditetapkan.
Itu bukanlah cacat persisnya, melainkan kompromi yang dipilih Aegis dengan sengaja: prediktabilitas daripada responsivitas. Ia berjalan berdampingan dengan model suku bunga mengambang Aave v4 pada vault yang mendasarinya sama, alih-alih menggantikannya. Dua taruhan berbeda pada jaminan yang sama, hidup sekaligus.
Prediktabilitas saat pasar tenang dan prediktabilitas saat terjadi krisis likuiditas adalah dua janji yang sangat berbeda, dan hanya satu dari keduanya yang benar-benar sudah diuji di mana pun dalam DeFi—apakah suku bunga tetap atau tidak.
Saya suka mengetahui suku bunga saya di muka. Apakah Anda masih akan memilih suku bunga tetap jika pool mengambang di sebelah mulai diam-diam membayar lebih tinggi begitu keadaan menjadi menegang?
#baby $BABY
Aegis sedang membangun pinjaman dengan suku bunga tetap di atas Trustless Bitcoin Vaults dari @BabylonLabs_io , yang diperkirakan akan diluncurkan akhir tahun ini. Dengan ini, suku bunga dikunci alih-alih membiarkannya bergerak mengikuti pemanfaatan seperti yang sudah dilakukan oleh pasar lending Aave v4 pada vault yang persis sama. Daya tariknya jelas: Anda mengetahui biaya Anda sejak awal, tanpa lonjakan suku bunga yang tak terduga di tengah posisi. Hal yang kurang mendapat sorotan adalah bagaimana suku bunga tetap bekerja saat permintaan benar-benar bergeser. Suku bunga mengambang memang ada khusus untuk menarik likuiditas ke tempat yang paling dibutuhkan secara real time. Suku bunga tetap tidak bisa melakukan itu—ia hanya “terpasang” pada angka yang sudah ditetapkan.
Itu bukanlah cacat persisnya, melainkan kompromi yang dipilih Aegis dengan sengaja: prediktabilitas daripada responsivitas. Ia berjalan berdampingan dengan model suku bunga mengambang Aave v4 pada vault yang mendasarinya sama, alih-alih menggantikannya. Dua taruhan berbeda pada jaminan yang sama, hidup sekaligus.
Prediktabilitas saat pasar tenang dan prediktabilitas saat terjadi krisis likuiditas adalah dua janji yang sangat berbeda, dan hanya satu dari keduanya yang benar-benar sudah diuji di mana pun dalam DeFi—apakah suku bunga tetap atau tidak.
Saya suka mengetahui suku bunga saya di muka. Apakah Anda masih akan memilih suku bunga tetap jika pool mengambang di sebelah mulai diam-diam membayar lebih tinggi begitu keadaan menjadi menegang?
#baby $BABY
Peminjaman Aave v4 adalah hal pertama yang menarik perhatian saya dengan Trustless Bitcoin Vaults dari @BabylonLabs_io , tetapi semakin lama saya menghabiskan waktu dengan desain ini, semakin saya yakin bahwa pinjam-meminjam hanyalah langkah pembuka, bukan batas teratas.
Begitu native BTC bisa dijadikan agunan yang dapat diverifikasi tanpa harus meninggalkan Bitcoin, primitf yang sama tidak lagi spesifik untuk satu kasus penggunaan. Sebuah vault tidak tahu atau peduli apakah aplikasi yang membaca statusnya adalah pasar lending, penerbit stablecoin, meja derivatif yang membutuhkan margin, atau produk asuransi yang butuh modal yang dikomit. Vault hanya tahu bahwa ada BTC yang terkunci di bawah kondisi yang ditetapkan pada saat vault itu dibuat.
Itulah yang membuatnya terasa lebih besar daripada sekadar satu produk untuk saya. Aegis sudah membangun peminjaman fixed-rate dengan menggunakan jalur yang sama seperti Aave v4. GoMining menyalurkan modal pinjaman ke imbal hasil penambangan melalui struktur vault yang sama. Keduanya tidak perlu membuat model kustodi baru mereka sendiri; mereka hanya terhubung ke kustodi yang sudah dibangun oleh Babylon.
Saya pikir ini taruhan yang sebenarnya—bukan satu aplikasi andalan—melainkan Bitcoin menjadi agunan yang bisa diprogram yang dapat dibangun di atasnya oleh produk keuangan yang serius, tanpa pernah meminta pemegang BTC untuk melepaskan hal yang mereka datangi ke Bitcoin untuk pertama kalinya.
#baby $BABY @BabylonLabs_io
Begitu native BTC bisa dijadikan agunan yang dapat diverifikasi tanpa harus meninggalkan Bitcoin, primitf yang sama tidak lagi spesifik untuk satu kasus penggunaan. Sebuah vault tidak tahu atau peduli apakah aplikasi yang membaca statusnya adalah pasar lending, penerbit stablecoin, meja derivatif yang membutuhkan margin, atau produk asuransi yang butuh modal yang dikomit. Vault hanya tahu bahwa ada BTC yang terkunci di bawah kondisi yang ditetapkan pada saat vault itu dibuat.
Itulah yang membuatnya terasa lebih besar daripada sekadar satu produk untuk saya. Aegis sudah membangun peminjaman fixed-rate dengan menggunakan jalur yang sama seperti Aave v4. GoMining menyalurkan modal pinjaman ke imbal hasil penambangan melalui struktur vault yang sama. Keduanya tidak perlu membuat model kustodi baru mereka sendiri; mereka hanya terhubung ke kustodi yang sudah dibangun oleh Babylon.
Saya pikir ini taruhan yang sebenarnya—bukan satu aplikasi andalan—melainkan Bitcoin menjadi agunan yang bisa diprogram yang dapat dibangun di atasnya oleh produk keuangan yang serius, tanpa pernah meminta pemegang BTC untuk melepaskan hal yang mereka datangi ke Bitcoin untuk pertama kalinya.
#baby $BABY @BabylonLabs_io
Lihat terjemahan
I read the isolation rule in Babylon's vault design as a security feature first, one weak app can't drag a vault meant for a different app down with it. Going through the team's own quarterly call, the reasoning behind it turned out to be more specific than I expected.
They were asked directly whether one vault could route to multiple DeFi protocols at once. The answer was no, and the stated reason wasn't capacity or engineering effort, it was that a single vault carrying different liquidation rules and different trust assumptions from multiple apps at the same time was something they didn't want to build, on purpose.
That reframes the boundary as a deliberate refusal, not just a current limitation waiting for a future upgrade. It also means the tradeoff is permanent by design, not a temporary gap someone will close later.
The part I keep sitting with is what this looks like once Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io actually integrate with more than one or two applications. Every new app means a fresh vault, a fresh peg-in, a fresh slice of BTC that cannot follow you if that app's risk profile changes later. Isolation protects you from someone else's failure. It does not protect you from wanting to leave.
Whether that becomes a minor cost of doing this safely or a real drag on capital efficiency probably depends on how many apps actually show up to integrate, and that is something no one can answer yet.
#baby $BABY @BabylonLabs_io
They were asked directly whether one vault could route to multiple DeFi protocols at once. The answer was no, and the stated reason wasn't capacity or engineering effort, it was that a single vault carrying different liquidation rules and different trust assumptions from multiple apps at the same time was something they didn't want to build, on purpose.
That reframes the boundary as a deliberate refusal, not just a current limitation waiting for a future upgrade. It also means the tradeoff is permanent by design, not a temporary gap someone will close later.
The part I keep sitting with is what this looks like once Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io actually integrate with more than one or two applications. Every new app means a fresh vault, a fresh peg-in, a fresh slice of BTC that cannot follow you if that app's risk profile changes later. Isolation protects you from someone else's failure. It does not protect you from wanting to leave.
Whether that becomes a minor cost of doing this safely or a real drag on capital efficiency probably depends on how many apps actually show up to integrate, and that is something no one can answer yet.
#baby $BABY @BabylonLabs_io
Satu detail tentang Trustless Bitcoin Vaults mengubah cara saya memandang jaminan Bitcoin.
Vault bukanlah sebuah akun.
Itu hanya satu Bitcoin UTXO.
Awalnya, hal itu terasa seperti keterbatasan.
Mengapa tidak saja membagi jaminan kapan pun Anda membutuhkannya?
Lalu saya menyadari TBV menghormati cara Bitcoin sebenarnya bekerja, alih-alih berpura-pura Bitcoin berperilaku seperti rantai berbasis akun.
Keputusan itu menciptakan trade-off yang menarik.
Karena vault tidak bisa dibagi, likuidasi tidak bisa menyita "setengah" dari jaminan Anda.
Entah vault itu diambil seluruhnya, atau dibiarkan tetap utuh.
Itulah mengapa Babylon merekomendasikan untuk sejak awal membagi BTC ke dalam beberapa vault, termasuk sebuah vault pengorbanan yang lebih kecil yang ditempatkan paling pertama dalam urutan likuidasi.
Saya merasa itu sangat elegan.
Alih-alih mengubah model akuntansi Bitcoin, protokol menyesuaikan desainnya sendiri agar selaras dengan struktur bawaan Bitcoin.
Perbedaannya memang halus, tapi penting.
Banyak protokol mencoba memaksa Bitcoin masuk ke sistem yang awalnya dirancang untuk blockchain lain.
TBV tampaknya berawal dari asumsi yang berlawanan:
Terima batasan Bitcoin terlebih dahulu.
Lalu bangun mekanisme baru di sekitarnya.
Apakah pendekatan ini akan menjadi standar masih perlu dilihat.
Tapi saya berpendapat protokol yang menghormati properti aset yang mereka bangun umumnya punya peluang bertahan lebih baik dibanding yang mencoba membentuk ulang aset itu sendiri.
Saya penasaran apakah proyek Bitcoin DeFi di masa depan akan mengikuti filosofi ini, atau terus berusaha membuat Bitcoin berperilaku seperti sesuatu yang tidak pernah dirancang untuk menjadi begitu.
#baby $BABY @BabylonLabs_io
Vault bukanlah sebuah akun.
Itu hanya satu Bitcoin UTXO.
Awalnya, hal itu terasa seperti keterbatasan.
Mengapa tidak saja membagi jaminan kapan pun Anda membutuhkannya?
Lalu saya menyadari TBV menghormati cara Bitcoin sebenarnya bekerja, alih-alih berpura-pura Bitcoin berperilaku seperti rantai berbasis akun.
Keputusan itu menciptakan trade-off yang menarik.
Karena vault tidak bisa dibagi, likuidasi tidak bisa menyita "setengah" dari jaminan Anda.
Entah vault itu diambil seluruhnya, atau dibiarkan tetap utuh.
Itulah mengapa Babylon merekomendasikan untuk sejak awal membagi BTC ke dalam beberapa vault, termasuk sebuah vault pengorbanan yang lebih kecil yang ditempatkan paling pertama dalam urutan likuidasi.
Saya merasa itu sangat elegan.
Alih-alih mengubah model akuntansi Bitcoin, protokol menyesuaikan desainnya sendiri agar selaras dengan struktur bawaan Bitcoin.
Perbedaannya memang halus, tapi penting.
Banyak protokol mencoba memaksa Bitcoin masuk ke sistem yang awalnya dirancang untuk blockchain lain.
TBV tampaknya berawal dari asumsi yang berlawanan:
Terima batasan Bitcoin terlebih dahulu.
Lalu bangun mekanisme baru di sekitarnya.
Apakah pendekatan ini akan menjadi standar masih perlu dilihat.
Tapi saya berpendapat protokol yang menghormati properti aset yang mereka bangun umumnya punya peluang bertahan lebih baik dibanding yang mencoba membentuk ulang aset itu sendiri.
Saya penasaran apakah proyek Bitcoin DeFi di masa depan akan mengikuti filosofi ini, atau terus berusaha membuat Bitcoin berperilaku seperti sesuatu yang tidak pernah dirancang untuk menjadi begitu.
#baby $BABY @BabylonLabs_io
Lihat terjemahan
I assumed Babylon only needed to check Bitcoin at the moment something mattered, confirming a stake, verifying a checkpoint, then moving on. Reading through the BTC Light Client module changed that picture.
Babylon Genesis keeps its own continuously updated view of the Bitcoin chain. It starts from a base header chosen deep enough to be treated as final and positioned exactly at a difficulty-adjustment boundary, then extends from there by applying Bitcoin's own proof-of-work rules through a message called MsgInsertHeaders. Vigilante Reporters carry the headers over, but they don't get to decide what counts as true. If competing branches show up, Genesis just follows whichever one has the most accumulated work behind it, the same rule Bitcoin itself uses.
That is a different kind of trust than checking a single inclusion proof and moving on. @BabylonLabs_io isn't asking an operator whether a Bitcoin event happened. It is verifying that event against a header chain it has been building and checking for itself the whole time.
The tradeoff is that Genesis now has an ongoing job instead of a one-time check. If reporters fall behind, or a Bitcoin reorg reshuffles recent blocks, Genesis has to notice and stay accurate through it, not just verify correctly whenever someone happens to ask.
I still don't have a good sense of how that holds up during an actual reorg or a period of degraded reporting, only that the rule for resolving it, follow the most accumulated work, is simple enough to trust on paper.
#baby $BABY
Babylon Genesis keeps its own continuously updated view of the Bitcoin chain. It starts from a base header chosen deep enough to be treated as final and positioned exactly at a difficulty-adjustment boundary, then extends from there by applying Bitcoin's own proof-of-work rules through a message called MsgInsertHeaders. Vigilante Reporters carry the headers over, but they don't get to decide what counts as true. If competing branches show up, Genesis just follows whichever one has the most accumulated work behind it, the same rule Bitcoin itself uses.
That is a different kind of trust than checking a single inclusion proof and moving on. @BabylonLabs_io isn't asking an operator whether a Bitcoin event happened. It is verifying that event against a header chain it has been building and checking for itself the whole time.
The tradeoff is that Genesis now has an ongoing job instead of a one-time check. If reporters fall behind, or a Bitcoin reorg reshuffles recent blocks, Genesis has to notice and stay accurate through it, not just verify correctly whenever someone happens to ask.
I still don't have a good sense of how that holds up during an actual reorg or a period of degraded reporting, only that the rule for resolving it, follow the most accumulated work, is simple enough to trust on paper.
#baby $BABY
Terverifikasi
Lihat terjemahan
I expected the pre-signing step during vault setup to cover the obvious cases, repayment, liquidation, maybe redemption. What I did not expect was for the failure case to already be signed too, before a single satoshi had moved anywhere.
Setting up a vault for Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io , the BTC sits temporarily in a Pre-PegIn output while Bitcoin confirmations come in. During that exact window, before the vault has even activated, you are already signing the refund transaction that lets you recover your BTC if the peg-in never completes. Not a promise to build one later if something breaks. An already-signed spending path sitting there, unused, waiting for a scenario that in most cases never happens.
That surprised me more than the liquidation and redemption paths did, honestly, because those felt like the parts everyone talks about.
The refund path is the one nobody mentions, and it is signed at the same moment as everything else, under the same pre-commitment logic, nothing gets improvised later, including the exit for when things go wrong before they even go right.
It reframes what pre-signing actually means here. It is not just locking in how a healthy vault behaves. It is locking in how failure behaves too, at a point when failure has not happened and might never happen.
I still do not have a clean answer for what happens if a depositor's own signing setup breaks down during that same window, before any of these pre-signed paths exist yet. The documentation covers what happens after the graph is built. What happens if something fails before that point is less clear to me.
#baby $BABY
Setting up a vault for Trustless Bitcoin Vaults (TBV) from @BabylonLabs_io , the BTC sits temporarily in a Pre-PegIn output while Bitcoin confirmations come in. During that exact window, before the vault has even activated, you are already signing the refund transaction that lets you recover your BTC if the peg-in never completes. Not a promise to build one later if something breaks. An already-signed spending path sitting there, unused, waiting for a scenario that in most cases never happens.
That surprised me more than the liquidation and redemption paths did, honestly, because those felt like the parts everyone talks about.
The refund path is the one nobody mentions, and it is signed at the same moment as everything else, under the same pre-commitment logic, nothing gets improvised later, including the exit for when things go wrong before they even go right.
It reframes what pre-signing actually means here. It is not just locking in how a healthy vault behaves. It is locking in how failure behaves too, at a point when failure has not happened and might never happen.
I still do not have a clean answer for what happens if a depositor's own signing setup breaks down during that same window, before any of these pre-signed paths exist yet. The documentation covers what happens after the graph is built. What happens if something fails before that point is less clear to me.
#baby $BABY
Siapa yang memiliki kekuatan untuk menghentikan penarikan Anda?
Siapa yang memiliki kekuatan untuk mengambilnya sebagai gantinya?
Kebanyakan sistem menjawab kedua pertanyaan dengan cara yang sama. Siapa pun yang bisa membekukan dana Anda biasanya juga bisa memindahkannya.
Trustless Bitcoin Vaults (TBV) dari @BabylonLabs_io menjawab keduanya secara berbeda.
Sebuah Dewan Keamanan duduk di dalam desain sebagai pengaman darurat (backstop).
Dewan ini bisa memblokir pembayaran.
Dewan ini bisa memicu jeda.
Dewan ini bisa masuk ke pemulihan ketika sesuatu telah berjalan sangat buruk.
Yang tidak bisa dilakukannya justru lebih penting.
Dewan ini tidak dapat memindahkan BTC Anda.
Dewan ini tidak dapat mengubah ke mana dana itu pergi.
Dewan ini tidak dapat menarik dana ke dompet mana pun, termasuk dompetnya sendiri.
Dewan ini bisa menghentikan.
Dewan ini tidak bisa mengendalikan arah.
Bahkan dewan yang sepenuhnya dikompromikan pun tetap tidak memiliki jalan menuju Bitcoin Anda.
Hanya sebuah pintu yang bisa ditahannya agar tetap tertutup.
Kekuatan itu juga tidak dimaksudkan untuk bertahan selamanya. Desain mengarah pada penyusutannya seiring sistem matang, meskipun tidak ada tanggal pasti yang telah ditetapkan.
Kebanyakan orang mengukur keamanan dari seberapa kecil kekuatan yang ada di sekitar aset mereka.
Mungkin ukuran yang lebih baik adalah bentuk seperti apa kekuatan itu diizinkan untuk dimiliki.
Dewan yang hanya bisa berkata tidak tidak sama dengan dewan yang juga bisa berkata di mana.
#baby $BABY
Siapa yang memiliki kekuatan untuk mengambilnya sebagai gantinya?
Kebanyakan sistem menjawab kedua pertanyaan dengan cara yang sama. Siapa pun yang bisa membekukan dana Anda biasanya juga bisa memindahkannya.
Trustless Bitcoin Vaults (TBV) dari @BabylonLabs_io menjawab keduanya secara berbeda.
Sebuah Dewan Keamanan duduk di dalam desain sebagai pengaman darurat (backstop).
Dewan ini bisa memblokir pembayaran.
Dewan ini bisa memicu jeda.
Dewan ini bisa masuk ke pemulihan ketika sesuatu telah berjalan sangat buruk.
Yang tidak bisa dilakukannya justru lebih penting.
Dewan ini tidak dapat memindahkan BTC Anda.
Dewan ini tidak dapat mengubah ke mana dana itu pergi.
Dewan ini tidak dapat menarik dana ke dompet mana pun, termasuk dompetnya sendiri.
Dewan ini bisa menghentikan.
Dewan ini tidak bisa mengendalikan arah.
Bahkan dewan yang sepenuhnya dikompromikan pun tetap tidak memiliki jalan menuju Bitcoin Anda.
Hanya sebuah pintu yang bisa ditahannya agar tetap tertutup.
Kekuatan itu juga tidak dimaksudkan untuk bertahan selamanya. Desain mengarah pada penyusutannya seiring sistem matang, meskipun tidak ada tanggal pasti yang telah ditetapkan.
Kebanyakan orang mengukur keamanan dari seberapa kecil kekuatan yang ada di sekitar aset mereka.
Mungkin ukuran yang lebih baik adalah bentuk seperti apa kekuatan itu diizinkan untuk dimiliki.
Dewan yang hanya bisa berkata tidak tidak sama dengan dewan yang juga bisa berkata di mana.
#baby $BABY
Di tengah proses menyiapkan vault di testnet Babylon, antarmuka memintaku memilih Vault Provider sebelum apa pun bisa dilanjutkan, dan insting pertamaku sama seperti untuk setiap bursa terpusat: apa yang terjadi pada BTC-ku setelah aku menyerahkannya kepada mereka.
Ternyata insting itu keliru untuk Trustless Bitcoin Vaults (TBV) dari <@BabylonLabs_io >, tetapi memahami alasannya tidak cukup hanya dengan mengklik layar pilihan saja. Vault Provider mengoordinasikan peg-in, mengumpulkan tanda tangan yang diperlukan untuk membangun graph transaksi, menghasilkan bukti zero-knowledge saat penebusan, lalu menyiarkan transaksi klaim dan pembayaran atas nama Anda. Mereka juga mengambil komisi kecil untuk melakukan pekerjaan itu. Tak satu pun dari tindakan tersebut memerlukan penitipan dana. BTC tersimpan dalam output Taproot yang jalur pengeluarannya sudah ditetapkan dan ditandatangani sebelum provider melakukan apa pun, jadi tidak ada langkah di mana mereka menahan dana yang bisa saja mereka tinggalkan begitu saja.
Peran yang sebenarnya lebih mirip relay ketimbang kustodian: memindahkan pesan dan bukti antara Bitcoin dan Ethereum, bukan memindahkan asetnya sendiri.
Namun, ketergantungan itu tidak sepenuhnya hilang. Jika seorang Vault Provider mati (offline), Anda beralih ke self-claim menggunakan materi pemulihan yang seharusnya Anda simpan saat pembuatan vault, dan jalur ini memang ada secara spesifik karena waktu aktif provider tidak dijamin.
Ada juga peran terpisah yang disebut Application Vault Keeper, dijalankan oleh aplikasi mana pun yang Anda pilih, dan di testnet aku benar-benar tidak bisa membedakan hanya dari antarmuka saja di mana pekerjaan Vault Provider berakhir dan tugas Keeper dimulai. Keduanya sama-sama berada di lapisan koordinasi di luar rantai (off-chain), tidak ada yang menahan apa pun, dan batas di antara keduanya baru jadi jelas setelah aku kembali membaca dokumentasi untuk kedua kalinya.
Yang masih belum punya jawaban bagus untukku adalah bagaimana depositor seharusnya memilih provider sejak awal. Dokumentasi menjelaskan apa yang bisa dan tidak bisa dilakukan oleh peran tersebut, tetapi tidak menjelaskan bagaimana keandalan atau reputasi dinilai sebelum Anda mengunci BTC dengan salah satu dari mereka.
#baby $BABY
Ternyata insting itu keliru untuk Trustless Bitcoin Vaults (TBV) dari <@BabylonLabs_io >, tetapi memahami alasannya tidak cukup hanya dengan mengklik layar pilihan saja. Vault Provider mengoordinasikan peg-in, mengumpulkan tanda tangan yang diperlukan untuk membangun graph transaksi, menghasilkan bukti zero-knowledge saat penebusan, lalu menyiarkan transaksi klaim dan pembayaran atas nama Anda. Mereka juga mengambil komisi kecil untuk melakukan pekerjaan itu. Tak satu pun dari tindakan tersebut memerlukan penitipan dana. BTC tersimpan dalam output Taproot yang jalur pengeluarannya sudah ditetapkan dan ditandatangani sebelum provider melakukan apa pun, jadi tidak ada langkah di mana mereka menahan dana yang bisa saja mereka tinggalkan begitu saja.
Peran yang sebenarnya lebih mirip relay ketimbang kustodian: memindahkan pesan dan bukti antara Bitcoin dan Ethereum, bukan memindahkan asetnya sendiri.
Namun, ketergantungan itu tidak sepenuhnya hilang. Jika seorang Vault Provider mati (offline), Anda beralih ke self-claim menggunakan materi pemulihan yang seharusnya Anda simpan saat pembuatan vault, dan jalur ini memang ada secara spesifik karena waktu aktif provider tidak dijamin.
Ada juga peran terpisah yang disebut Application Vault Keeper, dijalankan oleh aplikasi mana pun yang Anda pilih, dan di testnet aku benar-benar tidak bisa membedakan hanya dari antarmuka saja di mana pekerjaan Vault Provider berakhir dan tugas Keeper dimulai. Keduanya sama-sama berada di lapisan koordinasi di luar rantai (off-chain), tidak ada yang menahan apa pun, dan batas di antara keduanya baru jadi jelas setelah aku kembali membaca dokumentasi untuk kedua kalinya.
Yang masih belum punya jawaban bagus untukku adalah bagaimana depositor seharusnya memilih provider sejak awal. Dokumentasi menjelaskan apa yang bisa dan tidak bisa dilakukan oleh peran tersebut, tetapi tidak menjelaskan bagaimana keandalan atau reputasi dinilai sebelum Anda mengunci BTC dengan salah satu dari mereka.
#baby $BABY
Saya awalnya mengira bagian tersulit dari Trustless Bitcoin Vaults (TBV) adalah mengunci native BTC di Bitcoin sambil menggunakannya sebagai jaminan di Ethereum.
Setelah membaca lebih dalam, saya menyadari masalah yang lebih sulit justru muncul di bagian keluar (exit).
Mengunci Bitcoin di dalam skrip Taproot yang telah ditentukan hanyalah permulaan. Tantangan sesungguhnya adalah membuktikan kepada Bitcoin bahwa peristiwa penebusan yang benar terjadi di Ethereum sebelum BTC dilepaskan.
Bitcoin tidak bisa sekadar membaca kondisi (state) Ethereum.
Dan mempercayai operator jembatan untuk mengumumkan bahwa utang telah dilunasi atau likuidasi valid akan mengulang kembali risiko perantara yang sama yang coba dihindari oleh TBV.
Babylon mendekatinya melalui proses challenge berbasis BABE.
Ketika sebuah vault memasuki redemption, sebuah bukti zero-knowledge dibuat untuk menunjukkan bahwa peristiwa Ethereum yang cocok memang terjadi. Lalu, sebuah klaim diajukan di Bitcoin, diikuti masa challenge di mana klaim yang tidak valid dapat diperdebatkan.
Hanya setelah proses itu selesai, jalur pembayaran yang telah dipresign dapat melepaskan BTC ke tujuan yang tetap ditetapkan saat vault dibuat.
Masa tunggu itu mungkin tampak seperti UX yang tidak efisien.
Namun sebenarnya di sanalah model kepercayaan menjadi terlihat.
Layanan terpusat bisa melakukan redemption lebih cepat karena pengguna mempercayainya untuk memegang BTC dan menunaikan penarikan (withdrawal). TBV menerima latensi tambahan karena pelepasan Bitcoin dikunci oleh bukti kriptografis dan proses dispute, bukan oleh janji operator.
Bagi saya, inilah bagian yang membuat desainnya layak dipelajari.
Pertanyaan sulitnya bukan apakah native BTC bisa muncul sebagai jaminan di dalam aplikasi DeFi.
Melainkan apakah Bitcoin dapat menegakkan exit final tanpa kustodian, tanpa federasi jembatan, atau tanpa fork Bitcoin.
TBV sedang berupaya memecahkan persis itu.
Setoran menciptakan peluang.
Redemption membuktikan apakah sistem benar-benar minim kepercayaan.
Itulah sebabnya saya melihat masa challenge bukan sebagai detail teknis kecil, melainkan sebagai salah satu bagian paling penting dari desain @BabylonLabs_io .
#baby $BABY
Setelah membaca lebih dalam, saya menyadari masalah yang lebih sulit justru muncul di bagian keluar (exit).
Mengunci Bitcoin di dalam skrip Taproot yang telah ditentukan hanyalah permulaan. Tantangan sesungguhnya adalah membuktikan kepada Bitcoin bahwa peristiwa penebusan yang benar terjadi di Ethereum sebelum BTC dilepaskan.
Bitcoin tidak bisa sekadar membaca kondisi (state) Ethereum.
Dan mempercayai operator jembatan untuk mengumumkan bahwa utang telah dilunasi atau likuidasi valid akan mengulang kembali risiko perantara yang sama yang coba dihindari oleh TBV.
Babylon mendekatinya melalui proses challenge berbasis BABE.
Ketika sebuah vault memasuki redemption, sebuah bukti zero-knowledge dibuat untuk menunjukkan bahwa peristiwa Ethereum yang cocok memang terjadi. Lalu, sebuah klaim diajukan di Bitcoin, diikuti masa challenge di mana klaim yang tidak valid dapat diperdebatkan.
Hanya setelah proses itu selesai, jalur pembayaran yang telah dipresign dapat melepaskan BTC ke tujuan yang tetap ditetapkan saat vault dibuat.
Masa tunggu itu mungkin tampak seperti UX yang tidak efisien.
Namun sebenarnya di sanalah model kepercayaan menjadi terlihat.
Layanan terpusat bisa melakukan redemption lebih cepat karena pengguna mempercayainya untuk memegang BTC dan menunaikan penarikan (withdrawal). TBV menerima latensi tambahan karena pelepasan Bitcoin dikunci oleh bukti kriptografis dan proses dispute, bukan oleh janji operator.
Bagi saya, inilah bagian yang membuat desainnya layak dipelajari.
Pertanyaan sulitnya bukan apakah native BTC bisa muncul sebagai jaminan di dalam aplikasi DeFi.
Melainkan apakah Bitcoin dapat menegakkan exit final tanpa kustodian, tanpa federasi jembatan, atau tanpa fork Bitcoin.
TBV sedang berupaya memecahkan persis itu.
Setoran menciptakan peluang.
Redemption membuktikan apakah sistem benar-benar minim kepercayaan.
Itulah sebabnya saya melihat masa challenge bukan sebagai detail teknis kecil, melainkan sebagai salah satu bagian paling penting dari desain @BabylonLabs_io .
#baby $BABY
vaultBTC memiliki “BTC” di namanya, jadi awalnya saya mengira itu versi lain yang dibungkus dari Bitcoin.
Setelah membaca cara kerja Trustless Bitcoin Vaults (TBV), saya menyadari asumsi itu melewatkan seluruh desain.
Wrapped Bitcoin biasanya mengikuti model yang sudah familiar: native BTC ditempatkan di bawah kendali kustodian atau bridge, lalu token yang dapat dipindahtangankan diterbitkan di chain lain. Token tersebut bergerak melalui DeFi, sementara pengguna bergantung pada jalur penebusan dari luar untuk kembali ke BTC asli.
vaultBTC tidak bekerja seperti itu.
Native BTC tetap terkunci dalam vault Taproot di Jaringan Bitcoin. Ketika vault tersebut menjadi aktif untuk integrasi Aave v4, adapter membuat vaultBTC hanya sebagai catatan akuntansi internal agar pasar pinjaman dapat mengenali nilai dari agunan.
Itu tidak dikirim ke dompet pengguna.
Itu tidak dapat dipindahkan ke alamat sembarang.
Tidak ada pasar sekunder.
Dan itu dibakar ketika vault ditarik atau dilikuidasi.
Perbedaan itu penting karena representasi akuntansi tidak pernah mencoba menjadi pengganti untuk Bitcoin itu sendiri. Representasi ini tidak beredar secara independen, tidak menciptakan pasar terpisah, dan tidak meminta pengguna untuk memperlakukan token di Ethereum seolah-olah itu BTC yang mendasarinya.
Aset dan catatannya tetap terpisah.
Bitcoin tetap berada di Bitcoin, di mana jalur pengeluarannya ditegakkan oleh skrip Taproot yang disepakati saat pembuatan vault. Ethereum hanya menerima lapisan akuntansi yang diperlukan untuk pinjam-meminjam, pembayaran kembali, pemeriksaan health-factor, dan likuidasi.
Menurut saya, ini adalah salah satu ide paling bersih dalam desain Babylon.
Kebanyakan sistem lintas-chain memindahkan aset terlebih dahulu dan menjelaskan asumsi kepercayaannya nanti.
TBV berangkat dari pertanyaan yang berlawanan: Bagaimana sebuah aplikasi dapat menggunakan Bitcoin sebagai agunan tanpa mengubah Bitcoin menjadi sesuatu yang lain?
Jawabannya bukan aset wrapped yang lain.
Bitcoin tetap menjadi agunannya.
vaultBTC tetap menjadi bahasa akuntansi yang digunakan aplikasi untuk memahaminya.
#baby $BABY @BabylonLabs_io
Setelah membaca cara kerja Trustless Bitcoin Vaults (TBV), saya menyadari asumsi itu melewatkan seluruh desain.
Wrapped Bitcoin biasanya mengikuti model yang sudah familiar: native BTC ditempatkan di bawah kendali kustodian atau bridge, lalu token yang dapat dipindahtangankan diterbitkan di chain lain. Token tersebut bergerak melalui DeFi, sementara pengguna bergantung pada jalur penebusan dari luar untuk kembali ke BTC asli.
vaultBTC tidak bekerja seperti itu.
Native BTC tetap terkunci dalam vault Taproot di Jaringan Bitcoin. Ketika vault tersebut menjadi aktif untuk integrasi Aave v4, adapter membuat vaultBTC hanya sebagai catatan akuntansi internal agar pasar pinjaman dapat mengenali nilai dari agunan.
Itu tidak dikirim ke dompet pengguna.
Itu tidak dapat dipindahkan ke alamat sembarang.
Tidak ada pasar sekunder.
Dan itu dibakar ketika vault ditarik atau dilikuidasi.
Perbedaan itu penting karena representasi akuntansi tidak pernah mencoba menjadi pengganti untuk Bitcoin itu sendiri. Representasi ini tidak beredar secara independen, tidak menciptakan pasar terpisah, dan tidak meminta pengguna untuk memperlakukan token di Ethereum seolah-olah itu BTC yang mendasarinya.
Aset dan catatannya tetap terpisah.
Bitcoin tetap berada di Bitcoin, di mana jalur pengeluarannya ditegakkan oleh skrip Taproot yang disepakati saat pembuatan vault. Ethereum hanya menerima lapisan akuntansi yang diperlukan untuk pinjam-meminjam, pembayaran kembali, pemeriksaan health-factor, dan likuidasi.
Menurut saya, ini adalah salah satu ide paling bersih dalam desain Babylon.
Kebanyakan sistem lintas-chain memindahkan aset terlebih dahulu dan menjelaskan asumsi kepercayaannya nanti.
TBV berangkat dari pertanyaan yang berlawanan: Bagaimana sebuah aplikasi dapat menggunakan Bitcoin sebagai agunan tanpa mengubah Bitcoin menjadi sesuatu yang lain?
Jawabannya bukan aset wrapped yang lain.
Bitcoin tetap menjadi agunannya.
vaultBTC tetap menjadi bahasa akuntansi yang digunakan aplikasi untuk memahaminya.
#baby $BABY @BabylonLabs_io
Sebagian Benar
Yang paling menonjol bagi saya tentang Trustless Bitcoin Vaults (TBV) bukan sekadar bahwa mereka memungkinkan Bitcoin masuk ke DeFi. Melainkan bahwa aktivitas peminjaman dapat berpindah ke Ethereum sementara aset BTC yang mendasarinya tetap tidak berubah.
Dalam sebagian besar model DeFi Bitcoin, aset harus ditransformasikan sebelum menjadi berguna. BTC disetor ke seorang kustodian, dipindahkan melalui sebuah bridge, atau direpresentasikan sebagai token wrapped di rantai lain. Itu menciptakan likuiditas, tetapi juga mengubah model kepercayaan. Pengguna tidak lagi hanya mengandalkan Bitcoin. Mereka mengandalkan penerbit, bridge, sekumpulan penandatangan (signer set), atau proses penebusan.
TBV mengambil rute yang berbeda. Native BTC tetap terkunci di dalam skrip Taproot pada Jaringan Bitcoin. Di Ethereum, protokol melacak vault tersebut dan memungkinkan aplikasi terintegrasi seperti Aave v4 mengenali BTC terkunci itu sebagai jaminan (collateral).
Pemisahan ini penting karena Ethereum menangani logika pemberian pinjaman, sementara Bitcoin terus memegang aset itu sendiri.
Pengguna dapat meminjam aset yang didukung melalui lapisan aplikasi, tetapi BTC tidak ditransfer ke dalam wallet Ethereum, tidak disetor ke kustodian, dan tidak diubah menjadi token wrapped yang bebas diperdagangkan. Jaminan tetap berada di tempat yang memungkinkan aturan konsensus Bitcoin sendiri menegakkan jalur penggunaan (spending paths) yang telah disepakati saat vault dibuat.
Bagi saya, itulah pergeseran desain yang sesungguhnya.
TBV tidak mencoba membuat Bitcoin menjadi berguna dengan memindahkannya ke tempat lain. TBV berusaha membuat Bitcoin tetap berguna sambil mempertahankan lingkungan settlement alaminya.
Namun masih ada trade-off. Peg-in memerlukan konfirmasi Bitcoin, penebusan memakan waktu lebih lama karena proses pembuktian dan challenge, serta risiko tingkat aplikasi seperti smart contract, oracle, health factor, dan likuidasi tetap ada.
Tetapi itu adalah risiko yang berbeda dibanding menyerahkan custody atas BTC asli.
Itulah mengapa pendekatan @BabylonLabs_io menarik: aktivitas DeFi dapat terjadi lintas rantai, sementara jaminan inti tetap asli (native) terhadap Bitcoin.
#baby $BABY
Dalam sebagian besar model DeFi Bitcoin, aset harus ditransformasikan sebelum menjadi berguna. BTC disetor ke seorang kustodian, dipindahkan melalui sebuah bridge, atau direpresentasikan sebagai token wrapped di rantai lain. Itu menciptakan likuiditas, tetapi juga mengubah model kepercayaan. Pengguna tidak lagi hanya mengandalkan Bitcoin. Mereka mengandalkan penerbit, bridge, sekumpulan penandatangan (signer set), atau proses penebusan.
TBV mengambil rute yang berbeda. Native BTC tetap terkunci di dalam skrip Taproot pada Jaringan Bitcoin. Di Ethereum, protokol melacak vault tersebut dan memungkinkan aplikasi terintegrasi seperti Aave v4 mengenali BTC terkunci itu sebagai jaminan (collateral).
Pemisahan ini penting karena Ethereum menangani logika pemberian pinjaman, sementara Bitcoin terus memegang aset itu sendiri.
Pengguna dapat meminjam aset yang didukung melalui lapisan aplikasi, tetapi BTC tidak ditransfer ke dalam wallet Ethereum, tidak disetor ke kustodian, dan tidak diubah menjadi token wrapped yang bebas diperdagangkan. Jaminan tetap berada di tempat yang memungkinkan aturan konsensus Bitcoin sendiri menegakkan jalur penggunaan (spending paths) yang telah disepakati saat vault dibuat.
Bagi saya, itulah pergeseran desain yang sesungguhnya.
TBV tidak mencoba membuat Bitcoin menjadi berguna dengan memindahkannya ke tempat lain. TBV berusaha membuat Bitcoin tetap berguna sambil mempertahankan lingkungan settlement alaminya.
Namun masih ada trade-off. Peg-in memerlukan konfirmasi Bitcoin, penebusan memakan waktu lebih lama karena proses pembuktian dan challenge, serta risiko tingkat aplikasi seperti smart contract, oracle, health factor, dan likuidasi tetap ada.
Tetapi itu adalah risiko yang berbeda dibanding menyerahkan custody atas BTC asli.
Itulah mengapa pendekatan @BabylonLabs_io menarik: aktivitas DeFi dapat terjadi lintas rantai, sementara jaminan inti tetap asli (native) terhadap Bitcoin.
#baby $BABY
Peringatan phishing MetaMask telah memberi tahu pengguna untuk tidak melanjutkan selama bertahun-tahun. Namun orang tetap saja menerobosnya—cukup banyak sehingga peringatan itu hampir tidak lagi terasa sebagai peringatan, hanya layar merah di antara mereka dan hal yang sudah mereka putuskan untuk dilakukan.
Itulah mode kegagalan yang tertanam dalam setiap sistem peringatan lalu membiarkan lewat. Peringatan hanya bekerja pada seseorang yang memang sudah berniat untuk berhenti. Siapa pun yang sudah memutuskan langsung saja menekan lewatnya, dan setelah pengulangan yang cukup, klik itu menjadi refleks.
Kebijakan yang melakukan pemblokiran keras, bukan sekadar peringatan, menghapus pilihan pada saat yang paling penting—kedengarannya tegas, sampai Anda menyadari bahwa peringatan itu sebenarnya tidak pernah benar-benar menjadi pilihan bagi kebanyakan orang; hanya hambatan yang sudah dipelajari untuk diabaikan.
Pemeriksaan kebijakan Newton bermuara pada verifikasi atau tidak, lolos atau transaksi tidak berlanjut—bukan layar merah yang bisa dilewati. Jenis keamanannya lebih sempit dibanding sistem yang mencoba menginformasikan setiap pengguna yang mungkin. Ini juga jenis yang tidak bergantung pada seseorang benar-benar membaca peringatannya.
Jika peringatan hanya menghentikan orang yang sejak awal memang berniat berhenti, apakah itu pernah benar-benar melindungi siapa pun?
#newt $NEWT @NewtonProtocol
Itulah mode kegagalan yang tertanam dalam setiap sistem peringatan lalu membiarkan lewat. Peringatan hanya bekerja pada seseorang yang memang sudah berniat untuk berhenti. Siapa pun yang sudah memutuskan langsung saja menekan lewatnya, dan setelah pengulangan yang cukup, klik itu menjadi refleks.
Kebijakan yang melakukan pemblokiran keras, bukan sekadar peringatan, menghapus pilihan pada saat yang paling penting—kedengarannya tegas, sampai Anda menyadari bahwa peringatan itu sebenarnya tidak pernah benar-benar menjadi pilihan bagi kebanyakan orang; hanya hambatan yang sudah dipelajari untuk diabaikan.
Pemeriksaan kebijakan Newton bermuara pada verifikasi atau tidak, lolos atau transaksi tidak berlanjut—bukan layar merah yang bisa dilewati. Jenis keamanannya lebih sempit dibanding sistem yang mencoba menginformasikan setiap pengguna yang mungkin. Ini juga jenis yang tidak bergantung pada seseorang benar-benar membaca peringatannya.
Jika peringatan hanya menghentikan orang yang sejak awal memang berniat berhenti, apakah itu pernah benar-benar melindungi siapa pun?
#newt $NEWT @NewtonProtocol
Masuk untuk menjelajahi konten lainnya