Nova_eth_20
423 Posting
Nova_eth_20
129 Mengikuti
1.5K+ Pengikut
451 Disukai
Posting
Semua
Kuotasi
✌🏻✨🔥$STAR
$TUT
$TUT
Mù 穆涵
·
--
$STAR $GPS $DUSK #dusk @Dusk
Dusk's 80/10/5/5 tidak nyata—ini yang sebenarnya ada di block reward
Saya sedang mengecek rewards saya pagi ini sekitar pukul 10–11, dan pembagiannya terlihat berbeda dari yang saya ingat, jadi saya membuka dashboard staking dan kembali ke halaman tokenomics.
Baris yang menarik perhatian saya adalah: "70% + hingga 10%."
Block generator mendapat 70% tetap. Tambahan 10% itu tidak dijamin—tergantung kredit yang disertakan dalam sertifikat. Dan jika sebagian darinya tidak didistribusikan, Dusk membakarnya.
Jadi ringkasan yang biasa:
80% → block generator
10% → development
5% → validation
5% → ratification
terlewat satu kondisi penting. Struktur aslinya adalah:
70% → porsi block-generator yang tetap
hingga 10% → porsi block-generator yang bersifat kondisional
10% → development
5% → validation
5% → ratification
Bagian yang saya temukan menarik adalah ke mana perginya reward yang tidak terpakai: tidak ke mana-mana. Itu tidak dialihkan ke komite lain atau dana pengembangan. Itu dibakar.
Ini mengingatkan saya pada cara kerja miles maskapai. Anda mendapat tarif dasar untuk setiap tiket—dijamin. Tetapi bonus miles—yang terkait dengan kelas tarif atau kondisi promo—hanya masuk jika Anda benar-benar memenuhi kondisinya. Kalau tidak, bonus itu tidak bergulir ke waktu berikutnya. Hilang begitu saja. Mekanisme sertifikat berbasis Dusk untuk 10% bekerja dengan cara yang sama: kondisional, dan tidak diklaim secara default.
Hal ini penting jika dilihat dari gambaran yang lebih besar. Dusk dijadwalkan untuk mengeluarkan 500M DUSK untuk rewards staking selama 36 tahun, dengan kurva penurunan (decay) yang tetap.
Jadwal utama hanya memberi tahu apa yang bisa dikeluarkan. Mekanisme ini diam-diam menentukan berapa banyak dari itu yang benar-benar didistribusikan. Tekanan deflasi yang kecil namun struktural, tersembunyi di dalam model inflasi yang terlihat sederhana.
Yang tidak dijelaskan oleh dokumen: apa yang tepatnya menghasilkan kredit sertifikat itu, dan seberapa sering provisioner menangkap tambahan 10% penuh dibanding kehilangan sebagian darinya untuk dibakar.
Saya membuka dashboard dengan harapan mendapatkan pembagian reward yang sederhana. Yang saya temukan justru pembagian yang kondisional. 🧐
Menurut Anda bagaimana reward kondisional 10% milik Dusk?
Dusk's 80/10/5/5 tidak nyata—ini yang sebenarnya ada di block reward
Saya sedang mengecek rewards saya pagi ini sekitar pukul 10–11, dan pembagiannya terlihat berbeda dari yang saya ingat, jadi saya membuka dashboard staking dan kembali ke halaman tokenomics.
Baris yang menarik perhatian saya adalah: "70% + hingga 10%."
Block generator mendapat 70% tetap. Tambahan 10% itu tidak dijamin—tergantung kredit yang disertakan dalam sertifikat. Dan jika sebagian darinya tidak didistribusikan, Dusk membakarnya.
Jadi ringkasan yang biasa:
80% → block generator
10% → development
5% → validation
5% → ratification
terlewat satu kondisi penting. Struktur aslinya adalah:
70% → porsi block-generator yang tetap
hingga 10% → porsi block-generator yang bersifat kondisional
10% → development
5% → validation
5% → ratification
Bagian yang saya temukan menarik adalah ke mana perginya reward yang tidak terpakai: tidak ke mana-mana. Itu tidak dialihkan ke komite lain atau dana pengembangan. Itu dibakar.
Ini mengingatkan saya pada cara kerja miles maskapai. Anda mendapat tarif dasar untuk setiap tiket—dijamin. Tetapi bonus miles—yang terkait dengan kelas tarif atau kondisi promo—hanya masuk jika Anda benar-benar memenuhi kondisinya. Kalau tidak, bonus itu tidak bergulir ke waktu berikutnya. Hilang begitu saja. Mekanisme sertifikat berbasis Dusk untuk 10% bekerja dengan cara yang sama: kondisional, dan tidak diklaim secara default.
Hal ini penting jika dilihat dari gambaran yang lebih besar. Dusk dijadwalkan untuk mengeluarkan 500M DUSK untuk rewards staking selama 36 tahun, dengan kurva penurunan (decay) yang tetap.
Jadwal utama hanya memberi tahu apa yang bisa dikeluarkan. Mekanisme ini diam-diam menentukan berapa banyak dari itu yang benar-benar didistribusikan. Tekanan deflasi yang kecil namun struktural, tersembunyi di dalam model inflasi yang terlihat sederhana.
Yang tidak dijelaskan oleh dokumen: apa yang tepatnya menghasilkan kredit sertifikat itu, dan seberapa sering provisioner menangkap tambahan 10% penuh dibanding kehilangan sebagian darinya untuk dibakar.
Saya membuka dashboard dengan harapan mendapatkan pembagian reward yang sederhana. Yang saya temukan justru pembagian yang kondisional. 🧐
Menurut Anda bagaimana reward kondisional 10% milik Dusk?
#baby $BABY @BabylonLabs_io
Saya sedang membandingkan validator untuk delegasi BABY saya dan hampir melewatkan "penahanan" (jailing) sebagai boilerplate standar Cosmos yang dimiliki setiap chain: missed blocks, timeout sementara, tidak ada yang spesifik untuk Babylon. Lalu saya membaca apa yang sebenarnya ditandatangani validator—dua kali, bukan sekali.
Setiap validator Babylon Genesis mengerjakan dua tugas terpisah. Penandatanganan blok CometBFT reguler, pekerjaan biasa yang dilakukan validator Cosmos mana pun, dan yang kedua: pemungutan suara BLS di akhir setiap epoch, di mana tanda tangan validator digabungkan menjadi sebuah checkpoint yang diberi timestamp langsung ke Bitcoin. Tanda tangan kedua inilah alasan utamanya orang menyebut chain ini "Bitcoin-secured".
Penahanan karena downtime hanya memperhatikan tugas pertama, dengan caranya sendiri, penegakan liveness standar, tidak ada yang dramatis. Yang tidak bisa saya pastikan secara tepat adalah interaksi detailnya: apakah penahanan yang terjadi di tengah epoch secara diam-diam membuat kontribusi BLS seluruh epoch itu menjadi tidak sah, atau hanya menjadi masalah jika validator tersebut masih aktif pada saat epoch ditutup. Dokumen Babylon menegaskan bahwa dua tugas ini terpisah. Namun mereka tidak menjelaskan batas waktu spesifik tersebut di mana pun yang saya temukan.
Bagaimanapun juga, kedua tugas tersebut berbagi satu catatan uptime. Validator yang ditahan karena missed blocks biasa—aturan yang sama seperti yang dijalankan chain Cosmos mana pun—tidak otomatis terlindungi dari juga melewatkan tanda tangan yang benar-benar di-anchor ke Bitcoin pada epoch itu, untuk alasan yang sama sekali tidak ada hubungannya dengan keamanan Bitcoin.
Saya tidak menganggap ini sebagai cacat desain; tidak ada cara yang bersih untuk menahan seseorang dari satu peran dan tidak dari peran lainnya pada kunci yang sama. Yang belum saya pisahkan dalam kepala saya sebelumnya adalah bahwa riwayat downtime bukan hanya soal reward yang terlewat. Itu merupakan perkiraan kasar seberapa sering seorang validator benar-benar hadir untuk tanda tangan yang membuat klaim "Bitcoin-secured" itu menjadi kenyataan.
Saya cek lagi riwayat penahanan dari shortlist saya. Dua nama masing-masing punya satu entri, semuanya lebih dari setahun lalu, dan keduanya diikuti rangkaian waktu yang panjang dan bersih setelah itu. Bukan tanda bahaya. Hanya saja bukan nol yang sama yang saya kira persentase uptime bersih itu sudah memberi tahu saya.
$BLESS
🤔 Apa hal pertama yang kamu periksa sebelum mendelegasikan baby-mu
Saya sedang membandingkan validator untuk delegasi BABY saya dan hampir melewatkan "penahanan" (jailing) sebagai boilerplate standar Cosmos yang dimiliki setiap chain: missed blocks, timeout sementara, tidak ada yang spesifik untuk Babylon. Lalu saya membaca apa yang sebenarnya ditandatangani validator—dua kali, bukan sekali.
Setiap validator Babylon Genesis mengerjakan dua tugas terpisah. Penandatanganan blok CometBFT reguler, pekerjaan biasa yang dilakukan validator Cosmos mana pun, dan yang kedua: pemungutan suara BLS di akhir setiap epoch, di mana tanda tangan validator digabungkan menjadi sebuah checkpoint yang diberi timestamp langsung ke Bitcoin. Tanda tangan kedua inilah alasan utamanya orang menyebut chain ini "Bitcoin-secured".
Penahanan karena downtime hanya memperhatikan tugas pertama, dengan caranya sendiri, penegakan liveness standar, tidak ada yang dramatis. Yang tidak bisa saya pastikan secara tepat adalah interaksi detailnya: apakah penahanan yang terjadi di tengah epoch secara diam-diam membuat kontribusi BLS seluruh epoch itu menjadi tidak sah, atau hanya menjadi masalah jika validator tersebut masih aktif pada saat epoch ditutup. Dokumen Babylon menegaskan bahwa dua tugas ini terpisah. Namun mereka tidak menjelaskan batas waktu spesifik tersebut di mana pun yang saya temukan.
Bagaimanapun juga, kedua tugas tersebut berbagi satu catatan uptime. Validator yang ditahan karena missed blocks biasa—aturan yang sama seperti yang dijalankan chain Cosmos mana pun—tidak otomatis terlindungi dari juga melewatkan tanda tangan yang benar-benar di-anchor ke Bitcoin pada epoch itu, untuk alasan yang sama sekali tidak ada hubungannya dengan keamanan Bitcoin.
Saya tidak menganggap ini sebagai cacat desain; tidak ada cara yang bersih untuk menahan seseorang dari satu peran dan tidak dari peran lainnya pada kunci yang sama. Yang belum saya pisahkan dalam kepala saya sebelumnya adalah bahwa riwayat downtime bukan hanya soal reward yang terlewat. Itu merupakan perkiraan kasar seberapa sering seorang validator benar-benar hadir untuk tanda tangan yang membuat klaim "Bitcoin-secured" itu menjadi kenyataan.
Saya cek lagi riwayat penahanan dari shortlist saya. Dua nama masing-masing punya satu entri, semuanya lebih dari setahun lalu, dan keduanya diikuti rangkaian waktu yang panjang dan bersih setelah itu. Bukan tanda bahaya. Hanya saja bukan nol yang sama yang saya kira persentase uptime bersih itu sudah memberi tahu saya.
$BLESS
🤔 Apa hal pertama yang kamu periksa sebelum mendelegasikan baby-mu
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 Voting • Voting ditutup
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Saya memilih penyedia finalitas berdasarkan ukuran delegasi BTC dan riwayat uptime mereka, angka-angka yang setiap dasbor tampilkan. Baru kemudian saya membaca apa yang sebenarnya menjaga penyedia itu tetap berjalan dari hari ke hari, dan ternyata bukan BTC sama sekali.
Setiap penyedia finalitas membutuhkan kunci operasi terpisah yang didanai dengan BABY, jumlah kecil, untuk membayar gas guna melakukan komitmen randomness segar secara berulang. Pengajuan voting akan otomatis dikembalikan, dokumen operator milik Babylon menegaskan hal itu secara langsung. Transaksi lain pada kunci yang sama, termasuk komitmen randomness yang berulang, memerlukan gas yang tidak bisa kembali. Di dokumen, ini dijelaskan hampir seperti pemikiran setelahnya: dananya dengan jumlah minimum, biarkan tetap berjalan dalam waktu lama, satu kalimat di samping perangkat keamanan yang justru saya cari.
Jika lupa mengisi ulang, penyedia itu tidak akan “diam-diam” terkompromi; delegasi BTC mereka tetap persis sebesar dan sejujur kemarin. Mereka hanya tidak bisa terus berpartisipasi sampai seseorang menyadari dompet yang kosong dan menambahkan dana. Penyedia bisa sempurna di setiap metrik yang saya cek sebelum mendelegasikan, namun tetap bisa padam gara-gara sesuatu seremeh kunci gas yang tak pernah terpikir untuk diisi ulang.
Dasbor delegasi menampilkan komisi, ukuran delegasi, dan riwayat uptime. Tidak ada satupun yang menunjukkan apakah kunci operasi penyedia didanai dengan nyaman atau justru berjalan di ambang habis, karena angka itu sejak awal memang tidak dirancang untuk dipublikasikan.
Menurut saya ini bukan cacat desain: menjaga kunci operasi tetap minimal dan dipisahkan dari kepemilikan asli penyedia adalah pilihan keamanan yang masuk akal, bukan kelalaian. Dampaknya bagi siapa pun yang mendelegasikan menjadi lebih kecil: penyedia yang Anda pilih berdasarkan rekam jejak BTC mereka juga, secara diam-diam, menjalankan bisnis untuk mengingat membeli gas.
$HEI
Tahukah Anda bahwa kunci operasi penyedia finalitas bisa kehabisan bahkan ketika delegasi BTC mereka tampak sepenuhnya sehat?
Saya memilih penyedia finalitas berdasarkan ukuran delegasi BTC dan riwayat uptime mereka, angka-angka yang setiap dasbor tampilkan. Baru kemudian saya membaca apa yang sebenarnya menjaga penyedia itu tetap berjalan dari hari ke hari, dan ternyata bukan BTC sama sekali.
Setiap penyedia finalitas membutuhkan kunci operasi terpisah yang didanai dengan BABY, jumlah kecil, untuk membayar gas guna melakukan komitmen randomness segar secara berulang. Pengajuan voting akan otomatis dikembalikan, dokumen operator milik Babylon menegaskan hal itu secara langsung. Transaksi lain pada kunci yang sama, termasuk komitmen randomness yang berulang, memerlukan gas yang tidak bisa kembali. Di dokumen, ini dijelaskan hampir seperti pemikiran setelahnya: dananya dengan jumlah minimum, biarkan tetap berjalan dalam waktu lama, satu kalimat di samping perangkat keamanan yang justru saya cari.
Jika lupa mengisi ulang, penyedia itu tidak akan “diam-diam” terkompromi; delegasi BTC mereka tetap persis sebesar dan sejujur kemarin. Mereka hanya tidak bisa terus berpartisipasi sampai seseorang menyadari dompet yang kosong dan menambahkan dana. Penyedia bisa sempurna di setiap metrik yang saya cek sebelum mendelegasikan, namun tetap bisa padam gara-gara sesuatu seremeh kunci gas yang tak pernah terpikir untuk diisi ulang.
Dasbor delegasi menampilkan komisi, ukuran delegasi, dan riwayat uptime. Tidak ada satupun yang menunjukkan apakah kunci operasi penyedia didanai dengan nyaman atau justru berjalan di ambang habis, karena angka itu sejak awal memang tidak dirancang untuk dipublikasikan.
Menurut saya ini bukan cacat desain: menjaga kunci operasi tetap minimal dan dipisahkan dari kepemilikan asli penyedia adalah pilihan keamanan yang masuk akal, bukan kelalaian. Dampaknya bagi siapa pun yang mendelegasikan menjadi lebih kecil: penyedia yang Anda pilih berdasarkan rekam jejak BTC mereka juga, secara diam-diam, menjalankan bisnis untuk mengingat membeli gas.
$HEI
Tahukah Anda bahwa kunci operasi penyedia finalitas bisa kehabisan bahkan ketika delegasi BTC mereka tampak sepenuhnya sehat?
#baby @BabylonLabs_io
Baca pembahasan yang mengupas hukuman pembobolan semalam, mencari angka pasti denda BTC. Ditemukan: 0,1% dari BTC yang dipertaruhkan untuk double-signing. Lalu kutemukan baris yang berada tepat di sampingnya—yang tidak kucari: hadiah yang sebelumnya sudah diperoleh tidak ditarik kembali (clawed back).
Penyedia akan dibanned permanen, dipenjara selamanya, tidak bisa delegasi lagi, tidak bisa komisi lagi. Tapi apa pun komisi yang sudah mereka kumpulkan sebelum pelanggaran tetap menjadi milik mereka. Masa hukumannya berjalan ke depan sejak saat mereka tertangkap. Itu tidak berjalan ke belakang, meski sudah beroperasi selama yang lama sebelum itu.
Untuk penyedia yang benar-benar baru, celah itu hampir tidak berarti—belum ada akumulasi apa pun untuk ditahan. Tetapi untuk yang sudah menjalankan delegasi selama setahun, mengambil potongan komisi di setiap siklus reward selama itu, hitungannya berubah. Satu kali slash sebesar 0,1% menghantam semua pihak yang didelegasikan kepada mereka, secara proporsional, baik penyedia maupun para delegator. Yang tidak tersentuh adalah riwayat komisi, seberapa pun banyak yang mereka tinggalkan dengan hasil yang mereka pegang.
Aku tidak tahu apa yang benar-benar diperoleh penyedia mana pun selama masa jabatannya—itu tidak dipublikasikan di mana pun yang kutemukan—jadi aku tidak bisa bilang apakah celah ini sepele atau nyata. Yang bisa kubilang: efek jera memang dibangun agar hanya berjalan ke depan. Menarik kembali reward historis berarti membuka lagi setiap siklus reward masa lalu; itu kekacauan tersendiri untuk didesain.
Dibanned selamanya dan hancur (broke) adalah dua hasil yang berbeda, dan desain slashing Babylon sendiri hanya menjamin yang pertama.
$CYS $BABY
Baca pembahasan yang mengupas hukuman pembobolan semalam, mencari angka pasti denda BTC. Ditemukan: 0,1% dari BTC yang dipertaruhkan untuk double-signing. Lalu kutemukan baris yang berada tepat di sampingnya—yang tidak kucari: hadiah yang sebelumnya sudah diperoleh tidak ditarik kembali (clawed back).
Penyedia akan dibanned permanen, dipenjara selamanya, tidak bisa delegasi lagi, tidak bisa komisi lagi. Tapi apa pun komisi yang sudah mereka kumpulkan sebelum pelanggaran tetap menjadi milik mereka. Masa hukumannya berjalan ke depan sejak saat mereka tertangkap. Itu tidak berjalan ke belakang, meski sudah beroperasi selama yang lama sebelum itu.
Untuk penyedia yang benar-benar baru, celah itu hampir tidak berarti—belum ada akumulasi apa pun untuk ditahan. Tetapi untuk yang sudah menjalankan delegasi selama setahun, mengambil potongan komisi di setiap siklus reward selama itu, hitungannya berubah. Satu kali slash sebesar 0,1% menghantam semua pihak yang didelegasikan kepada mereka, secara proporsional, baik penyedia maupun para delegator. Yang tidak tersentuh adalah riwayat komisi, seberapa pun banyak yang mereka tinggalkan dengan hasil yang mereka pegang.
Aku tidak tahu apa yang benar-benar diperoleh penyedia mana pun selama masa jabatannya—itu tidak dipublikasikan di mana pun yang kutemukan—jadi aku tidak bisa bilang apakah celah ini sepele atau nyata. Yang bisa kubilang: efek jera memang dibangun agar hanya berjalan ke depan. Menarik kembali reward historis berarti membuka lagi setiap siklus reward masa lalu; itu kekacauan tersendiri untuk didesain.
Dibanned selamanya dan hancur (broke) adalah dua hasil yang berbeda, dan desain slashing Babylon sendiri hanya menjamin yang pertama.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Semalam saya memeriksa komisi penyedia finalitas sebelum mendelegasikan, 5%, terlihat wajar dibanding yang lain di daftar. Hampir mendelegasikan hanya berdasarkan angka itu. Lalu saya menemukan bahwa perintah pendaftaran yang Babylon butuhkan ternyata ada di baliknya.
Setiap penyedia finalitas menetapkan tiga angka saat pendaftaran, bukan satu. Tarif komisi saat ini, tarif maksimum yang tidak pernah bisa dilewati, dan tarif perubahan maksimum—seberapa cepat komisi diizinkan untuk naik menuju batas atas itu. Angka 5% yang saya lihat tidak pernah menjadi gambaran lengkap; itu hanya satu cuplikan pada sebuah dial, dengan batas atas yang lebih tinggi yang berdiri sendiri dan sudah ditanam sejak hari pertama.
Tidak ada yang menghentikan penyedia untuk mendaftar dengan 5% dengan batas maksimum 50%, lalu menaikkannya dalam langkah-langkah legal kecil setiap periode sampai delegator yang bergabung pada 5% mendapatkan hasil di bawah angka yang sangat berbeda. Tidak ada aturan yang dilanggar, tidak ada penipuan, hanya sebuah plafon yang sebenarnya sudah dipublikasikan sepanjang waktu.
Saya mencari di mana plafon itu benar-benar muncul bagi delegator ketika memutuskan siapa yang akan dipilih. Dari yang bisa saya temukan, dokumen staking milik Babylon sendiri dan API yang memberi makan dashboard menampilkan tepat satu field pada tahap itu: commission—lebih rendah berarti imbalan lebih tinggi—tidak lebih rinci dari itu. Bukan tarif maksimum yang letaknya satu field di sebelahnya dalam data pendaftaran milik penyedia.
Saya tidak berpikir ini membuat mekanismenya predatori. Pembatas laju perubahan ada justru agar komisi tidak bisa melonjak dalam semalam, dan perlindungan itu nyata. Yang kurang adalah hal yang lebih kecil: angka yang benar-benar membatasi pendapatan masa depan Anda tidak dibuat untuk ditampilkan pada layar yang Anda putuskan dari. Dokumen tidak mengatakan berapa banyak penyedia aktif yang sudah berpindah dari tarif awal mereka, atau seberapa dekat masing-masing dari mereka dengan plafon mereka saat ini, jadi saya tidak bisa memberi tahu Anda apakah ini risiko yang sedang terjadi atau hanya teoretis.
5% yang Anda lihat adalah sebuah foto. Plafon tersebut selalu menjadi kesepakatan yang sebenarnya.
Tahukah Anda bahwa komisi penyedia finalitas Anda bisa naik melewati angka yang Anda lihat saat ini? 📈
Semalam saya memeriksa komisi penyedia finalitas sebelum mendelegasikan, 5%, terlihat wajar dibanding yang lain di daftar. Hampir mendelegasikan hanya berdasarkan angka itu. Lalu saya menemukan bahwa perintah pendaftaran yang Babylon butuhkan ternyata ada di baliknya.
Setiap penyedia finalitas menetapkan tiga angka saat pendaftaran, bukan satu. Tarif komisi saat ini, tarif maksimum yang tidak pernah bisa dilewati, dan tarif perubahan maksimum—seberapa cepat komisi diizinkan untuk naik menuju batas atas itu. Angka 5% yang saya lihat tidak pernah menjadi gambaran lengkap; itu hanya satu cuplikan pada sebuah dial, dengan batas atas yang lebih tinggi yang berdiri sendiri dan sudah ditanam sejak hari pertama.
Tidak ada yang menghentikan penyedia untuk mendaftar dengan 5% dengan batas maksimum 50%, lalu menaikkannya dalam langkah-langkah legal kecil setiap periode sampai delegator yang bergabung pada 5% mendapatkan hasil di bawah angka yang sangat berbeda. Tidak ada aturan yang dilanggar, tidak ada penipuan, hanya sebuah plafon yang sebenarnya sudah dipublikasikan sepanjang waktu.
Saya mencari di mana plafon itu benar-benar muncul bagi delegator ketika memutuskan siapa yang akan dipilih. Dari yang bisa saya temukan, dokumen staking milik Babylon sendiri dan API yang memberi makan dashboard menampilkan tepat satu field pada tahap itu: commission—lebih rendah berarti imbalan lebih tinggi—tidak lebih rinci dari itu. Bukan tarif maksimum yang letaknya satu field di sebelahnya dalam data pendaftaran milik penyedia.
Saya tidak berpikir ini membuat mekanismenya predatori. Pembatas laju perubahan ada justru agar komisi tidak bisa melonjak dalam semalam, dan perlindungan itu nyata. Yang kurang adalah hal yang lebih kecil: angka yang benar-benar membatasi pendapatan masa depan Anda tidak dibuat untuk ditampilkan pada layar yang Anda putuskan dari. Dokumen tidak mengatakan berapa banyak penyedia aktif yang sudah berpindah dari tarif awal mereka, atau seberapa dekat masing-masing dari mereka dengan plafon mereka saat ini, jadi saya tidak bisa memberi tahu Anda apakah ini risiko yang sedang terjadi atau hanya teoretis.
5% yang Anda lihat adalah sebuah foto. Plafon tersebut selalu menjadi kesepakatan yang sebenarnya.
Tahukah Anda bahwa komisi penyedia finalitas Anda bisa naik melewati angka yang Anda lihat saat ini? 📈
#baby @BabylonLabs_io
Saya saat ini mempertaruhkan BTC melalui Babylon, jadi ketika saya menemukan kata "overflow" yang terkubur dalam dokumentasi lama Cap-3 semalam, saya tidak membacanya sebagai sejarah. Saya membacanya sebagai pertanyaan tentang posisi saya sendiri: apakah ini bisa terjadi pada saya.
Selama Fase 1, transaksi staking yang konfirmasinya terjadi setelah cap sudah terisi tetap mengunci BTC ke dalam kontrak persis seperti yang dilakukan semua orang. Mereka hanya tidak mendapatkan apa pun—tidak ada poin, tidak ada alokasi. Pengembalian koinnya pun tidak otomatis; dokumennya jelas: overflow stakes masih harus di-unbond dan ditarik, dengan waktu tunggu yang sama seperti posisi aktif, untuk stake yang membayar nol selama seluruh koin terkunci.
Yang menentukan siapa yang berhasil masuk bukanlah saat siapa pun menekan tombol stake. Itu adalah blok Bitcoin mana transaksi tersebut benar-benar terkonfirmasi, sebuah angka yang tidak sepenuhnya bisa dikendalikan siapa pun begitu keluar dari dompet. Dua orang bisa menyiarkan (broadcast) beberapa menit terpisah dan tetap mendarat dalam urutan yang berbeda tergantung biaya, kemacetan mempool, atau penambang mana yang menemukan blok berikutnya lebih dulu.
Limit Fase 1 sudah hilang, tetapi mekanisme yang menciptakan overflow tidak unik untuk fase itu. Setiap ronde yang dibatasi di masa depan—onboarding BSN baru dengan alokasi tetap, integrasi slot terbatas—mewarisi kondisi perlombaan yang sama begitu menggunakan konfirmasi blok alih-alih antrean. Tidak ada yang ditambal dari kekurangan desain itu. Itu hanya menjadi ketinggalan ketika cap menghilang.
Saya tidak yakin desain aslinya tidak adil; cap yang ketat memang perlu ada batas pemotongan, dan konfirmasi blok tidak bisa dipalsukan seperti timestamp. Yang tetap membekas pada saya adalah yang lebih kecil: BTC saya sendiri yang saat ini terkunci tidak pernah dilindungi oleh skill atau timing yang baik. Ia melewati garis yang digambar oleh para penambang, bukan oleh saya, dan lain kali garis itu digambar, ia tetap akan demikian.
$SKYAI $BICO $BABY
"Apakah risiko overflow ini akan menghentikan Anda untuk melakukan staking di ronde capped di masa depan?" 🎯
Saya saat ini mempertaruhkan BTC melalui Babylon, jadi ketika saya menemukan kata "overflow" yang terkubur dalam dokumentasi lama Cap-3 semalam, saya tidak membacanya sebagai sejarah. Saya membacanya sebagai pertanyaan tentang posisi saya sendiri: apakah ini bisa terjadi pada saya.
Selama Fase 1, transaksi staking yang konfirmasinya terjadi setelah cap sudah terisi tetap mengunci BTC ke dalam kontrak persis seperti yang dilakukan semua orang. Mereka hanya tidak mendapatkan apa pun—tidak ada poin, tidak ada alokasi. Pengembalian koinnya pun tidak otomatis; dokumennya jelas: overflow stakes masih harus di-unbond dan ditarik, dengan waktu tunggu yang sama seperti posisi aktif, untuk stake yang membayar nol selama seluruh koin terkunci.
Yang menentukan siapa yang berhasil masuk bukanlah saat siapa pun menekan tombol stake. Itu adalah blok Bitcoin mana transaksi tersebut benar-benar terkonfirmasi, sebuah angka yang tidak sepenuhnya bisa dikendalikan siapa pun begitu keluar dari dompet. Dua orang bisa menyiarkan (broadcast) beberapa menit terpisah dan tetap mendarat dalam urutan yang berbeda tergantung biaya, kemacetan mempool, atau penambang mana yang menemukan blok berikutnya lebih dulu.
Limit Fase 1 sudah hilang, tetapi mekanisme yang menciptakan overflow tidak unik untuk fase itu. Setiap ronde yang dibatasi di masa depan—onboarding BSN baru dengan alokasi tetap, integrasi slot terbatas—mewarisi kondisi perlombaan yang sama begitu menggunakan konfirmasi blok alih-alih antrean. Tidak ada yang ditambal dari kekurangan desain itu. Itu hanya menjadi ketinggalan ketika cap menghilang.
Saya tidak yakin desain aslinya tidak adil; cap yang ketat memang perlu ada batas pemotongan, dan konfirmasi blok tidak bisa dipalsukan seperti timestamp. Yang tetap membekas pada saya adalah yang lebih kecil: BTC saya sendiri yang saat ini terkunci tidak pernah dilindungi oleh skill atau timing yang baik. Ia melewati garis yang digambar oleh para penambang, bukan oleh saya, dan lain kali garis itu digambar, ia tetap akan demikian.
$SKYAI $BICO $BABY
"Apakah risiko overflow ini akan menghentikan Anda untuk melakukan staking di ronde capped di masa depan?" 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 Voting • Voting ditutup
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Aku mengunci rasio co-staking-ku tiga minggu lalu—20.000 BABY per BTC, rasio rekomendasi bawaan Babylon. Tadi malam aku mengecek reward-ku. Lebih rendah dari angka yang kubayangkan saat aku stake.
Posisiku tidak bergeser satu inci pun. Yang berubah adalah yang lain.
Boost co-staking 2,35% itu bukan “rate”. Itu kumpulan berukuran tetap, dibagi secara proporsional ke setiap wallet yang co-staking saat itu juga. Babylon menjelaskannya dengan gamblang di dokumen mereka sendiri: semakin banyak co-staker, reward individual semakin kecil. Kalau kamu mencapai rasionya dengan tepat, bagianmu yang sebenarnya tetap bergantung pada berapa banyak wallet lain yang juga mencapainya—angka yang bisa berubah tanpa kamu menyentuh posisi kamu.
Tidak ada dashboard yang melacak angka itu secara real time. Kamu bisa melihat bobotmu sendiri. Kamu tidak bisa melihat bobot total pool yang berubah di bawahnya.
Berbeda dari risiko Babylon lain yang bersembunyi di balik infrastruktur yang hilang atau operator yang terkonsentrasi, yang ini tersembunyi dengan terang—rumusnya sepenuhnya publik. Yang tidak ada cuma satu: siapa lagi yang memakainya.
Satu hal yang patut diawasi: 2,35% itu bukan fondasi permanen, melainkan angka tata kelola (governance). Angka itu hanya ada karena proposal bulan September lalu memotong inflasi Babylon menjadi irisan tetap: 1% untuk staker BTC, 2% untuk staker BABY, 2,35% untuk co-staker, sisanya dibagi ke tempat lain. Pemungutan suara di masa depan bisa mengubah ukuran irisan itu dengan cara yang sama seperti saat ini irisan itu diciptakan. Belum ada yang mengusulkan untuk mengecilkannya, jadi ini adalah kursi yang sedang kamu pantau—bukan meja yang dijamin akan kamu pegang.
Ada “sisi” kedua yang dibangun ke dalam rumusnya. Batas bobot yang memenuhi syarat akan mengikuti yang lebih kecil di antara: BABY kamu dibagi 20.000, atau BTC kamu. Kalau kamu melebihi rasio, tambahan BABY hanya menghasilkan imbal hasil staking biasa. Kalau kamu kurang, hanya sebagian dari BTC kamu yang mendapatkan boost.
Menggabungkan BTC dan BABY dibangun untuk memperkuat ikatan itu, dan pool bersama adalah cara yang masuk akal untuk mendanainya. Desainnya bukan masalah. Ketidakmampuan untuk melihat perubahan bagianmu sebelum itu terjadi—itulah masalahnya.
Kalau kamu sudah mencapai rasio persis seperti yang kulakukan, kamu tidak mendapatkan 2,35% yang tetap. Kamu sedang menyewa sebuah kursi di meja yang menjadi makin ramai sesuai jadwalnya sendiri, oleh orang-orang yang tidak akan pernah kamu lihat saat mereka datang.
Aku mengunci rasio co-staking-ku tiga minggu lalu—20.000 BABY per BTC, rasio rekomendasi bawaan Babylon. Tadi malam aku mengecek reward-ku. Lebih rendah dari angka yang kubayangkan saat aku stake.
Posisiku tidak bergeser satu inci pun. Yang berubah adalah yang lain.
Boost co-staking 2,35% itu bukan “rate”. Itu kumpulan berukuran tetap, dibagi secara proporsional ke setiap wallet yang co-staking saat itu juga. Babylon menjelaskannya dengan gamblang di dokumen mereka sendiri: semakin banyak co-staker, reward individual semakin kecil. Kalau kamu mencapai rasionya dengan tepat, bagianmu yang sebenarnya tetap bergantung pada berapa banyak wallet lain yang juga mencapainya—angka yang bisa berubah tanpa kamu menyentuh posisi kamu.
Tidak ada dashboard yang melacak angka itu secara real time. Kamu bisa melihat bobotmu sendiri. Kamu tidak bisa melihat bobot total pool yang berubah di bawahnya.
Berbeda dari risiko Babylon lain yang bersembunyi di balik infrastruktur yang hilang atau operator yang terkonsentrasi, yang ini tersembunyi dengan terang—rumusnya sepenuhnya publik. Yang tidak ada cuma satu: siapa lagi yang memakainya.
Satu hal yang patut diawasi: 2,35% itu bukan fondasi permanen, melainkan angka tata kelola (governance). Angka itu hanya ada karena proposal bulan September lalu memotong inflasi Babylon menjadi irisan tetap: 1% untuk staker BTC, 2% untuk staker BABY, 2,35% untuk co-staker, sisanya dibagi ke tempat lain. Pemungutan suara di masa depan bisa mengubah ukuran irisan itu dengan cara yang sama seperti saat ini irisan itu diciptakan. Belum ada yang mengusulkan untuk mengecilkannya, jadi ini adalah kursi yang sedang kamu pantau—bukan meja yang dijamin akan kamu pegang.
Ada “sisi” kedua yang dibangun ke dalam rumusnya. Batas bobot yang memenuhi syarat akan mengikuti yang lebih kecil di antara: BABY kamu dibagi 20.000, atau BTC kamu. Kalau kamu melebihi rasio, tambahan BABY hanya menghasilkan imbal hasil staking biasa. Kalau kamu kurang, hanya sebagian dari BTC kamu yang mendapatkan boost.
Menggabungkan BTC dan BABY dibangun untuk memperkuat ikatan itu, dan pool bersama adalah cara yang masuk akal untuk mendanainya. Desainnya bukan masalah. Ketidakmampuan untuk melihat perubahan bagianmu sebelum itu terjadi—itulah masalahnya.
Kalau kamu sudah mencapai rasio persis seperti yang kulakukan, kamu tidak mendapatkan 2,35% yang tetap. Kamu sedang menyewa sebuah kursi di meja yang menjadi makin ramai sesuai jadwalnya sendiri, oleh orang-orang yang tidak akan pernah kamu lihat saat mereka datang.
#baby $BABY @BabylonLabs_io
Separuh BTC saya saat ini dipertaruhkan melalui Babylon. Saya tidak pernah bertanya apa yang terjadi padanya jika separuh kumpulan validator mati sekaligus — sampai tadi malam, ketika saya membaca setengah dari makalah pendirian Babylon yang dulu saya lewatkan.
Checkpointing Bitcoin memperbaiki keamanan. Satu validator yang jujur mengirimkan bukti ke Bitcoin sudah cukup untuk menjatuhkan para pembohong dan menetapkan riwayat mana yang benar. Liveness adalah pertanyaan terpisah: apakah rantai terus menghasilkan blok sama sekali.
Ini bagian yang tidak bisa disentuh Bitcoin. Tidak ada protokol proof-of-stake yang menjamin liveness begitu validator yang bersifat adversarial melewati setengah dari kumpulan aktif. Tidak dengan Bitcoin di belakangnya, tidak dengan layanan timestamping apa pun — kecuali jika data setiap validator diposting di-chain, dan throughput Bitcoin tidak pernah dibangun untuk menampung itu.
Buktinya tetap berlaku terhadap niat jahat. Ia tidak mengatakan apa pun tentang validator yang hanya berhenti muncul. Rantai akan macet persis sama, apa pun alasannya, dan Bitcoin tidak bisa memberi tahu Anda yang mana yang terjadi.
"Diamankan oleh Bitcoin" terdengar seperti satu jaminan. Itu dua. Bitcoin memberi kepastian tentang riwayat mana yang benar. Ia tidak membeli janji bahwa rantai akan terus bergerak jika separuh validator menghilang sekaligus — pemadaman, keluar, atau serangan yang tidak sempat terdeteksi.
Sebuah komite yang butuh satu penanda tangan yang jujur, seorang relayer yang butuh satu agar tetap online — itu semua bisa diperbaiki dengan lebih banyak operator yang hadir. Batas ini adalah matematika yang terbukti, bukan masalah ketersediaan staf. Menonton lebih keras tidak akan mengubahnya.
BTC saya terkunci dalam kondisi apa pun. Bitcoin akan memberi saya tanda terima untuk momen tepat ketika rantai itu mati. Membuatnya kembali bernapas bukan bagian dari bukti.
$BLESS $HOME
Jika separuh validator Babylon mati gelap malam ini, apa yang terjadi pada BTC Anda?
Separuh BTC saya saat ini dipertaruhkan melalui Babylon. Saya tidak pernah bertanya apa yang terjadi padanya jika separuh kumpulan validator mati sekaligus — sampai tadi malam, ketika saya membaca setengah dari makalah pendirian Babylon yang dulu saya lewatkan.
Checkpointing Bitcoin memperbaiki keamanan. Satu validator yang jujur mengirimkan bukti ke Bitcoin sudah cukup untuk menjatuhkan para pembohong dan menetapkan riwayat mana yang benar. Liveness adalah pertanyaan terpisah: apakah rantai terus menghasilkan blok sama sekali.
Ini bagian yang tidak bisa disentuh Bitcoin. Tidak ada protokol proof-of-stake yang menjamin liveness begitu validator yang bersifat adversarial melewati setengah dari kumpulan aktif. Tidak dengan Bitcoin di belakangnya, tidak dengan layanan timestamping apa pun — kecuali jika data setiap validator diposting di-chain, dan throughput Bitcoin tidak pernah dibangun untuk menampung itu.
Buktinya tetap berlaku terhadap niat jahat. Ia tidak mengatakan apa pun tentang validator yang hanya berhenti muncul. Rantai akan macet persis sama, apa pun alasannya, dan Bitcoin tidak bisa memberi tahu Anda yang mana yang terjadi.
"Diamankan oleh Bitcoin" terdengar seperti satu jaminan. Itu dua. Bitcoin memberi kepastian tentang riwayat mana yang benar. Ia tidak membeli janji bahwa rantai akan terus bergerak jika separuh validator menghilang sekaligus — pemadaman, keluar, atau serangan yang tidak sempat terdeteksi.
Sebuah komite yang butuh satu penanda tangan yang jujur, seorang relayer yang butuh satu agar tetap online — itu semua bisa diperbaiki dengan lebih banyak operator yang hadir. Batas ini adalah matematika yang terbukti, bukan masalah ketersediaan staf. Menonton lebih keras tidak akan mengubahnya.
BTC saya terkunci dalam kondisi apa pun. Bitcoin akan memberi saya tanda terima untuk momen tepat ketika rantai itu mati. Membuatnya kembali bernapas bukan bagian dari bukti.
$BLESS $HOME
Jika separuh validator Babylon mati gelap malam ini, apa yang terjadi pada BTC Anda?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 Voting • Voting ditutup
Terverifikasi
@BabylonLabs_io $BABY #baby
Setiap kali Anda melepas pengikatan (unbond) BTC dari Babylon, ada sembilan kunci yang berada di antara Bitcoin Anda dan dompet Anda. Enam di antaranya harus menyetujui sebelum dana Anda bisa kembali.
Salah satu dari sembilan kunci itu milik Babylon Labs.
Pernyataannya adalah "trustless": tanpa kustodian, tanpa perusahaan yang memegang BTC Anda—hanya Bitcoin Script yang menegakkan aturan. Dan itu nyata—tidak ada satu kunci pun yang bisa menyentuh dana Anda sendirian. Namun, unbonding adalah satu-satunya pintu kembali ke koin Anda sebelum batas waktu timelock 15 bulan berakhir, dan tim yang membangun pintu itu juga memegang salah satu kuncinya untuk membukanya.
Itu bukan skandal. Delapan kunci lainnya berada pada entitas bernama dan bereputasi, dan komite hanya bisa menyetujui atau menolak transaksi standar—sistem ini tidak pernah dibuat agar bisa kabur dengan BTC siapa pun. Meski begitu, baca dokumentasi resmi Babylon dengan cukup saksama dan Anda akan menemukan bahwa pembuatnya tercantum sebagai penandatangan (signer) pada sistem yang ia bangun, sehingga sistem itu tidak perlu signers.
Tanyakan kepada staker Babylon mengapa mereka memindahkan BTC ke dalam protokol, dan "trustless" biasanya kata pertama yang keluar dari mulut mereka. Tanyakan siapa yang memegang kunci nomor satu, dan kebanyakan tidak akan tahu jawabannya adalah Babylon Labs.
$IDOL
Apakah fakta bahwa pembuat memegang salah satu kunci unbonding mengubah cara Anda memandang "trustless"?
Setiap kali Anda melepas pengikatan (unbond) BTC dari Babylon, ada sembilan kunci yang berada di antara Bitcoin Anda dan dompet Anda. Enam di antaranya harus menyetujui sebelum dana Anda bisa kembali.
Salah satu dari sembilan kunci itu milik Babylon Labs.
Pernyataannya adalah "trustless": tanpa kustodian, tanpa perusahaan yang memegang BTC Anda—hanya Bitcoin Script yang menegakkan aturan. Dan itu nyata—tidak ada satu kunci pun yang bisa menyentuh dana Anda sendirian. Namun, unbonding adalah satu-satunya pintu kembali ke koin Anda sebelum batas waktu timelock 15 bulan berakhir, dan tim yang membangun pintu itu juga memegang salah satu kuncinya untuk membukanya.
Itu bukan skandal. Delapan kunci lainnya berada pada entitas bernama dan bereputasi, dan komite hanya bisa menyetujui atau menolak transaksi standar—sistem ini tidak pernah dibuat agar bisa kabur dengan BTC siapa pun. Meski begitu, baca dokumentasi resmi Babylon dengan cukup saksama dan Anda akan menemukan bahwa pembuatnya tercantum sebagai penandatangan (signer) pada sistem yang ia bangun, sehingga sistem itu tidak perlu signers.
Tanyakan kepada staker Babylon mengapa mereka memindahkan BTC ke dalam protokol, dan "trustless" biasanya kata pertama yang keluar dari mulut mereka. Tanyakan siapa yang memegang kunci nomor satu, dan kebanyakan tidak akan tahu jawabannya adalah Babylon Labs.
$IDOL
Apakah fakta bahwa pembuat memegang salah satu kunci unbonding mengubah cara Anda memandang "trustless"?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 Voting • Voting ditutup
Pukul 2 pagi, masih terjaga, membaca dokumen checkpointing milik Babylon tanpa alasan apa pun selain karena aku tidak bisa tidur. Satu baris menghentikan scroll-ku: satu orang vigilante yang jujur dan hidup di seluruh jaringan sudah cukup untuk menjamin checkpoint yang berhasil dan aman ke Bitcoin.
Baca cepat—itu terdengar seperti desentralisasi menjalankan tugasnya. Puluhan operator independen, hanya satu yang perlu berperilaku.
Aku kembali ke paper akademik Babylon tahun 2022, yang ikut ditulis oleh para pendirinya—yang membuktikan klaim ini sebagai teorema formal, bukan sekadar kalimat pemasaran. Buktinya berlaku dengan satu syarat: ada satu validator yang jujur aktif setiap saat. Paper itu menyatakannya dengan gamblang.
Tapi ini yang tidak dijelaskannya. “Satu itu cukup secara matematis” dan “satu itu sedang online” adalah dua jaminan yang berbeda. Hanya yang pertama yang datang dengan bukti yang menempel.
Lalu kalimat yang sama muncul lagi, kali ini berdampingan dengan covenant emulator dan IBC relayer, yang dinamai sebagai program terpisah: operasi yang aman memerlukan setidaknya satu operator yang jujur untuk masing-masing program yang tercantum, atau sistem akan membunyikan alarm. Aku tidak yakin apakah itu mencakup ketiganya secara setara, atau apakah penulisannya memang hanya memikirkan rangkaian vigilante. Bagaimanapun, jumlah personelnya tidak dipublikasikan.
Babylon menyebutnya sukarela—siapa pun bisa menjalankan satu. Benar, tapi itu tetap tidak menyebutkan berapa banyak yang saat ini menjalankannya, atau apakah jumlah itu bertahan selama lonjakan biaya transaksi Bitcoin yang tidak ingin siapa pun menanggungnya.
Ada alasan kenapa tidak ada yang mempublikasikan angka itu. Mengungkap betapa tipisnya bantalan (buffer) akan membantu penyerang lebih banyak daripada membantu kamu.
Kalau kamu sedang melakukan staking lewat Babylon sekarang, ini adalah asumsi yang menopang BTC-mu dan tidak pernah ditampilkan oleh dasbor mana pun: bukan apakah matematikanya bekerja, melainkan apakah ada seseorang yang benar-benar terjaga untuk menjalankannya, malam ini, dan setiap malam setelahnya.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Apakah kamu mau melakukan staking jika jumlah “satu operator yang jujur” tidak diketahui? 👀
Baca cepat—itu terdengar seperti desentralisasi menjalankan tugasnya. Puluhan operator independen, hanya satu yang perlu berperilaku.
Aku kembali ke paper akademik Babylon tahun 2022, yang ikut ditulis oleh para pendirinya—yang membuktikan klaim ini sebagai teorema formal, bukan sekadar kalimat pemasaran. Buktinya berlaku dengan satu syarat: ada satu validator yang jujur aktif setiap saat. Paper itu menyatakannya dengan gamblang.
Tapi ini yang tidak dijelaskannya. “Satu itu cukup secara matematis” dan “satu itu sedang online” adalah dua jaminan yang berbeda. Hanya yang pertama yang datang dengan bukti yang menempel.
Lalu kalimat yang sama muncul lagi, kali ini berdampingan dengan covenant emulator dan IBC relayer, yang dinamai sebagai program terpisah: operasi yang aman memerlukan setidaknya satu operator yang jujur untuk masing-masing program yang tercantum, atau sistem akan membunyikan alarm. Aku tidak yakin apakah itu mencakup ketiganya secara setara, atau apakah penulisannya memang hanya memikirkan rangkaian vigilante. Bagaimanapun, jumlah personelnya tidak dipublikasikan.
Babylon menyebutnya sukarela—siapa pun bisa menjalankan satu. Benar, tapi itu tetap tidak menyebutkan berapa banyak yang saat ini menjalankannya, atau apakah jumlah itu bertahan selama lonjakan biaya transaksi Bitcoin yang tidak ingin siapa pun menanggungnya.
Ada alasan kenapa tidak ada yang mempublikasikan angka itu. Mengungkap betapa tipisnya bantalan (buffer) akan membantu penyerang lebih banyak daripada membantu kamu.
Kalau kamu sedang melakukan staking lewat Babylon sekarang, ini adalah asumsi yang menopang BTC-mu dan tidak pernah ditampilkan oleh dasbor mana pun: bukan apakah matematikanya bekerja, melainkan apakah ada seseorang yang benar-benar terjaga untuk menjalankannya, malam ini, dan setiap malam setelahnya.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Apakah kamu mau melakukan staking jika jumlah “satu operator yang jujur” tidak diketahui? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 Voting • Voting ditutup
Terverifikasi
Lihat terjemahan
#baby $BABY @BabylonLabs_io
I used to think slashing was Babylon's way of punishing dishonesty. That changed at 2am scrolling through an independent security audit of the EOTS implementation, the kind of document nobody opens without a reason.
The mechanism is elegant on its own terms. A finality provider commits to a piece of randomness before signing any block at a given height. Sign it once, nothing happens. Sign it twice, with two different messages, and the math behind Schnorr signatures turns that same randomness into the provider's exposed private key. Intentional double-signing becomes self-punishing by construction, and there's a reason for that: a protocol can only read signatures, not intent, so a rule strict enough to catch an attacker can't tell an attacker from an accident.
That tradeoff is what the audit flagged. A deliberate attack and an honest backup-node failover firing at the same height produce the exact same signature pattern. Both look identical to EOTS. Both get slashed the same way, tombstoned, no reinstatement.
That's not theoretical. Hex Trust, an institutional custodian running finality provider infrastructure on Babylon, lists specific safeguards against exactly this: no private key reuse across machines, manual failover instead of automatic, because automatic failover is exactly what can produce two live signers for one key at once.
Here's the part with no clean answer. There's no public disclosure standard for which failover setup a provider runs. You can check commission, uptime, delegator count. Not this, not before your BTC is already locked.
Delegating was never just a bet that the operator wouldn't attack you. It's also a bet their infrastructure never has a bad day for as long as your BTC is locked, on a detail the protocol makes unknowable in advance .
$KOMA
I used to think slashing was Babylon's way of punishing dishonesty. That changed at 2am scrolling through an independent security audit of the EOTS implementation, the kind of document nobody opens without a reason.
The mechanism is elegant on its own terms. A finality provider commits to a piece of randomness before signing any block at a given height. Sign it once, nothing happens. Sign it twice, with two different messages, and the math behind Schnorr signatures turns that same randomness into the provider's exposed private key. Intentional double-signing becomes self-punishing by construction, and there's a reason for that: a protocol can only read signatures, not intent, so a rule strict enough to catch an attacker can't tell an attacker from an accident.
That tradeoff is what the audit flagged. A deliberate attack and an honest backup-node failover firing at the same height produce the exact same signature pattern. Both look identical to EOTS. Both get slashed the same way, tombstoned, no reinstatement.
That's not theoretical. Hex Trust, an institutional custodian running finality provider infrastructure on Babylon, lists specific safeguards against exactly this: no private key reuse across machines, manual failover instead of automatic, because automatic failover is exactly what can produce two live signers for one key at once.
Here's the part with no clean answer. There's no public disclosure standard for which failover setup a provider runs. You can check commission, uptime, delegator count. Not this, not before your BTC is already locked.
Delegating was never just a bet that the operator wouldn't attack you. It's also a bet their infrastructure never has a bad day for as long as your BTC is locked, on a detail the protocol makes unknowable in advance .
$KOMA
Terverifikasi
$BABY $UAI $COTI #baby @BabylonLabs_io
Awalnya saya mengira komite perjanjian itu hanyalah langkah bootstrap—sesuatu yang akan disingkirkan Babylon begitu roadmap mereka sendiri matang, sama seperti kebanyakan protokol muda yang berjanji untuk desentralisasi sesuai jadwal mereka. Namun dokumentasinya mengatakan sesuatu yang lebih senyap dan lebih aneh dari itu.
Komite ini ada karena Bitcoin sendiri tidak punya cara bawaan untuk menegakkan covenant, tidak ada opcode yang bisa memaksa sebuah UTXO untuk dibelanjakan hanya melalui aturan yang sudah disepakati sebelumnya. Jadi Babylon membangun multisig 6-dari-9 untuk meniru fungsi yang hilang tersebut: memantau permintaan staking, menandatangani unbonding dan slashing, berdiri sebagai kemampuan yang belum dimiliki Bitcoin Script. Bagian itu adalah rekayasa yang jujur untuk mengatasi celah nyata, dan asumsi kepercayaannya benar-benar lebih ringan daripada multisig kustodian biasa—kejujuran yang bersifat eksistensial alih-alih kejujuran mayoritas; cukup satu penandatangan yang jujur untuk menghentikan pencurian.
Yang menghentikan saya adalah kondisi keluarnya. Dokumentasi Babylon sendiri tidak mengatakan komitenya berhenti ketika tata kelola sudah matang, atau ketika ambang batas TVL tertentu tercapai, atau ketika ada tonggak internal tertentu yang dirilis. Dokumentasi tersebut menyebut komite tetap ada sampai fungsi covenant tersedia secara native di Bitcoin, melalui opcode seperti OP-CAT atau OP-CTV—opcode yang belum diadopsi Bitcoin Core dan tidak memiliki jadwal adopsi yang benar-benar pasti. Tanggal pensiunnya tidak ada di roadmap Babylon. Itu berada di proses tata kelola protokol lain, yang tidak punya suara bagi Babylon dan tidak bisa dipercepat.
Jadi kepercayaan itu tidak hilang ketika Babylon menyebutnya sebagai sistem yang diamankan oleh Bitcoin. Kepercayaan itu hanya berpindah satu lapis lebih jauh—keluar dari sebuah multisig dengan keanggotaan yang didefinisikan, lalu menuju sebuah soft fork Bitcoin yang mungkin atau mungkin tidak akan dirilis pada dekade ini. Enam dari sembilan penandatangan yang diketahui adalah setidaknya sebuah asumsi kepercayaan yang bisa Anda sebutkan. Upgrade opcode yang masih menunggu tanpa tenggat waktu adalah asumsi kepercayaan yang hanya bisa Anda tunggu.
Komite covenant tetap ada sampai Bitcoin menambahkan opcode covenant. Tidak ada timeline Babylon yang mengendalikannya.
Pendapat Anda? 👀
Awalnya saya mengira komite perjanjian itu hanyalah langkah bootstrap—sesuatu yang akan disingkirkan Babylon begitu roadmap mereka sendiri matang, sama seperti kebanyakan protokol muda yang berjanji untuk desentralisasi sesuai jadwal mereka. Namun dokumentasinya mengatakan sesuatu yang lebih senyap dan lebih aneh dari itu.
Komite ini ada karena Bitcoin sendiri tidak punya cara bawaan untuk menegakkan covenant, tidak ada opcode yang bisa memaksa sebuah UTXO untuk dibelanjakan hanya melalui aturan yang sudah disepakati sebelumnya. Jadi Babylon membangun multisig 6-dari-9 untuk meniru fungsi yang hilang tersebut: memantau permintaan staking, menandatangani unbonding dan slashing, berdiri sebagai kemampuan yang belum dimiliki Bitcoin Script. Bagian itu adalah rekayasa yang jujur untuk mengatasi celah nyata, dan asumsi kepercayaannya benar-benar lebih ringan daripada multisig kustodian biasa—kejujuran yang bersifat eksistensial alih-alih kejujuran mayoritas; cukup satu penandatangan yang jujur untuk menghentikan pencurian.
Yang menghentikan saya adalah kondisi keluarnya. Dokumentasi Babylon sendiri tidak mengatakan komitenya berhenti ketika tata kelola sudah matang, atau ketika ambang batas TVL tertentu tercapai, atau ketika ada tonggak internal tertentu yang dirilis. Dokumentasi tersebut menyebut komite tetap ada sampai fungsi covenant tersedia secara native di Bitcoin, melalui opcode seperti OP-CAT atau OP-CTV—opcode yang belum diadopsi Bitcoin Core dan tidak memiliki jadwal adopsi yang benar-benar pasti. Tanggal pensiunnya tidak ada di roadmap Babylon. Itu berada di proses tata kelola protokol lain, yang tidak punya suara bagi Babylon dan tidak bisa dipercepat.
Jadi kepercayaan itu tidak hilang ketika Babylon menyebutnya sebagai sistem yang diamankan oleh Bitcoin. Kepercayaan itu hanya berpindah satu lapis lebih jauh—keluar dari sebuah multisig dengan keanggotaan yang didefinisikan, lalu menuju sebuah soft fork Bitcoin yang mungkin atau mungkin tidak akan dirilis pada dekade ini. Enam dari sembilan penandatangan yang diketahui adalah setidaknya sebuah asumsi kepercayaan yang bisa Anda sebutkan. Upgrade opcode yang masih menunggu tanpa tenggat waktu adalah asumsi kepercayaan yang hanya bisa Anda tunggu.
Komite covenant tetap ada sampai Bitcoin menambahkan opcode covenant. Tidak ada timeline Babylon yang mengendalikannya.
Pendapat Anda? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 Voting • Voting ditutup
Saat memilih penyedia finalitas minggu lalu, saya menatap daftar sekitar 30 nama yang sudah terverifikasi, lalu saya sadar diri sedang hampir mengklik yang sudah memiliki delegator paling banyak. Refleks yang sama yang mengubah sebagian besar staking Ethereum menjadi cerita tentang Lido.
Lalu saya benar-benar membaca panduan staking milik Babylon.
Di sana risikonya disebut langsung: mendelegasikan ke penyedia yang paling populer meningkatkan risiko sentralisasi. Bukan pengamatan seorang pengkritik—dokumentasi mereka sendiri yang mengatakan itu.
➡ Sekitar 30 penyedia memiliki tanda centang terverifikasi di dalam aplikasi.
➡ Tidak ada apa pun dalam daftar itu yang membatasi seberapa banyak delegasi yang bisa diserap oleh satu penyedia.
Berikan kredit ke Babylon karena berani menyatakannya secara terbuka; kebanyakan produk staking tidak pernah memberi peringatan kepada pengguna akhir sebelum mereka mengklik.
Inilah yang paling melekat pada saya. Tanda centang itu ada untuk membangun kepercayaan. Tapi jika sebagian besar staker default ke nama terverifikasi yang sudah memiliki delegator terbanyak—pola persis yang Ethereum jalani—hal yang dimaksud untuk membangun kepercayaan justru menjadi mekanisme yang memusatkan risiko yang mereka peringatkan.
Saya mencari angka-angka pembagian delegasi yang benar-benar ada: seberapa besar kendali gabungan dari 5 atau 10 penyedia finalitas teratas. Tidak ada yang publik. Tulisan salah satu bursa kripto tentang protokol itu menyebutnya "masih memerlukan diskusi lebih lanjut", sebuah masalah terbuka yang ditandai oleh sumber di luar sana—bukan sesuatu yang Babylon sendiri pernah bahas secara tertulis.
Saya membagi delegasi saya ke tiga penyedia yang lebih kecil, bukan ke satu penyedia besar. Di skala seperti ini, mungkin lebih dekat ke gestur simbolis daripada perbaikan yang benar-benar efektif, dan saya tahu itu.
@BabylonLabs_io $BABY #baby $ON
"Apakah Anda akan mendelegasikan ke penyedia finalitas yang lebih kecil dengan sengaja?"
Lalu saya benar-benar membaca panduan staking milik Babylon.
Di sana risikonya disebut langsung: mendelegasikan ke penyedia yang paling populer meningkatkan risiko sentralisasi. Bukan pengamatan seorang pengkritik—dokumentasi mereka sendiri yang mengatakan itu.
➡ Sekitar 30 penyedia memiliki tanda centang terverifikasi di dalam aplikasi.
➡ Tidak ada apa pun dalam daftar itu yang membatasi seberapa banyak delegasi yang bisa diserap oleh satu penyedia.
Berikan kredit ke Babylon karena berani menyatakannya secara terbuka; kebanyakan produk staking tidak pernah memberi peringatan kepada pengguna akhir sebelum mereka mengklik.
Inilah yang paling melekat pada saya. Tanda centang itu ada untuk membangun kepercayaan. Tapi jika sebagian besar staker default ke nama terverifikasi yang sudah memiliki delegator terbanyak—pola persis yang Ethereum jalani—hal yang dimaksud untuk membangun kepercayaan justru menjadi mekanisme yang memusatkan risiko yang mereka peringatkan.
Saya mencari angka-angka pembagian delegasi yang benar-benar ada: seberapa besar kendali gabungan dari 5 atau 10 penyedia finalitas teratas. Tidak ada yang publik. Tulisan salah satu bursa kripto tentang protokol itu menyebutnya "masih memerlukan diskusi lebih lanjut", sebuah masalah terbuka yang ditandai oleh sumber di luar sana—bukan sesuatu yang Babylon sendiri pernah bahas secara tertulis.
Saya membagi delegasi saya ke tiga penyedia yang lebih kecil, bukan ke satu penyedia besar. Di skala seperti ini, mungkin lebih dekat ke gestur simbolis daripada perbaikan yang benar-benar efektif, dan saya tahu itu.
@BabylonLabs_io $BABY #baby $ON
"Apakah Anda akan mendelegasikan ke penyedia finalitas yang lebih kecil dengan sengaja?"
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 Voting • Voting ditutup
#baby @BabylonLabs_io
Hampir sempat menaruh sejumlah kecil BTC ke posisi pinjaman yang didukung brankas (vault) minggu lalu. Sebelum aku melakukannya, aku ingin tahu satu hal: kalau pasar bergerak cepat melawanku, apa sebenarnya yang menentukan kapan aku dilikuidasi? Pertanyaan itulah yang membuatku menelusuri situsnya Babylon sendiri—ke tempat istilah “trustless” berhenti berlaku. Itu tidak terkubur. Hanya saja, istilah itu tidak bertahan jika diterjemahkan ke dalam setiap judul yang dibangun di sekitar satu kata itu. ➡ Halaman Learn milik Babylon menjelaskan dengan gamblang bahwa risiko sebenarnya berada di sisi DeFi, bukan di dalam vault itu sendiri, dan memberikan likuidasi dalam pinjaman sebagai contohnya. ➡ Whitepaper turut menguatkannya: likuidasi memerlukan tanda tangan (signature) dari sebuah price oracle, yang diperlakukan sebagai ketergantungan terpisah dari desain inti vault. Beri kredit untuk Babylon—mereka menuliskannya sendiri. Tidak ada yang perlu menggali dari mereka. Inilah bagian yang paling melekat padaku, bagian yang benar-benar mengubah seberapa banyak aku hendak menyetor. “A price oracle” terdengar abstrak, sampai satu laporan tentang sistem yang persis ini menyebut jaringan mana saja yang benar-benar memegang hubungan tersebut dengan Babylon: Band Protocol dan Pyth, jaringan berfungsi umum yang sekaligus memberi harga untuk puluhan chain lainnya. Materi milik Babylon tidak menyebutkannya secara langsung, jadi anggap pasangan spesifik itu sebagai yang dilaporkan, bukan dikonfirmasi oleh Babylon sendiri. Jika salah satu feed tersebut terlambat atau salah saat pergerakan cepat, likuidasiku tetap terjadi persis seperti yang dikodekan. Bertindak berdasarkan informasi yang buruk. Lapisan dasar Bitcoin tidak ikut menentukan hasil itu. Vault hanya melakukan apa yang dijanjikannya. Oracle hanya memberinya sesuatu yang salah. Itu bukan kegagalan pada vault. Itu risiko DeFi, memakai label “trustless”, dan mewarisi riwayat gangguan (outage) yang memang sudah dibawa oleh price feed-nya dari chain lain yang bahkan tidak kupakai. Aku tetap menyetor. Hanya saja lebih kecil daripada yang akan kulakukan satu jam sebelumnya. Trustless menjelaskan apa yang terjadi pada BTC-mu. Itu tidak pernah menjadi janji tentang apa yang terjadi pada uangmu setelah keluar dari vault.
$BROCCOLIF3B $ON $BABY
Hampir sempat menaruh sejumlah kecil BTC ke posisi pinjaman yang didukung brankas (vault) minggu lalu. Sebelum aku melakukannya, aku ingin tahu satu hal: kalau pasar bergerak cepat melawanku, apa sebenarnya yang menentukan kapan aku dilikuidasi? Pertanyaan itulah yang membuatku menelusuri situsnya Babylon sendiri—ke tempat istilah “trustless” berhenti berlaku. Itu tidak terkubur. Hanya saja, istilah itu tidak bertahan jika diterjemahkan ke dalam setiap judul yang dibangun di sekitar satu kata itu. ➡ Halaman Learn milik Babylon menjelaskan dengan gamblang bahwa risiko sebenarnya berada di sisi DeFi, bukan di dalam vault itu sendiri, dan memberikan likuidasi dalam pinjaman sebagai contohnya. ➡ Whitepaper turut menguatkannya: likuidasi memerlukan tanda tangan (signature) dari sebuah price oracle, yang diperlakukan sebagai ketergantungan terpisah dari desain inti vault. Beri kredit untuk Babylon—mereka menuliskannya sendiri. Tidak ada yang perlu menggali dari mereka. Inilah bagian yang paling melekat padaku, bagian yang benar-benar mengubah seberapa banyak aku hendak menyetor. “A price oracle” terdengar abstrak, sampai satu laporan tentang sistem yang persis ini menyebut jaringan mana saja yang benar-benar memegang hubungan tersebut dengan Babylon: Band Protocol dan Pyth, jaringan berfungsi umum yang sekaligus memberi harga untuk puluhan chain lainnya. Materi milik Babylon tidak menyebutkannya secara langsung, jadi anggap pasangan spesifik itu sebagai yang dilaporkan, bukan dikonfirmasi oleh Babylon sendiri. Jika salah satu feed tersebut terlambat atau salah saat pergerakan cepat, likuidasiku tetap terjadi persis seperti yang dikodekan. Bertindak berdasarkan informasi yang buruk. Lapisan dasar Bitcoin tidak ikut menentukan hasil itu. Vault hanya melakukan apa yang dijanjikannya. Oracle hanya memberinya sesuatu yang salah. Itu bukan kegagalan pada vault. Itu risiko DeFi, memakai label “trustless”, dan mewarisi riwayat gangguan (outage) yang memang sudah dibawa oleh price feed-nya dari chain lain yang bahkan tidak kupakai. Aku tetap menyetor. Hanya saja lebih kecil daripada yang akan kulakukan satu jam sebelumnya. Trustless menjelaskan apa yang terjadi pada BTC-mu. Itu tidak pernah menjadi janji tentang apa yang terjadi pada uangmu setelah keluar dari vault.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 Voting • Voting ditutup
Sebagian Benar
#baby $BABY @BabylonLabs_io
Hampir menaruh sedikit BTC ke posisi pinjaman yang didukung brankas (vault) minggu lalu. Sebelum saya melakukannya, saya ingin tahu satu hal: jika pasar bergerak cepat melawan saya, apa yang sebenarnya menentukan kapan saya akan dilikuidasi?
Pertanyaan itulah yang membuat saya mencari melewati materi pemasaran dan masuk ke situs resmi milik Babylon—ke bagian di mana kata "trustless" (tanpa pihak tepercaya) mulai tidak lagi berlaku.
Itu tidak dikubur. Hanya saja tidak bisa bertahan ketika diterjemahkan ke setiap judul berita yang dibangun dari satu kata itu.
➡ Halaman Learn milik Babylon mengatakan dengan gamblang bahwa risiko yang sesungguhnya berada di sisi DeFi, bukan di dalam brankas itu sendiri, dan menjadikan likuidasi pada pinjaman sebagai contohnya.
➡ Whitepaper juga menguatkannya: likuidasi memerlukan tanda tangan dari price oracle, yang diperlakukan sebagai ketergantungan terpisah dari desain inti brankas.
Berikan penghargaan untuk Babylon—mereka menuliskannya sendiri. Tidak ada yang perlu menggali dari mereka.
Inilah bagian yang paling melekat pada saya, bagian yang benar-benar mengubah seberapa banyak saya akan menyetor. "Sebuah price oracle" terdengar abstrak, sampai satu laporan tentang sistem yang persis ini menyebutkan jaringan mana yang benar-benar memegang hubungan itu dengan Babylon: Band Protocol dan Pyth, jaringan yang sama-sama dipakai untuk kebutuhan umum dalam penetapan harga puluhan rantai lainnya pada waktu yang sama. Materi resmi Babylon tidak menyebut mereka secara langsung, jadi anggap pasangan spesifik itu sebagai laporan, bukan sesuatu yang dikonfirmasi langsung oleh Babylon.
Jika salah satu feed itu terlambat atau salah saat pergerakan cepat, likuidasi saya tetap terjadi persis seperti yang dikodekan. Bertindak dengan informasi yang buruk—dengan benar. Lapisan dasar Bitcoin tidak “ikut memilih” dalam hasil itu. Brankas melakukan persis seperti yang mereka janjikan. Oraculenya hanya memberinya sesuatu yang palsu.
Itu bukan brankas yang gagal. Itu risiko DeFi, memakai label trustless, lalu mewarisi riwayat gangguan (outage history) apa pun yang sudah dibawanya dari feed harga di rantai lain yang bahkan tidak saya gunakan.
Saya tetap membuat setoran. Hanya saja lebih kecil daripada yang akan saya lakukan satu jam sebelumnya.
Trustless menjelaskan apa yang terjadi pada BTC Anda. Itu tidak pernah menjadi janji tentang apa yang terjadi pada uang Anda setelah uang itu keluar dari brankas.
$EUL
Bisakah brankas yang trustless tetap bergantung pada oracles?
Hampir menaruh sedikit BTC ke posisi pinjaman yang didukung brankas (vault) minggu lalu. Sebelum saya melakukannya, saya ingin tahu satu hal: jika pasar bergerak cepat melawan saya, apa yang sebenarnya menentukan kapan saya akan dilikuidasi?
Pertanyaan itulah yang membuat saya mencari melewati materi pemasaran dan masuk ke situs resmi milik Babylon—ke bagian di mana kata "trustless" (tanpa pihak tepercaya) mulai tidak lagi berlaku.
Itu tidak dikubur. Hanya saja tidak bisa bertahan ketika diterjemahkan ke setiap judul berita yang dibangun dari satu kata itu.
➡ Halaman Learn milik Babylon mengatakan dengan gamblang bahwa risiko yang sesungguhnya berada di sisi DeFi, bukan di dalam brankas itu sendiri, dan menjadikan likuidasi pada pinjaman sebagai contohnya.
➡ Whitepaper juga menguatkannya: likuidasi memerlukan tanda tangan dari price oracle, yang diperlakukan sebagai ketergantungan terpisah dari desain inti brankas.
Berikan penghargaan untuk Babylon—mereka menuliskannya sendiri. Tidak ada yang perlu menggali dari mereka.
Inilah bagian yang paling melekat pada saya, bagian yang benar-benar mengubah seberapa banyak saya akan menyetor. "Sebuah price oracle" terdengar abstrak, sampai satu laporan tentang sistem yang persis ini menyebutkan jaringan mana yang benar-benar memegang hubungan itu dengan Babylon: Band Protocol dan Pyth, jaringan yang sama-sama dipakai untuk kebutuhan umum dalam penetapan harga puluhan rantai lainnya pada waktu yang sama. Materi resmi Babylon tidak menyebut mereka secara langsung, jadi anggap pasangan spesifik itu sebagai laporan, bukan sesuatu yang dikonfirmasi langsung oleh Babylon.
Jika salah satu feed itu terlambat atau salah saat pergerakan cepat, likuidasi saya tetap terjadi persis seperti yang dikodekan. Bertindak dengan informasi yang buruk—dengan benar. Lapisan dasar Bitcoin tidak “ikut memilih” dalam hasil itu. Brankas melakukan persis seperti yang mereka janjikan. Oraculenya hanya memberinya sesuatu yang palsu.
Itu bukan brankas yang gagal. Itu risiko DeFi, memakai label trustless, lalu mewarisi riwayat gangguan (outage history) apa pun yang sudah dibawanya dari feed harga di rantai lain yang bahkan tidak saya gunakan.
Saya tetap membuat setoran. Hanya saja lebih kecil daripada yang akan saya lakukan satu jam sebelumnya.
Trustless menjelaskan apa yang terjadi pada BTC Anda. Itu tidak pernah menjadi janji tentang apa yang terjadi pada uang Anda setelah uang itu keluar dari brankas.
$EUL
Bisakah brankas yang trustless tetap bergantung pada oracles?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 Voting • Voting ditutup
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
$EUL $CHILLGUY Goooo
dan berikan saya umpan balik
dan berikan saya umpan balik
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
#baby $BABY @BabylonLabs_io
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
Tidak bisa tidur semalam, jadi saya membuka tiga naskah terpisah di sisi Aave Temp Check milik Babylon, sejajar satu sama lain—lebih karena kebiasaan daripada apa pun.
Satu kata terus mengganggu saya.
Bitcoin.com, Cointribune, dan LiveBitcoinNews semuanya mendeskripsikan alur likuidasi TBV dengan cara yang sama. Likuidator tanpa izin menukar brankas yang disita dengan WBTC secara instan, dengan premi kecil. Lalu, sekumpulan “arbitrase yang diizinkan” membeli posisi tersebut dan menebus BTC yang sebenarnya nanti, sesuai jadwal Bitcoin sendiri.
Berikan kredit pada Babylon untuk paruh pertama: pemeriksaan likuidasi tanpa izin berjalan persis seperti yang dipaparkan.
Bagian keduanya yang membuat saya mencari lebih jauh ke belakang daripada proposal Aave. Whitepaper Agustus milik Babylon tentang Trustless Bitcoin Vaults tidak pernah menyebut “permissioned” juga—ia mengatakan likuidasi berjalan melalui “liquidator yang di-whitelist” yang memantau harga dan keadaan brankas. Kata yang berbeda, bentuknya sama. Seorang analis independen yang bertukar pesan dengan tim Babylon di X mengangkat poin yang sama secara langsung kepada mereka: cukup banyak pihak whitelist yang berperilaku benar adalah asumsi kepercayaan yang tidak disebutkan oleh materi pemasaran.
Jadi, ternyata kata itu memang tepat. Pertanyaan sebenarnya: mengapa peran itu harus dibatasi sama sekali, padahal sisi pertukaran WBTC tidak. Bahasa skrip Bitcoin tidak bisa mengevaluasi sembarang status off-chain. BitVM3 mengakali ini dengan membungkus verifikator bukti pengetahuan nol di dalam sirkuit yang diacak, tetapi seseorang tetap harus menghasilkan dan mengirim bukti tersebut untuk memicu penebusan. Sisi pertukaran WBTC mudah dibiarkan tanpa izin—setiap likuidator yang punya modal bisa mengambil perdagangan itu. Pengiriman bukti adalah masalah yang lebih sulit yang belum terselesaikan oleh BitVM3.
Ini bukan tentang apakah brankas itu trustless atau tidak. Babylon tidak menyembunyikan proses whitelisting di whitepaper mereka sendiri. Trustlessness tidak hilang di sini. Ia hanya berakhir satu langkah lebih awal daripada yang ditunjukkan oleh kebanyakan liputan.
$EUL
Apa yang mendefinisikan brankas BTC yang benar-benar trustless?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 Voting • Voting ditutup
bergabung
英鸿³³₇
·
--
[Putar ulang] 🎙️ Bincang tentang suka-duka pasar primer, dan investasi rutin (DCA) di pasar sekunder untuk BNB
02 j 17 m 48 d · 12.8k mendengarkan
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
dua kumpulan untuk aset yang sama, terpisah beberapa klik, dengan nol koneksi di antara keduanya sampai sekarang. Aave menampung sekitar $5B dalam WBTC yang nyaris tidak bergerak di sisi pinjaman. Babylon memegang $4B+ dalam staked BTC yang tidak menghasilkan apa pun selain imbalan staking.
itulah pitch sebenarnya yang tertanam di Temp Check Babylon — bukan "trustless BTC," tetapi mencocokkan suplai idle di satu platform dengan jaminan idle di platform lain.
desain Hub-and-Spoke Aave di V4 adalah yang membuat ini mungkin tanpa Babylon menyentuh core lending pool Aave sama sekali. dua Spoke baru di-deploy sebagai modul terisolasi — Babylon mengelola logika jaminan BTC, sementara Hub utama Aave tetap tidak tersentuh oleh risiko apa pun yang diperkenalkan.
perlu dicatat: ini bukan proposal komunitas yang beredar tanpa disadari. pendiri Aave sendiri secara publik mendukungnya, menyoroti implementasi Spoke secara spesifik sebagai pola baru untuk V4 — bukan sekadar listing aset lain.
masih dalam tahap Temp Check. ARFC dan pemungutan suara di rantai (on-chain) harus terjadi sebelum BTC apa pun benar-benar mengalir melalui ini.
jika kedua pool masih tetap idle beberapa bulan setelah ini lolos tata kelola, masalahnya tidak pernah ada pada plumbing. masalahnya adalah selera.
$DEXE
Yang paling penting jika ini terbit?
dua kumpulan untuk aset yang sama, terpisah beberapa klik, dengan nol koneksi di antara keduanya sampai sekarang. Aave menampung sekitar $5B dalam WBTC yang nyaris tidak bergerak di sisi pinjaman. Babylon memegang $4B+ dalam staked BTC yang tidak menghasilkan apa pun selain imbalan staking.
itulah pitch sebenarnya yang tertanam di Temp Check Babylon — bukan "trustless BTC," tetapi mencocokkan suplai idle di satu platform dengan jaminan idle di platform lain.
desain Hub-and-Spoke Aave di V4 adalah yang membuat ini mungkin tanpa Babylon menyentuh core lending pool Aave sama sekali. dua Spoke baru di-deploy sebagai modul terisolasi — Babylon mengelola logika jaminan BTC, sementara Hub utama Aave tetap tidak tersentuh oleh risiko apa pun yang diperkenalkan.
perlu dicatat: ini bukan proposal komunitas yang beredar tanpa disadari. pendiri Aave sendiri secara publik mendukungnya, menyoroti implementasi Spoke secara spesifik sebagai pola baru untuk V4 — bukan sekadar listing aset lain.
masih dalam tahap Temp Check. ARFC dan pemungutan suara di rantai (on-chain) harus terjadi sebelum BTC apa pun benar-benar mengalir melalui ini.
jika kedua pool masih tetap idle beberapa bulan setelah ini lolos tata kelola, masalahnya tidak pernah ada pada plumbing. masalahnya adalah selera.
$DEXE
Yang paling penting jika ini terbit?
Masuk untuk menjelajahi konten lainnya