Binance Square
#shareyouropinion

shareyouropinion

9,136 penayangan
37 Berdiskusi
Mirza_X_Mustafa
·
--
Terverifikasi
Menemukan laporan transparansi sebelumnya tadi malam yang belum pernah saya baca, dan itu mengubah cara saya memahami apa sebenarnya Newton. Newton awalnya sama sekali tidak dirancang sebagai mesin kebijakan untuk kepatuhan. Keterbukaan Oktober 2025 mendeskripsikan desain aslinya sebagai sebuah keystore rollup yang dibangun untuk manajemen kunci, dengan fokus khusus pada otomasi yang dapat diverifikasi dan otorisasi yang didelegasikan untuk agen AI. Gagasan intinya adalah memungkinkan agen mengeksekusi aksi onchain melalui izin terkontrol yang diverifikasi secara kriptografis, yang terikat pada infrastruktur manajemen kunci. Pergantian arah terjadi ketika tim menyadari bahwa primitf-primitif dasar yang sama—otomasi yang dapat diverifikasi dan otorisasi yang didelegasikan—dapat diperluas jauh melampaui manajemen kunci agen, menjadi kerangka umum untuk penegakan kebijakan di seluruh stablecoin, RWAs, dan pasar aset yang lebih luas. Keystore rollup tersebut menjadi fondasi untuk sesuatu yang jauh lebih luas: sebuah mesin kebijakan yang mengatur tindakan apa yang boleh terjadi—dalam kondisi apa—dengan attestasi apa. Itu titik awal yang secara bermakna berbeda dibandingkan yang disarankan oleh whitepaper yang sebelumnya saya baca. Saya benar-benar berpikir bahwa sejarah ini penting untuk memahami pilihan arsitektur Newton: model attestasi BLS, desain kuorum operator, penekanan pada perdagangan agen sebagai kasus penggunaan—ini bukan keputusan desain yang berangkat dari kepatuhan. Ini adalah keputusan desain manajemen kunci dan otorisasi agen yang kemudian digeneralisasikan menjadi kasus penggunaan kepatuhan setelahnya. Yang belum saya selesaikan adalah seberapa besar arsitektur saat ini masih membawa asumsi dari desain keystore rollup asli yang mungkin tidak optimal untuk mesin kebijakan yang berorientasi kepatuhan—apakah pivot tersebut merupakan desain ulang yang bersih atau perluasan dari fondasi teknis aslinya. #ShareYourOpinion $EVAA $LAB Bagaimana menurut Anda arsitektur Newton berkembang? @NewtonProtocol $NEWT #Newt
Menemukan laporan transparansi sebelumnya tadi malam yang belum pernah saya baca, dan itu mengubah cara saya memahami apa sebenarnya Newton. Newton awalnya sama sekali tidak dirancang sebagai mesin kebijakan untuk kepatuhan.

Keterbukaan Oktober 2025 mendeskripsikan desain aslinya sebagai sebuah keystore rollup yang dibangun untuk manajemen kunci, dengan fokus khusus pada otomasi yang dapat diverifikasi dan otorisasi yang didelegasikan untuk agen AI.

Gagasan intinya adalah memungkinkan agen mengeksekusi aksi onchain melalui izin terkontrol yang diverifikasi secara kriptografis, yang terikat pada infrastruktur manajemen kunci.

Pergantian arah terjadi ketika tim menyadari bahwa primitf-primitif dasar yang sama—otomasi yang dapat diverifikasi dan otorisasi yang didelegasikan—dapat diperluas jauh melampaui manajemen kunci agen, menjadi kerangka umum untuk penegakan kebijakan di seluruh stablecoin, RWAs, dan pasar aset yang lebih luas.

Keystore rollup tersebut menjadi fondasi untuk sesuatu yang jauh lebih luas: sebuah mesin kebijakan yang mengatur tindakan apa yang boleh terjadi—dalam kondisi apa—dengan attestasi apa.

Itu titik awal yang secara bermakna berbeda dibandingkan yang disarankan oleh whitepaper yang sebelumnya saya baca.

Saya benar-benar berpikir bahwa sejarah ini penting untuk memahami pilihan arsitektur Newton: model attestasi BLS, desain kuorum operator, penekanan pada perdagangan agen sebagai kasus penggunaan—ini bukan keputusan desain yang berangkat dari kepatuhan. Ini adalah keputusan desain manajemen kunci dan otorisasi agen yang kemudian digeneralisasikan menjadi kasus penggunaan kepatuhan setelahnya.

Yang belum saya selesaikan adalah seberapa besar arsitektur saat ini masih membawa asumsi dari desain keystore rollup asli yang mungkin tidak optimal untuk mesin kebijakan yang berorientasi kepatuhan—apakah pivot tersebut merupakan desain ulang yang bersih atau perluasan dari fondasi teknis aslinya.
#ShareYourOpinion
$EVAA $LAB
Bagaimana menurut Anda arsitektur Newton berkembang?
@NewtonProtocol $NEWT #Newt
Original design mostly remaine
0%
Major redesign after the pivot
0%
A blend of both approaches
33%
Not enough information yet
67%
3 Voting • Voting ditutup
Realitas operasional KYC AML tradisional vs kesenjangan kewajiban model kredensial Newton Saya menelusuri model identitas Newton bersama seorang teman petugas kepatuhan minggu lalu seseorang yang menjalankan program KYC di perusahaan teregulasi dan kesenjangan antara apa yang Newton jelaskan dan apa yang Tim Kepatuhan lakukan secara operasional ternyata lebih besar dari yang saya perkirakan. KYC/AML tradisional tim onboarding mengumpulkan dokumen, menyaring terhadap basis data sanksi, memberi skor risiko simpan catatannya. Transaksi tertandai secara retrospektif tarik berkas. Riwayat peninjauan tulis laporan berkas SAR. Jejak dokumen manual berbasis kertas auditor terima. Bank yang bertanggung jawab. Bank yang melakukan pengecekan itu. Bank yang memiliki hasilnya. Model Newton: kredensial dikeluarkan oleh penyedia KYC pihak ketiga, dipegang oleh pengguna, dievaluasi oleh operator di TEE Enclave terhadap kebijakan dalam hitungan detik. Tanda terima kepatuhan adalah jejak audit. Kecepatan dan otomatisasi itu nyata. Pertanyaan pertama yang diajukan teman saya petugas kepatuhan adalah siapa yang bertanggung jawab ketika Newton mengatakan kredensial valid, tetapi data penerbitnya salah. Dalam model Newton, penerbit menerbitkannya, operator mengevaluasinya, smart contract menerapkannya. Rantai tanggung jawab menjadi lebih panjang dan kurang jelas. Saya sebenarnya berpikir bahwa distribusi kewajiban adalah pertanyaan desain yang paling penting secara praktis untuk adopsi institusional bukan kemampuan teknisnya, melainkan siapa yang menanggung kewajiban ketika transaksi yang diattestasikan Newton ternyata tidak patuh. Yang belum saya selesaikan adalah apakah tanda terima kepatuhan Newton memenuhi persyaratan kewajiban regulatori atau hanya dokumen bahwa sebuah pengecekan dijalankan dan apakah keduanya adalah hal yang sama. $LAB $HMSTR #shareyouropinion @NewtonProtocol $NEWT #Newt
Realitas operasional KYC AML tradisional vs kesenjangan kewajiban model kredensial Newton

Saya menelusuri model identitas Newton bersama seorang teman petugas kepatuhan minggu lalu seseorang yang menjalankan program KYC di perusahaan teregulasi dan kesenjangan antara apa yang Newton jelaskan dan apa yang Tim Kepatuhan lakukan secara operasional ternyata lebih besar dari yang saya perkirakan.

KYC/AML tradisional tim onboarding mengumpulkan dokumen, menyaring terhadap basis data sanksi, memberi skor risiko simpan catatannya. Transaksi tertandai secara retrospektif tarik berkas. Riwayat peninjauan tulis laporan berkas SAR.

Jejak dokumen manual berbasis kertas auditor terima. Bank yang bertanggung jawab. Bank yang melakukan pengecekan itu. Bank yang memiliki hasilnya.

Model Newton: kredensial dikeluarkan oleh penyedia KYC pihak ketiga, dipegang oleh pengguna, dievaluasi oleh operator di TEE Enclave terhadap kebijakan dalam hitungan detik. Tanda terima kepatuhan adalah jejak audit.

Kecepatan dan otomatisasi itu nyata. Pertanyaan pertama yang diajukan teman saya petugas kepatuhan adalah siapa yang bertanggung jawab ketika Newton mengatakan kredensial valid, tetapi data penerbitnya salah. Dalam model Newton, penerbit menerbitkannya, operator mengevaluasinya, smart contract menerapkannya. Rantai tanggung jawab menjadi lebih panjang dan kurang jelas.

Saya sebenarnya berpikir bahwa distribusi kewajiban adalah pertanyaan desain yang paling penting secara praktis untuk adopsi institusional bukan kemampuan teknisnya, melainkan siapa yang menanggung kewajiban ketika transaksi yang diattestasikan Newton ternyata tidak patuh.

Yang belum saya selesaikan adalah apakah tanda terima kepatuhan Newton memenuhi persyaratan kewajiban regulatori atau hanya dokumen bahwa sebuah pengecekan dijalankan dan apakah keduanya adalah hal yang sama.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt
program poin dan rewards di DeFi menciptakan compliance Edge case. identitas Newton dan domain compliance tidak dirancang dengan jelas untuk mengatasi hal tersebut. dalam program poin, program mendistribusikan kredit atau token ke wallet berdasarkan aktivitas protokol. dalam kedua kasus, pertanyaan compliance adalah apakah wallet penerima memenuhi syarat untuk menerima nilai yang didistribusikan. compliance untuk transaksi berlaku pada distribusi rewards dengan cara yang sama seperti berlaku untuk transfer nilai lainnya. apakah domain compliance Newton dapat menegakkan pemeriksaan sanksi pada transaksi distribusi rewards secara spesifik pada transfer keluar rewards dari sebuah protokol ke sebuah wallet tidak dijelaskan dengan jelas dalam dokumentasi. arahanya penting. kebanyakan kasus penggunaan Newton melibatkan pemeriksaan sebuah wallet sebelum ia mengirim transaksi ke sebuah protokol. sebuah rewards airdrop bekerja dengan arah yang berlawanan. apakah model penegakan berlaku untuk transfer keluar yang diprakarsai protokol adalah pertanyaan struktural tentang bagaimana pemeriksaan kebijakan dipicu. tidak ada jawaban untuk ini dalam dokumentasi saat ini. edge case ini cukup nyata untuk diperhatikan bagi setiap protokol DeFi yang menjalankan program rewards aktif. @NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion {future}(HMSTRUSDT) {future}(LABUSDT) {spot}(NEWTUSDT) #Newt #NEWT Apakah rewards perlu pengecekan?
program poin dan rewards di DeFi menciptakan compliance Edge case. identitas Newton dan domain compliance tidak dirancang dengan jelas untuk mengatasi hal tersebut.

dalam program poin, program mendistribusikan kredit atau token ke wallet berdasarkan aktivitas protokol.

dalam kedua kasus,
pertanyaan compliance adalah apakah wallet penerima memenuhi syarat untuk menerima nilai yang didistribusikan.

compliance untuk transaksi berlaku pada distribusi rewards dengan cara yang sama seperti berlaku untuk transfer nilai lainnya.

apakah domain compliance Newton dapat menegakkan pemeriksaan sanksi pada transaksi distribusi rewards
secara spesifik pada transfer keluar rewards dari sebuah protokol ke sebuah wallet
tidak dijelaskan dengan jelas dalam dokumentasi.

arahanya penting.

kebanyakan kasus penggunaan Newton melibatkan pemeriksaan sebuah wallet sebelum ia mengirim transaksi ke sebuah protokol.

sebuah rewards airdrop bekerja dengan arah yang berlawanan.

apakah model penegakan berlaku untuk transfer keluar yang diprakarsai protokol adalah pertanyaan struktural tentang bagaimana pemeriksaan kebijakan dipicu.

tidak ada jawaban untuk ini dalam dokumentasi saat ini. edge case ini cukup nyata untuk diperhatikan bagi setiap protokol DeFi yang menjalankan program rewards aktif.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
Apakah rewards perlu pengecekan?
🔘 Always
67%
🔘 High-value only
33%
🔘 Never
0%
🔘 Depends on rules
0%
6 Voting • Voting ditutup
Artikel
Rego dalam otorisasi cloud perusahaan vs kasus penggunaan kepatuhan Newton#newt Minggu ini saya menelusuri bagian penulisan kebijakan Rego untuk memahami apa sebenarnya yang diminta Newton untuk dipelajari oleh pengembang dan tim kepatuhan—karena cara pandang dari bahasa yang sama yang digunakan untuk Kubernetes admission control membawa asumsi yang layak untuk diperiksa. Rego adalah bahasa kebijakan deklaratif yang dibuat oleh proyek Open Policy Agent. Dalam infrastruktur perusahaan, bahasa ini digunakan untuk otorisasi Kubernetes Admission Control melalui API gateway, serta untuk kebijakan pada pipeline CI/CD. Ia memiliki model evaluasi yang spesifik, yaitu sekumpulan aturan atas data terstruktur yang dievaluasi untuk menghasilkan sebuah keputusan, dan kurva pembelajaran yang tidak jelas bagi siapa pun yang datang dari latar belakang pemrograman imperatif.

Rego dalam otorisasi cloud perusahaan vs kasus penggunaan kepatuhan Newton

#newt
Minggu ini saya menelusuri bagian penulisan kebijakan Rego untuk memahami apa sebenarnya yang diminta Newton untuk dipelajari oleh pengembang dan tim kepatuhan—karena cara pandang dari bahasa yang sama yang digunakan untuk Kubernetes admission control membawa asumsi yang layak untuk diperiksa.
Rego adalah bahasa kebijakan deklaratif yang dibuat oleh proyek Open Policy Agent. Dalam infrastruktur perusahaan, bahasa ini digunakan untuk otorisasi Kubernetes Admission Control melalui API gateway, serta untuk kebijakan pada pipeline CI/CD. Ia memiliki model evaluasi yang spesifik, yaitu sekumpulan aturan atas data terstruktur yang dievaluasi untuk menghasilkan sebuah keputusan, dan kurva pembelajaran yang tidak jelas bagi siapa pun yang datang dari latar belakang pemrograman imperatif.
mulailah dari kecil. agen AI yang menghasilkan perdagangan di DeFi tidak kemudian melakukan perdagangan algoritmik di keuangan tradisional, dan infrastruktur kepatuhan di sekitarnya jauh lebih kurang berkembang. perbesar pandangan: lapisan kebijakan Newton membahas pertanyaan kepatuhan tingkat transaksi. apakah transaksi spesifik ini memenuhi aturan yang telah ditetapkan—itulah satu lapisan dari kepatuhan yang dibutuhkan oleh perdagangan algoritmik tradisional. #NEWT lapisan-lapisan di atasnya berbeda. kepatuhan perdagangan algoritmik tradisional memerlukan dokumentasi model, jejak audit yang menghubungkan perdagangan yang dieksekusi dengan keputusan model tertentu, serta kemampuan killswitch untuk intervensi manusia ketika model berperilaku tidak terduga. #newt tidak ada hal-hal tersebut yang dicakup oleh penegakan pra-penyelesaian pada transaksi individual. perbesar pandangan lebih jauh: jika perdagangan agen AI di DeFi meningkat skalanya, regulator akan menerapkan persyaratan yang mirip dengan yang mengatur perdagangan algoritmik di pasar tradisional. infrastruktur Newton adalah komponen yang diperlukan dalam tumpukan kepatuhan tersebut. menganggapnya sebagai sesuatu yang cukup dengan sendirinya akan menjadi celah yang berarti bagi entitas yang diatur mana pun yang menggunakan agen AI di DeFi. #ShareYourOpinion $LAB $HMSTR @NewtonProtocol $NEWT #Newt
mulailah dari kecil. agen AI yang menghasilkan perdagangan di DeFi tidak kemudian melakukan perdagangan algoritmik di keuangan tradisional, dan infrastruktur kepatuhan di sekitarnya jauh lebih kurang berkembang.

perbesar pandangan: lapisan kebijakan Newton membahas pertanyaan kepatuhan tingkat transaksi. apakah transaksi spesifik ini memenuhi aturan yang telah ditetapkan—itulah satu lapisan dari kepatuhan yang dibutuhkan oleh perdagangan algoritmik tradisional.
#NEWT
lapisan-lapisan di atasnya berbeda. kepatuhan perdagangan algoritmik tradisional memerlukan dokumentasi model, jejak audit yang menghubungkan perdagangan yang dieksekusi dengan keputusan model tertentu, serta kemampuan killswitch untuk intervensi manusia ketika model berperilaku tidak terduga.
#newt

tidak ada hal-hal tersebut yang dicakup oleh penegakan pra-penyelesaian pada transaksi individual.

perbesar pandangan lebih jauh: jika perdagangan agen AI di DeFi meningkat skalanya, regulator akan menerapkan persyaratan yang mirip dengan yang mengatur perdagangan algoritmik di pasar tradisional. infrastruktur Newton adalah komponen yang diperlukan dalam tumpukan kepatuhan tersebut. menganggapnya sebagai sesuatu yang cukup dengan sendirinya akan menjadi celah yang berarti bagi entitas yang diatur mana pun yang menggunakan agen AI di DeFi.

#ShareYourOpinion $LAB $HMSTR

@NewtonProtocol $NEWT #Newt
Bacalah lagi dokumen tata kelola itu tadi malam karena saya bisa memahami bahwa tata kelola yang diasumsikan berarti sesuatu yang sudah beroperasi. Artinya, sesuatu yang sedang dirancang. Siklus proposal yang dijelaskan Newton memiliki lima tahap. Ide diskusi informal tanpa proses formal. RFC Request for Comments, dokumen terstruktur yang mengusulkan perubahan. NIP Newton Improvement Proposal versi RFC yang sudah diformalkan dan siap untuk dipertimbangkan. Diskusi Komunitas periode terbuka untuk masukan sebelum pemungutan suara. Pemungutan Suara Token House dilakukan di luar rantai via Snapshot, di mana pemegang NEWT memberikan suara pada NIP. Itulah seluruh alur sesuai rancangan. Apa yang saya lewatkan saat pembacaan pertama adalah bahwa alur ini ada di dalam dokumen, tetapi Token House itu sendiri badan yang benar-benar memberikan suara belum ada sebagai struktur operasional. Saat ini, pada fase 0 yang disebut dalam dokumen, Dewan Yayasan yang mengambil keputusan. Siklus proposal adalah keadaan target, bukan kondisi saat ini. Detail itu mengubah cara saya membaca setiap klaim tata kelola dalam materi Newton. Saya sebenarnya suka karena dokumen itu secara eksplisit membedakan hal ini bahasa Fase 0 tidak samar pemasaran yang dikelola komunitas. Jarang melihat nama proyek yang menyebut tahap sentralisasi saat ini secara langsung. Yang belum saya pahami adalah apa yang secara spesifik memicu transisi dari Fase 0 ke Fase 1 apakah berdasarkan jadwal yang tetap, metrik desentralisasi, atau sepenuhnya atas kebijaksanaan Dewan Yayasan. $TAC $LAB #ShareYourOpinion @NewtonProtocol $NEWT #Newt
Bacalah lagi dokumen tata kelola itu tadi malam karena saya bisa memahami bahwa tata kelola yang diasumsikan berarti sesuatu yang sudah beroperasi. Artinya, sesuatu yang sedang dirancang.

Siklus proposal yang dijelaskan Newton memiliki lima tahap. Ide diskusi informal tanpa proses formal. RFC Request for Comments, dokumen terstruktur yang mengusulkan perubahan. NIP Newton Improvement Proposal versi RFC yang sudah diformalkan dan siap untuk dipertimbangkan.

Diskusi Komunitas periode terbuka untuk masukan sebelum pemungutan suara. Pemungutan Suara Token House dilakukan di luar rantai via Snapshot, di mana pemegang NEWT memberikan suara pada NIP.

Itulah seluruh alur sesuai rancangan.

Apa yang saya lewatkan saat pembacaan pertama adalah bahwa alur ini ada di dalam dokumen, tetapi Token House itu sendiri badan yang benar-benar memberikan suara belum ada sebagai struktur operasional. Saat ini, pada fase 0 yang disebut dalam dokumen, Dewan Yayasan yang mengambil keputusan. Siklus proposal adalah keadaan target, bukan kondisi saat ini.

Detail itu mengubah cara saya membaca setiap klaim tata kelola dalam materi Newton.

Saya sebenarnya suka karena dokumen itu secara eksplisit membedakan hal ini bahasa Fase 0 tidak samar pemasaran yang dikelola komunitas. Jarang melihat nama proyek yang menyebut tahap sentralisasi saat ini secara langsung.

Yang belum saya pahami adalah apa yang secara spesifik memicu transisi dari Fase 0 ke Fase 1 apakah berdasarkan jadwal yang tetap, metrik desentralisasi, atau sepenuhnya atas kebijaksanaan Dewan Yayasan.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt
·
--
Bullish
$BTR Binance Btr peta likuidasi usdt Tidak ada yang tersisa di bawah left dalam likuidasi short btr Likuidasi 100k pada 0.5223 Waktu untuk Beli Pengaturan Entri Perdagangan Long 🚦 0.04800 Zona Harga Take Profit 🎯 0.05000 Zona Target Berikutnya Harga 🎯 0.05100 Zona Target Harga Terakhir 🎯 0.05200 #BTR #ShareBuyback #shareyouropinion {future}(BTRUSDT)
$BTR Binance Btr peta likuidasi usdt
Tidak ada yang tersisa di bawah left dalam likuidasi short btr
Likuidasi 100k pada 0.5223 Waktu untuk Beli
Pengaturan Entri Perdagangan Long 🚦 0.04800
Zona Harga Take Profit 🎯 0.05000
Zona Target Berikutnya Harga 🎯 0.05100
Zona Target Harga Terakhir 🎯 0.05200

#BTR #ShareBuyback #shareyouropinion
Terverifikasi
Naskah putih Trustless Bitcoin Vaults (TBV) melakukan sesuatu yang patut disorot. Di Bagian 5, naskah tersebut mencantumkan Open Participation sebagai salah satu manfaat yang disebutkan, dan sekaligus menentukan liquidator yang di-whitelist sebagai mekanisme sebenarnya di bagian yang sama.@babylonlabs_io Butir manfaatnya secara eksplisit menjelaskan siapa yang dicakup oleh open participation: liquidator, peminjam, dan pengembang—semuanya diharapkan dapat terhubung ke protokol dengan onboarding yang minimal. Alur likuidasi beberapa paragraf sebelumnya juga sama-sama eksplisit: likuidasi dieksekusi oleh liquidator yang di-whitelist, yaitu sebuah kumpulan terdefinisi yang bersifat permissioned, bukan siapa pun yang ingin menutup posisi yang undercollateralized.$BABY Tidak berarti bahwa melakukan whitelisting liquidator itu tidak masuk akal. Likuidasi berarti menahan dan memindahkan modal riil dengan cepat, dan melakukan verifikasi peserta untuk peran tersebut adalah praktik standar di berbagai protokol pinjaman—baik onchain maupun offchain. Namun, tidak juga berarti kedua klaim itu selaras sepenuhnya. Manfaat menyebut liquidator sebagai open participant, tetapi mekanismenya justru membatasi. Keduanya tidak bisa sepenuhnya benar pada waktu yang sama: “open” membawa bobot lebih besar dalam butir itu dibanding dukungan yang diberikan oleh whitelist. #baby Mungkin ada resolusi jika whitelist itu sendiri mudah untuk diikuti: himpunan co-signing k-of-n bisa memungkinkan siapa pun untuk masuk—lalu minimal onboarding dan whitelisted bisa menjadi hal yang sama dilihat dari dua sudut pandang. Tetapi naskah putih tersebut tidak pernah menjelaskan bagaimana seorang liquidator benar-benar mendapatkan status whitelisted. Jadi, apakah siapa pun bisa menjadi liquidator, atau apakah open participation berakhir di whitelist? Bagian 5 menyebut manfaat dan gerbangnya di halaman yang sama, dan tidak menghubungkan keduanya. $UAI $BANK #ShareYourOpinion #ShareYourVote
Naskah putih Trustless Bitcoin Vaults (TBV) melakukan sesuatu yang patut disorot. Di Bagian 5, naskah tersebut mencantumkan Open Participation sebagai salah satu manfaat yang disebutkan, dan sekaligus menentukan liquidator yang di-whitelist sebagai mekanisme sebenarnya di bagian yang sama.@BabylonLabs_io

Butir manfaatnya secara eksplisit menjelaskan siapa yang dicakup oleh open participation: liquidator, peminjam, dan pengembang—semuanya diharapkan dapat terhubung ke protokol dengan onboarding yang minimal. Alur likuidasi beberapa paragraf sebelumnya juga sama-sama eksplisit: likuidasi dieksekusi oleh liquidator yang di-whitelist, yaitu sebuah kumpulan terdefinisi yang bersifat permissioned, bukan siapa pun yang ingin menutup posisi yang undercollateralized.$BABY

Tidak berarti bahwa melakukan whitelisting liquidator itu tidak masuk akal. Likuidasi berarti menahan dan memindahkan modal riil dengan cepat, dan melakukan verifikasi peserta untuk peran tersebut adalah praktik standar di berbagai protokol pinjaman—baik onchain maupun offchain.

Namun, tidak juga berarti kedua klaim itu selaras sepenuhnya. Manfaat menyebut liquidator sebagai open participant, tetapi mekanismenya justru membatasi. Keduanya tidak bisa sepenuhnya benar pada waktu yang sama: “open” membawa bobot lebih besar dalam butir itu dibanding dukungan yang diberikan oleh whitelist. #baby

Mungkin ada resolusi jika whitelist itu sendiri mudah untuk diikuti: himpunan co-signing k-of-n bisa memungkinkan siapa pun untuk masuk—lalu minimal onboarding dan whitelisted bisa menjadi hal yang sama dilihat dari dua sudut pandang. Tetapi naskah putih tersebut tidak pernah menjelaskan bagaimana seorang liquidator benar-benar mendapatkan status whitelisted.

Jadi, apakah siapa pun bisa menjadi liquidator, atau apakah open participation berakhir di whitelist? Bagian 5 menyebut manfaat dan gerbangnya di halaman yang sama, dan tidak menghubungkan keduanya.

$UAI $BANK
#ShareYourOpinion
#ShareYourVote
Anyone can liquidate
60%
Whitelist is required
20%
Needs clarification
20%
5 Voting • Voting ditutup
Saya kembali dan benar-benar mengikuti alur testnetnya akhir pekan ini, bukan hanya membaca tentangnya dari orang lain. Saya kira menonton panduan video yang diasumsikan cukup untuk memahami mekanismenya. Ternyata tidak. Testnet publik untuk peminjaman beragun Bitcoin native melalui Aave v4 yang didukung oleh Trustless Bitcoin Vaults (TBV) memungkinkan Anda menyetor test BTC ke dalam sebuah vault, lalu menontonnya terverifikasi di onchain dan meminjam dengan cara yang sama seperti yang dijelaskan whitepaper: pembuatan collBTC dan proses lending. Mengambil token test dari faucet terlebih dahulu, kemudian menelusuri penyetoran melalui explorer membuat konsep vault yang abstrak menjadi urutan langkah yang benar-benar terasa—bukan sekadar diagram. Yang “klik” bagi saya hanya setelah saya melakukannya sendiri: langkah verifikasi light client tidak terasa instan seperti halnya transfer token biasa. Ada waktu tunggu yang nyata antara penyetoran dan munculnya collBTC yang bisa digunakan. Saya benar-benar berpikir, menjalankannya sendiri mengubah cara Anda membaca bagian-bagian selanjutnya dari whitepaper. Alur settlement dan liquidation tidak lagi abstrak saat Anda sudah melihat satu penyetoran bergerak melalui langkah-langkah yang sama. Yang belum saya teliti adalah apakah waktu pada testnet sesuai dengan pengalaman yang akan terasa di mainnet—atau apakah infrastruktur testnet berjalan lebih cepat atau lebih lambat dibanding deploy di lingkungan live. Ada formulir umpan balik yang terhubung bersama aplikasi testnet. Jika Anda menjalankan alurnya sendiri, form ini layak digunakan bila Anda mendapati sesuatu yang tidak sesuai dengan dokumen. $EUL $ON #shareyouropinion @babylonlabs_io $BABY #baby
Saya kembali dan benar-benar mengikuti alur testnetnya akhir pekan ini, bukan hanya membaca tentangnya dari orang lain. Saya kira menonton panduan video yang diasumsikan cukup untuk memahami mekanismenya. Ternyata tidak.

Testnet publik untuk peminjaman beragun Bitcoin native melalui Aave v4 yang didukung oleh Trustless Bitcoin Vaults (TBV) memungkinkan Anda menyetor test BTC ke dalam sebuah vault, lalu menontonnya terverifikasi di onchain dan meminjam dengan cara yang sama seperti yang dijelaskan whitepaper: pembuatan collBTC dan proses lending. Mengambil token test dari faucet terlebih dahulu, kemudian menelusuri penyetoran melalui explorer membuat konsep vault yang abstrak menjadi urutan langkah yang benar-benar terasa—bukan sekadar diagram.

Yang “klik” bagi saya hanya setelah saya melakukannya sendiri: langkah verifikasi light client tidak terasa instan seperti halnya transfer token biasa. Ada waktu tunggu yang nyata antara penyetoran dan munculnya collBTC yang bisa digunakan.

Saya benar-benar berpikir, menjalankannya sendiri mengubah cara Anda membaca bagian-bagian selanjutnya dari whitepaper. Alur settlement dan liquidation tidak lagi abstrak saat Anda sudah melihat satu penyetoran bergerak melalui langkah-langkah yang sama.

Yang belum saya teliti adalah apakah waktu pada testnet sesuai dengan pengalaman yang akan terasa di mainnet—atau apakah infrastruktur testnet berjalan lebih cepat atau lebih lambat dibanding deploy di lingkungan live.

Ada formulir umpan balik yang terhubung bersama aplikasi testnet. Jika Anda menjalankan alurnya sendiri, form ini layak digunakan bila Anda mendapati sesuatu yang tidak sesuai dengan dokumen.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby
Artikel
Audit Halborn: tidak ada kerentanan kritis — apa yang diberitahukan oleh pengungkapan ruang lingkup auditKembali ke pengungkapan audit Halborn di laporan Q4 2025 untuk melihat dengan cermat apa yang benar-benar diaudit dan apa yang dikatakan tentang hasilnya, karena frasa “tidak ada kerentanan kritis” perlu dipahami ruang lingkupnya sebelum artinya menjadi jelas. Audit ini secara spesifik menargetkan infrastruktur prover yang disebutkan secara eksplisit dalam laporan, sehingga dibedakan dari audit atas seluruh protokol. Asumsi keamanan atas ketepatan (correctness) serta ketangguhan implementasi prover yang digunakan dalam alur kerja verifikasi kebijakan menjadi fokus yang dinyatakan. Ini adalah audit tingkat komponen yang bersifat terkurung, bukan peninjauan keamanan protokol end-to-end.

Audit Halborn: tidak ada kerentanan kritis — apa yang diberitahukan oleh pengungkapan ruang lingkup audit

Kembali ke pengungkapan audit Halborn di laporan Q4 2025 untuk melihat dengan cermat apa yang benar-benar diaudit dan apa yang dikatakan tentang hasilnya, karena frasa “tidak ada kerentanan kritis” perlu dipahami ruang lingkupnya sebelum artinya menjadi jelas.
Audit ini secara spesifik menargetkan infrastruktur prover yang disebutkan secara eksplisit dalam laporan, sehingga dibedakan dari audit atas seluruh protokol.
Asumsi keamanan atas ketepatan (correctness) serta ketangguhan implementasi prover yang digunakan dalam alur kerja verifikasi kebijakan menjadi fokus yang dinyatakan. Ini adalah audit tingkat komponen yang bersifat terkurung, bukan peninjauan keamanan protokol end-to-end.
Dinamika kekuasaan governance siapa yang mengendalikan ambang batas kuorum pembagian biaya penerimaan operator Bagian yang tidak pernah ditanyakan orang dalam governance Newton adalah siapa sebenarnya yang mengendalikan parameter yang paling penting. Tiga jalur governance kebijakan standar penerimaan operator peningkatan protokol Fine yang hilang dari diskusi adalah apa yang sebenarnya diatur oleh jalur-jalur tersebut. Ambang batas kuorum dapat dikonfigurasi per tugas ditetapkan oleh governance menentukan keamanan ekonomi setiap attestation di jaringan. Pembagian biaya dapat dikonfigurasi ditetapkan oleh governance menentukan ekonomi operator. Penerimaan operator diatur oleh kerangka governance protokol menentukan siapa yang sama sekali mendapatkan biaya. Sekarang lihat siapa yang memegang NEWT. Operator mempertaruhkan NEWT Operator mendapatkan biaya Operator diharuskan memegang NEWT untuk ikut serta. Jika operator memiliki kepemilikan NEWT yang tidak proporsional dibanding pemegang token lain, mereka memiliki pengaruh yang tidak proporsional atas suara governance yang menetapkan ambang batas kuorum dan pembagian biaya mereka sendiri. Bukan berarti itu hal yang aneh kebanyakan governance proof of stake punya versi masalah seperti ini Validator di jaringan lain memberikan suara pada parameter yang memengaruhi ekonomi validator. #newt Bukan berarti itu juga sebuah kekurangan kepemilikan NEWT yang membuat operator “punya kulit dalam permainan” bisa menyelaraskan kepentingan mereka dengan kesehatan jangka panjang jaringan, bukan ekstraksi jangka pendek. #NEWT Yang belum saya putuskan adalah apakah Newton telah merancang mekanisme spesifik untuk mencegah operator secara kolektif memilih untuk menurunkan ambang batas kuorum sehingga mengurangi beban operasional mereka sendiri dengan cara yang diam-diam merusak keamanan jaringan. #shareyouropinion $HMSTR $LAB @NewtonProtocol $NEWT #Newt
Dinamika kekuasaan governance siapa yang mengendalikan ambang batas kuorum pembagian biaya penerimaan operator

Bagian yang tidak pernah ditanyakan orang dalam governance Newton adalah siapa sebenarnya yang mengendalikan parameter yang paling penting.

Tiga jalur governance kebijakan standar penerimaan operator peningkatan protokol Fine yang hilang dari diskusi adalah apa yang sebenarnya diatur oleh jalur-jalur tersebut.

Ambang batas kuorum dapat dikonfigurasi per tugas ditetapkan oleh governance menentukan keamanan ekonomi setiap attestation di jaringan.

Pembagian biaya dapat dikonfigurasi ditetapkan oleh governance menentukan ekonomi operator.
Penerimaan operator diatur oleh kerangka governance protokol menentukan siapa yang sama sekali mendapatkan biaya.
Sekarang lihat siapa yang memegang NEWT.

Operator mempertaruhkan NEWT Operator mendapatkan biaya Operator diharuskan memegang NEWT untuk ikut serta. Jika operator memiliki kepemilikan NEWT yang tidak proporsional dibanding pemegang token lain, mereka memiliki pengaruh yang tidak proporsional atas suara governance yang menetapkan ambang batas kuorum dan pembagian biaya mereka sendiri.

Bukan berarti itu hal yang aneh kebanyakan governance proof of stake punya versi masalah seperti ini Validator di jaringan lain memberikan suara pada parameter yang memengaruhi ekonomi validator.
#newt
Bukan berarti itu juga sebuah kekurangan kepemilikan NEWT yang membuat operator “punya kulit dalam permainan” bisa menyelaraskan kepentingan mereka dengan kesehatan jangka panjang jaringan, bukan ekstraksi jangka pendek.
#NEWT
Yang belum saya putuskan adalah apakah Newton telah merancang mekanisme spesifik untuk mencegah operator secara kolektif memilih untuk menurunkan ambang batas kuorum sehingga mengurangi beban operasional mereka sendiri dengan cara yang diam-diam merusak keamanan jaringan.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt
Terverifikasi
Ada sebuah dataset dalam whitepaper yang kebanyakan orang lewati: survei terhadap 166 jaringan blockchain. Enam belas di antaranya memiliki kemampuan pembekuan aset bawaan. Sembilan belas lainnya bisa mengaktifkannya dengan perubahan minimal. Tiga puluh lima jaringan di mana permissionless bersifat kondisional. Newton menggunakan ini untuk membingkai masalah inti: kontrol level UI tidak cukup, tetapi asumsi bahwa jalur blockchain bersifat netral juga tidak cukup. Jaringan yang memiliki kemampuan pembekuan dapat menegakkan kepatuhan dengan cara yang tidak transparan dan dikendalikan oleh siapa pun yang memegang otoritas pembekuan, tanpa akuntabilitas kriptografis. Respons Newton adalah penegakan di lapisan kebijakan, bukan di lapisan protokol. Logika otorisasi dapat diaudit dalam Rego. Rangkaian operator terdesentralisasi. Bukti kepatuhan dicatat di onchain. Ini tidak mencegah sebuah jaringan membekukan aset, tetapi membuat keputusan kepatuhan dapat dipisahkan dari protokol dan tetap dapat diaudit, bahkan ketika rantainya tidak netral. Bukan solusi yang lengkap. Ada lapisan akuntabilitas yang berbeda di atas masalah tersebut. #NEWT Saya benar-benar berpikir data pembekuan itu mengubah cara Newton memecahkan masalah: bukan sekadar menambahkan kepatuhan ke jalur permissionless, melainkan membuat kepatuhan transparan ketika jalur tersebut sendiri mungkin tidak. #newt Pertanyaannya adalah apakah lapisan kebijakan Newton memberikan akuntabilitas yang bermakna ketika rantai yang mendasarinya masih mempertahankan otoritas pembekuan sepihak, atau apakah bukti kepatuhan menjadi tidak relevan jika aset tetap bisa dibekukan. #ShareYourOpinion @NewtonProtocol $NEWT #Newt $LAB $HMSTR
Ada sebuah dataset dalam whitepaper yang kebanyakan orang lewati: survei terhadap 166 jaringan blockchain. Enam belas di antaranya memiliki kemampuan pembekuan aset bawaan.

Sembilan belas lainnya bisa mengaktifkannya dengan perubahan minimal.

Tiga puluh lima jaringan di mana permissionless bersifat kondisional.

Newton menggunakan ini untuk membingkai masalah inti: kontrol level UI tidak cukup, tetapi asumsi bahwa jalur blockchain bersifat netral juga tidak cukup.

Jaringan yang memiliki kemampuan pembekuan dapat menegakkan kepatuhan dengan cara yang tidak transparan dan dikendalikan oleh siapa pun yang memegang otoritas pembekuan, tanpa akuntabilitas kriptografis.

Respons Newton adalah penegakan di lapisan kebijakan, bukan di lapisan protokol. Logika otorisasi dapat diaudit dalam Rego. Rangkaian operator terdesentralisasi. Bukti kepatuhan dicatat di onchain. Ini tidak mencegah sebuah jaringan membekukan aset, tetapi membuat keputusan kepatuhan dapat dipisahkan dari protokol dan tetap dapat diaudit, bahkan ketika rantainya tidak netral.

Bukan solusi yang lengkap. Ada lapisan akuntabilitas yang berbeda di atas masalah tersebut.
#NEWT
Saya benar-benar berpikir data pembekuan itu mengubah cara Newton memecahkan masalah: bukan sekadar menambahkan kepatuhan ke jalur permissionless, melainkan membuat kepatuhan transparan ketika jalur tersebut sendiri mungkin tidak.
#newt
Pertanyaannya adalah apakah lapisan kebijakan Newton memberikan akuntabilitas yang bermakna ketika rantai yang mendasarinya masih mempertahankan otoritas pembekuan sepihak, atau apakah bukti kepatuhan menjadi tidak relevan jika aset tetap bisa dibekukan.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR
Yes — transparency matters
50%
No — freezing wins always
25%
Depends on jurisdiction
25%
Only with independent ops
0%
4 Voting • Voting ditutup
Bagian routing fee milik Babylon memiliki satu baris spesifik yang layak dibaca dua kali Lelang otomatis di On-Chain di mana fee yang didenominasi dalam BTC dilelang untuk BABY, dan BABY yang dibelanjakan oleh pemenang akan dibakar secara programatis. Tidak ada diskresi treasury. Tidak ada komite yang memutuskan berapa banyak yang dibakar atau kapan. Hanya lelang mekanis yang terikat langsung pada pemakaian Protokol. Itu pilihan desain yang spesifik, bukan klaim generik tentang tokenomics deflationer. Saat aktivitas Trustless Bitcoin Vaults (TBV) tumbuh—lebih banyak vault dibuat, lebih banyak pinjaman berbasis BTC, lebih banyak penebusan—maka fee yang dihasilkan dalam BTC akan dirutekan melalui lelang ini, dan BABY dihapus dari suplai sebagai fungsi langsung dari penggunaan nyata, bukan jadwal emisi tetap. Saya tidak mengatakan ini menjamin apa pun tentang nilai token. Pembakaran yang terhubung dengan penggunaan masih bergantung pada penggunaan yang benar-benar terjadi dalam skala yang berarti, dan whitepaper secara eksplisit menyatakan bahwa struktur fee dan aturan staking tetap berada dalam desain yang aktif dan tunduk pada persetujuan tata kelola. Saya juga tidak mengatakan ini detail kecil. Mengaitkan mekanisme pembakaran token dengan penggunaan protokol yang telah ditunjukkan, bukan dengan janji pemasaran atau jadwal tetap, adalah sinyal yang lebih jujur untuk dipantau dibanding kebanyakan klaim tokenomics di ruang ini. Yang belum saya selesaikan adalah apakah mekanisme lelang ini sudah aktif pada deployment langsung mana pun atau apakah mekanisme ini masih salah satu usulan yang masih dalam diskusi desain, bersama kerangka routing fee lainnya. @babylonlabs_io $BABY #baby #ShareYourOpinion $BANK $DEXE
Bagian routing fee milik Babylon memiliki satu baris spesifik yang layak dibaca dua kali
Lelang otomatis di On-Chain di mana fee yang didenominasi dalam BTC dilelang untuk BABY, dan BABY yang dibelanjakan oleh pemenang akan dibakar secara programatis.

Tidak ada diskresi treasury. Tidak ada komite yang memutuskan berapa banyak yang dibakar atau kapan. Hanya lelang mekanis yang terikat langsung pada pemakaian Protokol.

Itu pilihan desain yang spesifik, bukan klaim generik tentang tokenomics deflationer. Saat aktivitas Trustless Bitcoin Vaults (TBV) tumbuh—lebih banyak vault dibuat, lebih banyak pinjaman berbasis BTC, lebih banyak penebusan—maka fee yang dihasilkan dalam BTC akan dirutekan melalui lelang ini, dan BABY dihapus dari suplai sebagai fungsi langsung dari penggunaan nyata, bukan jadwal emisi tetap.

Saya tidak mengatakan ini menjamin apa pun tentang nilai token. Pembakaran yang terhubung dengan penggunaan masih bergantung pada penggunaan yang benar-benar terjadi dalam skala yang berarti, dan whitepaper secara eksplisit menyatakan bahwa struktur fee dan aturan staking tetap berada dalam desain yang aktif dan tunduk pada persetujuan tata kelola.

Saya juga tidak mengatakan ini detail kecil. Mengaitkan mekanisme pembakaran token dengan penggunaan protokol yang telah ditunjukkan, bukan dengan janji pemasaran atau jadwal tetap, adalah sinyal yang lebih jujur untuk dipantau dibanding kebanyakan klaim tokenomics di ruang ini.

Yang belum saya selesaikan adalah apakah mekanisme lelang ini sudah aktif pada deployment langsung mana pun atau apakah mekanisme ini masih salah satu usulan yang masih dalam diskusi desain, bersama kerangka routing fee lainnya.

@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE
Masuk untuk menjelajahi konten lainnya
Bergabunglah dengan pengguna kripto global di Binance Square
⚡️ Dapatkan informasi terbaru dan berguna tentang kripto.
💬 Dipercayai oleh bursa kripto terbesar di dunia.
👍 Temukan wawasan nyata dari kreator terverifikasi.
Email/Nomor Ponsel