$ICNT $BLESS
tapi yang aku tatap itu bukan bahkan likuidasi itu sendiri.
itu karena order vault di dalam posisi Babylon Aave v4 bisa diam-diam berubah menjadi order kerugian. health factor turun di bawah 1 dan Babylon Core Spoke menghitung berapa banyak jaminan yang harus dilikuidasi.
angka yang rapi.
tapi apakah Bitcoin peduli seberapa rapi angka itu?
sebenarnya tidak.
satu Babylon Trustless Bitcoin Vault masih satu UTXO Taproot yang utuh. lapisan dasar Bitcoin tidak bisa melepas setengahnya hanya karena kekurangan di sisi Ethereum keluar sebagai pecahan yang rapi. jadi alur likuidasi Babylon dimulai dari daftar vault yang dipesan milik depositor di bagian depan dan mengambil vault-vault lengkap sampai target likuidasi terpenuhi.
ternyata reordering kecil itu tidak pernah sekadar kosmetik.
itu sudah menetapkan prioritas likuidasi.
mungkin vault pertama memang sengaja dibuat lebih kecil dan sebagai pengorbanan, diletakkan di sana supaya vault yang lebih besar bisa tetap selamat.
terdengar terkontrol.
tapi bagaimana kalau vault pengorbanan itu tidak cukup? maka Babylon mengambil vault lengkap berikutnya juga. “Aave menghitung kekurangan. Bitcoin menjawab dalam UTXO utuh.”
utang tetap presisi.
kerugian tetap datang dalam potongan-potongan ukuran vault Babylon yang dibentuk oleh keputusan pengurutan yang dibuat lebih awal, kemungkinan besar saat health factor terlihat benar-benar baik. dan bagian itulah yang terasa agak tidak tepat di kepalaku.
karena peristiwa likuidasi datang belakangan. tapi urutan kerusakan sudah ada di sana sebelum ada yang terlihat rusak. jadi kapan sebenarnya risiko likuidasi mulai terjadi di Babylon?
saat health factor turun di bawah 1?
atau ketika aku diam-diam menaruh satu vault Bitcoin di tempat yang akan jadi yang pertama untuk pergi?
@BabylonLabs_io $BABY #baby
tapi yang aku tatap itu bukan bahkan likuidasi itu sendiri.
itu karena order vault di dalam posisi Babylon Aave v4 bisa diam-diam berubah menjadi order kerugian. health factor turun di bawah 1 dan Babylon Core Spoke menghitung berapa banyak jaminan yang harus dilikuidasi.
angka yang rapi.
tapi apakah Bitcoin peduli seberapa rapi angka itu?
sebenarnya tidak.
satu Babylon Trustless Bitcoin Vault masih satu UTXO Taproot yang utuh. lapisan dasar Bitcoin tidak bisa melepas setengahnya hanya karena kekurangan di sisi Ethereum keluar sebagai pecahan yang rapi. jadi alur likuidasi Babylon dimulai dari daftar vault yang dipesan milik depositor di bagian depan dan mengambil vault-vault lengkap sampai target likuidasi terpenuhi.
ternyata reordering kecil itu tidak pernah sekadar kosmetik.
itu sudah menetapkan prioritas likuidasi.
mungkin vault pertama memang sengaja dibuat lebih kecil dan sebagai pengorbanan, diletakkan di sana supaya vault yang lebih besar bisa tetap selamat.
terdengar terkontrol.
tapi bagaimana kalau vault pengorbanan itu tidak cukup? maka Babylon mengambil vault lengkap berikutnya juga. “Aave menghitung kekurangan. Bitcoin menjawab dalam UTXO utuh.”
utang tetap presisi.
kerugian tetap datang dalam potongan-potongan ukuran vault Babylon yang dibentuk oleh keputusan pengurutan yang dibuat lebih awal, kemungkinan besar saat health factor terlihat benar-benar baik. dan bagian itulah yang terasa agak tidak tepat di kepalaku.
karena peristiwa likuidasi datang belakangan. tapi urutan kerusakan sudah ada di sana sebelum ada yang terlihat rusak. jadi kapan sebenarnya risiko likuidasi mulai terjadi di Babylon?
saat health factor turun di bawah 1?
atau ketika aku diam-diam menaruh satu vault Bitcoin di tempat yang akan jadi yang pertama untuk pergi?
@BabylonLabs_io $BABY #baby
