Binance Square
#shareyourvote

shareyourvote

2,411 penayangan
10 Berdiskusi
Mirza_X_Mustafa
·
--
Setiap brankas di Trustless Bitcoin Vaults (TBV) menyisihkan sekitar $93 nilai BTC sebagai challenge bond. Kebanyakan orang tidak akan pernah melihat uang itu ke mana pun; uang itu hanya mengendap di sana dan kembali lagi ketika brankas ditutup. @babylonlabs_io $BABY Jadi apa gunanya. Intinya, tantangan harus benar-benar memerlukan biaya agar sistem bisa berjalan. Jika membantah klaim itu gratis, orang-orang bisa membuat spam challenge palsu sepanjang hari hanya untuk mengganggu orang lain. Dan jika berbohong itu gratis di sisi lain, tidak ada alasan bagi siapa pun untuk tetap jujur. Ini pada dasarnya logika yang sama seperti uang deposit yang bisa dikembalikan yang Anda setorkan sebelum menyewa peralatan. Anda hampir tidak pernah kehilangannya, tapi fakta bahwa itu bisa saja hilang adalah hal yang menjaga semuanya tetap adil bagi semua pihak yang terlibat. #ShareYourVote $KOMA $BANK #baby
Setiap brankas di Trustless Bitcoin Vaults (TBV) menyisihkan sekitar $93 nilai BTC sebagai challenge bond. Kebanyakan orang tidak akan pernah melihat uang itu ke mana pun; uang itu hanya mengendap di sana dan kembali lagi ketika brankas ditutup.
@BabylonLabs_io $BABY
Jadi apa gunanya.

Intinya, tantangan harus benar-benar memerlukan biaya agar sistem bisa berjalan. Jika membantah klaim itu gratis, orang-orang bisa membuat spam challenge palsu sepanjang hari hanya untuk mengganggu orang lain. Dan jika berbohong itu gratis di sisi lain, tidak ada alasan bagi siapa pun untuk tetap jujur.

Ini pada dasarnya logika yang sama seperti uang deposit yang bisa dikembalikan yang Anda setorkan sebelum menyewa peralatan. Anda hampir tidak pernah kehilangannya, tapi fakta bahwa itu bisa saja hilang adalah hal yang menjaga semuanya tetap adil bagi semua pihak yang terlibat.
#ShareYourVote
$KOMA $BANK
#baby
Challenge bonds work
0%
Refundable security model
100%
Anti-spam mechanism
0%
Need more incentives
0%
1 Voting • Voting ditutup
Belum sepenuhnya yakin harus menafsirkan yang ini. Inflasi tahunan BABY dipotong dari 8% menjadi 5,5% pada November lalu, bersamaan dengan peningkatan (upgrade) yang memperkenalkan Staking BTC BABY CO (20.000 BABY per 1 BTC untuk reward tambahan). Upgrade yang sama juga membawa dua perubahan lainnya. Apakah pemotongan inflasi ini dimaksudkan untuk menyeimbangkan permintaan BABY baru dari CoStaking, atau ini sebenarnya perubahan yang tidak terkait yang kebetulan baru saja dirilis bersamaan? Dan apakah semua ini ada hubungannya dengan cara biaya dari Trustless Bitcoin Vaults (TBV) nantinya dialirkan ke BABY burns, atau itu jalur yang sama sekali terpisah? Sedang mencoba mencari tahu apakah ada satu cerita tokenomik yang terkoordinasi di sini, atau hanya dua proposal tata kelola (governance) yang secara kebetulan dikirim pada waktu yang sama. $KOMA $BANK #ShareYourVote @babylonlabs_io $BABY #baby
Belum sepenuhnya yakin harus menafsirkan yang ini. Inflasi tahunan BABY dipotong dari 8% menjadi 5,5% pada November lalu, bersamaan dengan peningkatan (upgrade) yang memperkenalkan Staking BTC BABY CO (20.000 BABY per 1 BTC untuk reward tambahan). Upgrade yang sama juga membawa dua perubahan lainnya.

Apakah pemotongan inflasi ini dimaksudkan untuk menyeimbangkan permintaan BABY baru dari CoStaking, atau ini sebenarnya perubahan yang tidak terkait yang kebetulan baru saja dirilis bersamaan? Dan apakah semua ini ada hubungannya dengan cara biaya dari Trustless Bitcoin Vaults (TBV) nantinya dialirkan ke BABY burns, atau itu jalur yang sama sekali terpisah?

Sedang mencoba mencari tahu apakah ada satu cerita tokenomik yang terkoordinasi di sini, atau hanya dua proposal tata kelola (governance) yang secara kebetulan dikirim pada waktu yang sama.
$KOMA $BANK
#ShareYourVote
@BabylonLabs_io $BABY #baby
Coordinated tokenomics
0%
Two separate changes
100%
Need more context
0%
Burn link matters most
0%
1 Voting • Voting ditutup
Terverifikasi
Mencari daftar lengkap poin pembahasan untuk mengetahui hal-hal yang seharusnya didukung oleh Trustless Bitcoin Vaults (TBV) dan dua di antaranya menghentikan kartu kredit serta asuransi saya. Peminjaman stablecoin, perps—semuanya mendapatkan bagian desain yang sebenarnya di whitepaper. Architecture, workflows, Benefits—semuanya dijelaskan. Kartu kredit dan asuransi muncul dalam daftar Aplikasi, tetapi BTC collateral asli bisa jadi—namun tidak ada satu pun yang mendapatkan apa pun yang mendekati itu. Tidak ada yang dibahas di mana pun dalam Materi teknis. Dibandingkan dengan tiga use case yang dirancang, itu benar-benar sebuah Kesenjangan, bukan sekadar kurang detail. Produk kartu kredit membutuhkan hal-hal yang tidak dimiliki oleh lending: otorisasi instan, waktu settlement merchant, penanganan chargeback, dan lain-lain. Tidak ada itu yang muncul di bagian mana pun yang sudah saya baca. Tidak berarti tidak akan bisa bekerja pada akhirnya. Primitive vault yang mendasarinya cukup umum sehingga kemungkinan besar bisa dengan cara yang sama seperti yang sudah menjangkau lending, stablecoins, dan perps. Saya hanya mencatat bahwa “Kartu kredit dan asuransi” saat ini terdengar lebih seperti sebuah kategori yang tim yakini dapat dijangkau, ketimbang sebuah produk dengan mekanisme yang dipublikasikan. $BANK $KOMA #ShareYourVote @babylonlabs_io $BABY #baby
Mencari daftar lengkap poin pembahasan untuk mengetahui hal-hal yang seharusnya didukung oleh Trustless Bitcoin Vaults (TBV) dan dua di antaranya menghentikan kartu kredit serta asuransi saya.

Peminjaman stablecoin, perps—semuanya mendapatkan bagian desain yang sebenarnya di whitepaper. Architecture, workflows, Benefits—semuanya dijelaskan. Kartu kredit dan asuransi muncul dalam daftar Aplikasi, tetapi BTC collateral asli bisa jadi—namun tidak ada satu pun yang mendapatkan apa pun yang mendekati itu. Tidak ada yang dibahas di mana pun dalam Materi teknis.

Dibandingkan dengan tiga use case yang dirancang, itu benar-benar sebuah Kesenjangan, bukan sekadar kurang detail. Produk kartu kredit membutuhkan hal-hal yang tidak dimiliki oleh lending: otorisasi instan, waktu settlement merchant, penanganan chargeback, dan lain-lain. Tidak ada itu yang muncul di bagian mana pun yang sudah saya baca.

Tidak berarti tidak akan bisa bekerja pada akhirnya. Primitive vault yang mendasarinya cukup umum sehingga kemungkinan besar bisa dengan cara yang sama seperti yang sudah menjangkau lending, stablecoins, dan perps.

Saya hanya mencatat bahwa “Kartu kredit dan asuransi” saat ini terdengar lebih seperti sebuah kategori yang tim yakini dapat dijangkau, ketimbang sebuah produk dengan mekanisme yang dipublikasikan.
$BANK $KOMA
#ShareYourVote
@BabylonLabs_io $BABY #baby
Do You Agree With My Content
50%
You Don't Agree
17%
Already Know
0%
Comparison Gap-analysis
33%
6 Voting • Voting ditutup
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
Memetakan program Structured Selling yang terstruktur dari laporan Juni 2025 karena memiliki lebih banyak komponen yang berbeda dibandingkan yang disarankan insider saat menjual secara terjadwal, yaitu tujuh mekanisme terpisah yang bekerja bersama. Sertifikasi Pra-Adopsi: sebuah rencana hanya dapat diadopsi ketika individu tersebut tidak memiliki informasi non publik yang material pada saat itu. Masa Cooling Off: penjualan tidak dapat dimulai segera setelah adopsi rencana; jeda wajib membatasi setiap keunggulan informasi residu. Batas Frekuensi Penjualan: hanya penjualan pra-terjadwal yang berkala, tanpa penentuan waktu secara diskresioner. Batas Penjualan (Sale Caps): batas volume yang selaras mengenai seberapa banyak yang dapat dijual pada setiap penjualan yang dijadwalkan. Pembatasan Kelayakan: hanya token yang sudah vested penuh dan sudah terbuka yang memenuhi syarat; token yang terkunci atau belum vested dikecualikan sepenuhnya. Persyaratan Pelaksanaan: penjualan harus dilakukan melalui pihak ketiga independen melalui bursa yang disetujui atau meja OTC, bukan diarahkan sendiri. Klausul Penangguhan: administrator rencana dapat menghentikan rencana aktif selama peristiwa besar protokol, pemungutan suara tata kelola, peningkatan (upgrades), atau insiden keamanan untuk mencegah ketidaksesuaian waktu. Tujuh kontrol berbeda, masing-masing menutup celah yang berpotensi berbeda. Sertifikasi Pra-Adopsi dan Masa Cooling Off mengatasi asimetri informasi pada saat komitmen. Batas Frekuensi Penjualan dan Sale Caps mengatasi penentuan waktu secara diskresioner dan manipulasi volume. Saya sebenarnya berpikir ini adalah struktur yang benar-benar komprehensif, dimodelkan secara eksplisit pada rencana perdagangan 10b5-1 yang digunakan dalam kepatuhan insider trading perusahaan publik tradisional, yang disesuaikan untuk alokasi token. Masing-masing dari tujuh komponennya menargetkan cara tertentu di mana penjualan insider, jika tidak dibatasi, dapat menciptakan keunggulan informasi yang tidak adil atau berdampak pada pasar. Yang BELUM saya kembangkan adalah apakah program structured selling ini sudah benar-benar digunakan; apakah ada Kontributor Utama, Early Backers, atau kepemimpinan Foundation yang telah mengeksekusi penjualan di bawah program ini sejak periode cliff 12 bulan dimulai, atau apakah program ini tetap belum teruji dalam praktik karena vesting baru saja mulai membuka token. $LAB $EVAA #ShareYourVote @NewtonProtocol $NEWT #Newt
Memetakan program Structured Selling yang terstruktur dari laporan Juni 2025 karena memiliki lebih banyak komponen yang berbeda dibandingkan yang disarankan insider saat menjual secara terjadwal, yaitu tujuh mekanisme terpisah yang bekerja bersama.

Sertifikasi Pra-Adopsi: sebuah rencana hanya dapat diadopsi ketika individu tersebut tidak memiliki informasi non publik yang material pada saat itu.

Masa Cooling Off: penjualan tidak dapat dimulai segera setelah adopsi rencana; jeda wajib membatasi setiap keunggulan informasi residu. Batas Frekuensi Penjualan: hanya penjualan pra-terjadwal yang berkala, tanpa penentuan waktu secara diskresioner. Batas Penjualan (Sale Caps): batas volume yang selaras mengenai seberapa banyak yang dapat dijual pada setiap penjualan yang dijadwalkan.

Pembatasan Kelayakan: hanya token yang sudah vested penuh dan sudah terbuka yang memenuhi syarat; token yang terkunci atau belum vested dikecualikan sepenuhnya. Persyaratan Pelaksanaan: penjualan harus dilakukan melalui pihak ketiga independen melalui bursa yang disetujui atau meja OTC, bukan diarahkan sendiri. Klausul Penangguhan: administrator rencana dapat menghentikan rencana aktif selama peristiwa besar protokol, pemungutan suara tata kelola, peningkatan (upgrades), atau insiden keamanan untuk mencegah ketidaksesuaian waktu.

Tujuh kontrol berbeda, masing-masing menutup celah yang berpotensi berbeda.
Sertifikasi Pra-Adopsi dan Masa Cooling Off mengatasi asimetri informasi pada saat komitmen. Batas Frekuensi Penjualan dan Sale Caps mengatasi penentuan waktu secara diskresioner dan manipulasi volume.

Saya sebenarnya berpikir ini adalah struktur yang benar-benar komprehensif, dimodelkan secara eksplisit pada rencana perdagangan 10b5-1 yang digunakan dalam kepatuhan insider trading perusahaan publik tradisional, yang disesuaikan untuk alokasi token. Masing-masing dari tujuh komponennya menargetkan cara tertentu di mana penjualan insider, jika tidak dibatasi, dapat menciptakan keunggulan informasi yang tidak adil atau berdampak pada pasar.

Yang BELUM saya kembangkan adalah apakah program structured selling ini sudah benar-benar digunakan; apakah ada Kontributor Utama, Early Backers, atau kepemimpinan Foundation yang telah mengeksekusi penjualan di bawah program ini sejak periode cliff 12 bulan dimulai, atau apakah program ini tetap belum teruji dalam praktik karena vesting baru saja mulai membuka token.
$LAB $EVAA
#ShareYourVote
@NewtonProtocol $NEWT #Newt
DO YOU LIKE THIS
50%
I DONT LIKE THIS
50%
OR I CANT UNDERSTAND
0%
2 Voting • Voting ditutup
Terverifikasi
NewtonPermissions adalah nama yang baru pertama kali saya lihat minggu ini. Itulah yang Newton sebut sebagai kebijakan yang dapat digunakan kembali dalam laporan Q3 2025 sebelum terminologi saat ini ditetapkan. Kerangka yang dimaksud adalah kebijakan yang dapat digunakan kembali tertentu yang didefinisikan oleh pemilik aplikasi untuk diterapkan dan dibuktikan sebelum terjadi penetapan. Mekanisme inti yang sama dibahas secara mendalam dalam analisis sebelumnya dengan nama policy packs dan kebijakan Rego. Nama yang berbeda, konsep yang mendasari sama—pada tahap awal evolusi dokumentasi. Perlu dicatat apa yang tidak berubah di samping perubahan nama. Tiga entitas inti—Applications, Operators, dan Data Providers—adalah tiga peran yang sama yang ada dalam dokumentasi saat ini, hanya saja dijelaskan sedikit berbeda. Applications mendefinisikan kebijakan dan permintaan evaluasi. Operators menilai apakah intent mematuhi. Data Providers menyediakan masukan onchain dan offchain. Struktur itu tetap konsisten di sepanjang perubahan penamaan. Saya tidak mengatakan perubahan nama tidak berarti apa-apa. Terminologi berkembang seiring dokumentasi disempurnakan dan saat sebuah proyek bergerak dari nama kerja internal menuju bahasa produk yang ditujukan untuk publik. Namun, saya juga tidak mengatakan itu benar-benar tidak relevan. Siapa pun yang membaca pengungkapan awal Newton bersama dokumentasi saat ini perlu tahu bahwa NewtonPermissions dan kebijakan saat ini merujuk pada mekanisme yang sama; jika tidak, dokumen historis akan terbaca seperti sedang menjelaskan fitur lain yang berbeda dan tidak terkait. Yang belum saya kerjakan adalah kapan tepatnya istilah itu bergeser dari NewtonPermissions ke penamaan saat ini, atau apakah ada perubahan fungsional yang menyertai rename tersebut selain labelnya sendiri. $EVAA $LAB #ShareYourVote @NewtonProtocol $NEWT #Newt
NewtonPermissions adalah nama yang baru pertama kali saya lihat minggu ini. Itulah yang Newton sebut sebagai kebijakan yang dapat digunakan kembali dalam laporan Q3 2025 sebelum terminologi saat ini ditetapkan.

Kerangka yang dimaksud adalah kebijakan yang dapat digunakan kembali tertentu yang didefinisikan oleh pemilik aplikasi untuk diterapkan dan dibuktikan sebelum terjadi penetapan. Mekanisme inti yang sama dibahas secara mendalam dalam analisis sebelumnya dengan nama policy packs dan kebijakan Rego. Nama yang berbeda, konsep yang mendasari sama—pada tahap awal evolusi dokumentasi.

Perlu dicatat apa yang tidak berubah di samping perubahan nama.

Tiga entitas inti—Applications, Operators, dan Data Providers—adalah tiga peran yang sama yang ada dalam dokumentasi saat ini, hanya saja dijelaskan sedikit berbeda. Applications mendefinisikan kebijakan dan permintaan evaluasi. Operators menilai apakah intent mematuhi. Data Providers menyediakan masukan onchain dan offchain. Struktur itu tetap konsisten di sepanjang perubahan penamaan.

Saya tidak mengatakan perubahan nama tidak berarti apa-apa. Terminologi berkembang seiring dokumentasi disempurnakan dan saat sebuah proyek bergerak dari nama kerja internal menuju bahasa produk yang ditujukan untuk publik.

Namun, saya juga tidak mengatakan itu benar-benar tidak relevan. Siapa pun yang membaca pengungkapan awal Newton bersama dokumentasi saat ini perlu tahu bahwa NewtonPermissions dan kebijakan saat ini merujuk pada mekanisme yang sama; jika tidak, dokumen historis akan terbaca seperti sedang menjelaskan fitur lain yang berbeda dan tidak terkait.

Yang belum saya kerjakan adalah kapan tepatnya istilah itu bergeser dari NewtonPermissions ke penamaan saat ini, atau apakah ada perubahan fungsional yang menyertai rename tersebut selain labelnya sendiri.
$EVAA $LAB
#ShareYourVote
@NewtonProtocol $NEWT #Newt
Just a name change
0%
Same tech, new label
100%
Rename + new features
0%
Need more evidence
0%
1 Voting • Voting ditutup
Baca laporan Q4 2025 dua kali untuk daftar integrasi oracle karena ada yang TIDAK cocok saat putaran pertama. Newton sekarang memiliki dua oracle identitas berorientasi KYC yang terpisah: Persona dan Veriff, dan saya menduga sebuah protokol akan memutuskan hanya satu. Persona diumumkan pada Q1 2026. Veriff muncul di laporan Q4 2025, artinya sebenarnya mendahului Persona sekitar seperempat. Urutan ini penting: Veriff bukan tambahan redundan setelah Persona sudah ada. Persona yang datang kemudian. Jadi mengapa mempertahankan dua oracle verifikasi identitas yang melakukan pekerjaan serupa. Laporan tersebut membingkai model oracle Newton sebagai lapisan kebijakan netral di seluruh sistem yang beragam—bukan dukungan terhadap aplikasi tertentu. Bahasa penafian yang sama juga tercakup dalam analisis sebelumnya mengenai pembingkaian contoh yang bukan dukungan (non-endorsement). Jika dibaca sesuai pembingkaian itu: memiliki dua penyedia KYC BUKAN redundansi, melainkan opsionalitas. Penulis kebijakan yang menyusun tumpukan kepatuhan memilih vendor verifikasi identitas yang paling sesuai dengan hubungan yang sudah ada atau kebutuhan regulasinya: Veriff untuk standar dokumentasi yurisdiksi tertentu, Persona untuk yang lain—atau salah satu keduanya—tergantung vendor mana yang sudah memiliki kontrak dengan institusi tertentu. Saya justru berpikir ini mengubah cara membaca apa yang Newton integrasikan dengan pengumuman X: harus dipahami sebagai satu kesatuan secara kolektif, bukan satu per satu. Polanya bukan Newton memilih vendor KYC terbaik. Yang Newton lakukan adalah membangun sebuah menu, lalu penulis kebijakan memilih dari menu itu berdasarkan hubungan vendor yang sudah ada dan kebutuhan yurisdiksional mereka. Yang belum saya pecahkan adalah apakah data Persona dan Veriff dapat disusun (dikomposisikan) dalam satu kebijakan: apakah diperlukan kesepakatan di antara keduanya, atau menerima salah satu; atau apakah penulis kebijakan harus memilih tepat satu oracle identitas per kebijakan dan tidak bisa merujuk keduanya sekaligus. Menurut Anda, mengapa Newton mengintegrasikan keduanya—Persona dan Veriff? #ShareYourVote #VoteYourOpinion $DODO $XEC @NewtonProtocol $NEWT #Newt
Baca laporan Q4 2025 dua kali untuk daftar integrasi oracle karena ada yang TIDAK cocok saat putaran pertama. Newton sekarang memiliki dua oracle identitas berorientasi KYC yang terpisah: Persona dan Veriff, dan saya menduga sebuah protokol akan memutuskan hanya satu.

Persona diumumkan pada Q1 2026. Veriff muncul di laporan Q4 2025, artinya sebenarnya mendahului Persona sekitar seperempat. Urutan ini penting: Veriff bukan tambahan redundan setelah Persona sudah ada. Persona yang datang kemudian.

Jadi mengapa mempertahankan dua oracle verifikasi identitas yang melakukan pekerjaan serupa.

Laporan tersebut membingkai model oracle Newton sebagai lapisan kebijakan netral di seluruh sistem yang beragam—bukan dukungan terhadap aplikasi tertentu. Bahasa penafian yang sama juga tercakup dalam analisis sebelumnya mengenai pembingkaian contoh yang bukan dukungan (non-endorsement).

Jika dibaca sesuai pembingkaian itu: memiliki dua penyedia KYC BUKAN redundansi, melainkan opsionalitas. Penulis kebijakan yang menyusun tumpukan kepatuhan memilih vendor verifikasi identitas yang paling sesuai dengan hubungan yang sudah ada atau kebutuhan regulasinya: Veriff untuk standar dokumentasi yurisdiksi tertentu, Persona untuk yang lain—atau salah satu keduanya—tergantung vendor mana yang sudah memiliki kontrak dengan institusi tertentu.

Saya justru berpikir ini mengubah cara membaca apa yang Newton integrasikan dengan pengumuman X: harus dipahami sebagai satu kesatuan secara kolektif, bukan satu per satu. Polanya bukan Newton memilih vendor KYC terbaik. Yang Newton lakukan adalah membangun sebuah menu, lalu penulis kebijakan memilih dari menu itu berdasarkan hubungan vendor yang sudah ada dan kebutuhan yurisdiksional mereka.

Yang belum saya pecahkan adalah apakah data Persona dan Veriff dapat disusun (dikomposisikan) dalam satu kebijakan: apakah diperlukan kesepakatan di antara keduanya, atau menerima salah satu; atau apakah penulis kebijakan harus memilih tepat satu oracle identitas per kebijakan dan tidak bisa merujuk keduanya sekaligus.

Menurut Anda, mengapa Newton mengintegrasikan keduanya—Persona dan Veriff?
#ShareYourVote #VoteYourOpinion $DODO $XEC
@NewtonProtocol $NEWT #Newt
Vendor optionality
0%
Better security
100%
Regional compliance
0%
1 Voting • Voting ditutup
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