Aadi33

Pengakuan Pasar #37

Sebenarnya aku tidak tahu kenapa aku menjual seperti yang kulakukan. Aku hanya melakukannya, lalu membuat alasan setelahnya.

Mulai menonton transaksi milikku sendiri seperti orang asing. Setup yang sama, rasa takut yang sama, titik keluar yang sama, setiap saat. Bukan analisis. Memori otot yang disamarkan sebagai keputusan.

Jadi aku mulai bertanya satu hal sebelum setiap transaksi: aku melakukan ini karena chart, atau karena transaksi terakhir yang menyakitiku.

Kebanyakan waktunya yang kedua.

Ternyata pasar tidak menguji prediksimu. Pasar menguji apakah kamu sudah bertemu dirimu sendiri.

$BTC $BNB $ZEC #crypto #BinanceSquare

Bitcoin ETF baru saja memutus rangkaian arus keluar selama 8 minggu dengan masuk bersih segar sebesar $197 juta.

Institusi diam-diam mulai mundur.

Satu minggu hijau belum mengonfirmasi tren baru, tapi ini tanda berarti pertama bahwa tekanan jual mungkin mulai mereda. Jika arus masuk ETF berlanjut pada minggu-minggu mendatang, sentimen pasar bisa bergeser jauh lebih cepat daripada yang diperkirakan kebanyakan orang.

Uang pintar tidak membunyikan bel di bagian bawah.

Ia terakumulasi sementara kerumunan masih memperdebatkan.

#bitcoin #BTC #etf #crypto #BinanceSquare
$BTC

Orang sering mengasumsikan tokenized real-world assets membawa model risiko yang sama seperti aset yang mereka representasikan; obligasi treasury yang tokenized berperilaku seperti obligasi treasury, hanya saja lebih cepat untuk dipindahkan.

Saya telah melihat bagaimana @NewtonProtocol frames menghitung risiko aktual dalam RWA, dan ternyata ini tidak benar-benar soal aset yang mendasarinya. Dokumentasi Newton mengarah pada admin key yang disusupi, manipulasi NAV atau oracle, serta mint yang tidak sah sebagai model ancaman yang sebenarnya—risiko yang muncul karena bagaimana token tersebut diterbitkan dan dikelola di onchain, bukan karena sesuatu tentang obligasi treasury itu sendiri.

Yang Newton terapkan adalah runtime invariants khusus untuk hal ini: batasan-batasan yang tetap berlaku terlepas dari siapa pun yang memegang admin key. Guardrails mint dan redeem memastikan hanya investor yang memenuhi syarat yang dapat berpartisipasi. Pemeriksaan integritas NAV melakukan verifikasi silang harga oracle terhadap batas toleransi. Ini bukan izin yang bisa diabaikan oleh siapa pun yang memiliki akses lebih tinggi; semua itu dicek pada level transaksi setiap saat.

Inilah yang sebenarnya membuat saya penasaran. Pada kebanyakan aset tokenized, jika seseorang mendapatkan admin key, pada dasarnya itu adalah seluruh permainan,.. mereka bisa mint tanpa otorisasi, menguras treasury, dan melewati kontrol apa pun yang seharusnya ada. Kuncinya adalah kontrol. Runtime invariants memutus tautan itu dengan sengaja, jadi mendapatkan key tidak otomatis berarti mendapatkan batasan juga.

Saya ingin tahu apakah invariants ini benar-benar sudah diuji terhadap skenario kompromi admin key yang nyata, atau apakah jaminan itu saat ini masih sebagian besar bersifat teoretis.

$NEWT #Newt
#BinanceTurns9



Apakah runtime invariants benar-benar dapat menghentikan admin key yang telah dikompromikan?

Orang-orang menganggap bahwa jika sebuah gateway menolak untuk memproses permintaan Anda, Anda akan terjebak.

Dari yang sudah saya baca, Newton memiliki mekanisme force inclusion yang memungkinkan aplikasi mengirimkan tugas langsung ke jaringan operator, alih-alih bergantung pada gateway. Jika itu benar, berarti gateway bukanlah titik kemacetan permanen (chokepoint) yang penting untuk ketahanan terhadap sensor.

Yang masih kurang jelas bagi saya adalah sisi praktisnya.

Menggunakan jalur itu kemungkinan berarti menangani pekerjaan yang biasanya disembunyikan/diabstraksikan oleh gateway, seperti perutean dan koordinasi dengan jaringan operator. Itu menimbulkan pertanyaan apakah force inclusion dapat benar-benar digunakan secara realistis oleh aplikasi rata-rata saat terjadi pemadaman atau peristiwa sensor, atau apakah ini lebih terutama digunakan oleh tim dengan infrastruktur yang besar.

Ada yang di sini sudah benar-benar menguji force inclusion dari ujung ke ujung? Saya ingin tahu seperti apa cara kerjanya dalam praktik dibandingkan dengan cara ia dijelaskan dalam dokumen.

@NewtonProtocol $NEWT #Newt
$ZEC $BTC

Kebanyakan orang sering mengira infrastruktur compliance untuk building team di institusi adalah semacam layanan RegTech yang spesialis, bergelut mendalam dengan pekerjaan regulasi namun baru dalam infrastruktur kripto skala konsumen. Biasanya itu asumsi yang aman untuk jenis produk seperti ini.

Namun, tidak demikian dengan @NewtonProtocol . Pengembang intinya adalah Magic Labs, dan saya baru menghubungkannya setelah menelusuri siapa sebenarnya yang berada di baliknya. Mereka membangun embedded wallet—jenis infrastruktur yang memungkinkan sebuah aplikasi mengonfirmasi pengguna tanpa pernah menampilkan seed phrase kepada mereka. Didukung PayPal Ventures, sudah berjalan pada skala nyata, lebih dari 57 juta wallet, lebih dari 200.000 pengembang, dan ini adalah lapisan wallet yang menjadi penggerak Polymarket.

Ini mengubah cara saya membaca risiko eksekusi Newton. Banyak infrastruktur kripto yang berfokus pada kepatuhan dibangun oleh tim yang kuat dari sisi regulasi, tetapi relatif baru dalam pengiriman pada skala yang benar-benar bermakna. Magic Labs justru sebaliknya—mereka sudah menyelesaikan distribusi dan keandalan untuk infrastruktur wallet secara spesifik. Newton bukan percobaan pertama tim baru dalam volume transaksi nyata; ini tim yang sudah mapan yang sedang merambah masalah yang berdekatan.

Yang ingin saya garis bawahi, embedded wallet dan otorisasi berbasis kebijakan adalah masalah rekayasa yang benar-benar berbeda. Infrastruktur wallet sebagian besar adalah manajemen kunci dan ketersediaan (uptime). Lapisan otorisasi Newton berarti konsensus operator terdesentralisasi, attestasi kriptografis, dan penyelesaian sengketa melalui zero-knowledge proofs. Keahlian yang terbukti di satu bidang tidak otomatis berpindah ke bidang lainnya.

Bukan kelemahan,.. hanya perlu ketepatan. Saya penasaran seberapa banyak desain operator dan konsensus Newton dipimpin oleh orang-orang yang punya rekam jejak di area spesifik tersebut, dibandingkan dengan sisi wallet tim yang memperluas ke area itu.

@NewtonProtocol $NEWT #Newt
#Polymarket #MagicLabs #zkProofs
$SXT $LAB

Orang sering mengira transfer stablecoin akan, entah terblokir atau tidak—lulus atau gagal—dengan satu pemeriksaan sederhana.

Namun, hal kepatuhan stablecoin Newton memiliki bagian atribusi terkait Travel Rule ini, dan itu bukan sesuatu yang sifatnya benar-benar “lulus atau gagal” seperti pemeriksaan penyaringan sanksi. Travel Rule berfokus pada informasi pengirim (originator) dan penerima (beneficiary) yang harus mengikuti transfer apabila melewati ambang batas tertentu: siapa yang mengirim, siapa yang menerimanya, dengan informasi tersebut dikaitkan secara aman dengan transfer tersebut.

Itu jenis pemeriksaan yang berbeda dari memblokir aktor berbahaya. Penyaringan sanksi bersifat biner: pengirim ada di daftar atau tidak. Travel Rule lebih tentang memastikan informasi yang diwajibkan benar-benar mengikuti transfer antar entitas yang teregulasi, bukan sekadar dicek sekali lalu dilupakan.

Yang sebenarnya menarik adalah ini hanya aktif untuk transfer yang memenuhi kualifikasi, di atas ambang batas apa pun yang memicu aturan tersebut. Jadi, kebanyakan transfer stablecoin berukuran retail tidak pernah menyentuhnya sama sekali—aturan ini dibangun untuk transfer yang cukup besar sehingga regulator benar-benar peduli pada jejak dokumennya.

Tapi saya masih belum jelas bagaimana ini bekerja lintas chain. Jika asal transfer ada di satu chain dan sedang dipindahkan ke chain tujuan melalui kumpulan operator tersinkronisasi milik Newton, apakah informasi originator ikut terbawa dengan bersih atau ada sesuatu yang hilang saat mengoordinasikan informasi identitas melewati batas itu. Atribusi hanya berarti sesuatu jika ia bertahan di sepanjang perjalanan, bukan hanya di hop pertama.

Saya penasaran apakah ada yang benar-benar sudah menguji transfer Travel Rule yang melintasi beberapa chain sekaligus dalam satu rangkaian, atau apakah sebagian besar pengujiannya masih dilakukan di dalam satu chain sejauh ini.

@NewtonProtocol $NEWT #Newt
$PYR $HMSTR

#RetailStockBuyingLowestSince2020 #JapanUrgesGPIFToBoostDomesticAssets #SKHynixCompletesRecordUSListing

Orang sering mengasumsikan bahwa brankas yang “dikurasi” berarti seseorang benar-benar memantau risikonya secara real time, sebuah tim yang mengawasi dasbor, siap bereaksi saat sesuatu terlihat janggal.

Namun, sebagian besar itu tidak seperti yang terjadi. “Dikurasi” biasanya hanya berarti seseorang menuliskan aturannya sekali. Penegakan aktual dilakukan transaksi demi transaksi—pada saat ada sesuatu yang mencoba bergerak—bukan melalui pemantauan latar belakang yang terus-menerus.

Saya menelusuri bagaimana <0-1>@NewtonProtocol </0-1> menangani ini khusus untuk kasus RWA dan penggunaan vault. Newton menawarkan policy packs, yaitu kumpulan modul Rego yang sudah tersusun sebelumnya, yang mencakup pemeriksaan integritas NAV dengan cara mengait silang harga oracle terhadap batas toleransi yang dikonfigurasi, beserta pagar pengaman kelayakan untuk mint dan redeem. Pemeriksaan ini dijalankan pada saat transaksi itu sendiri. Tidak ada kewajiban bagi siapa pun untuk menonton layar. Pemeriksa itu hanya “siap siaga” dan akan bekerja ketika <t-2/>dipicu.

Ini peningkatan nyata dibanding bergantung pada manusia yang menangkap masalah setelah kejadian, yang biasanya sudah terlambat. Tapi ini juga berarti perlindungan vault hanya sebaik batas toleransi dan aturan apa pun yang dikonfigurasi saat policy pertama kali ditulis. Jika pasar bergerak dengan cara yang tidak ada yang antisipasi ketika batas-batas tersebut ditetapkan, pemeriksaan tetap berjalan. Hanya saja bisa jadi pemeriksaan itu tidak lagi membandingkan terhadap ambang yang tepat.

Saya tidak mengatakan itu suatu kekurangan dalam desain. Hanya saja, ini jenis asumsi yang sebaiknya diketahui. Perlindungannya bukan pengawasan berkelanjutan; itu adalah aturan yang ditulis lebih dulu, ditegakkan secara konsisten, tetapi hanya setara dengan seberapa terakhir seseorang memperbaruinya.

Saya ingin tahu seberapa sering batas toleransi tersebut benar-benar ditinjau ulang setelah sebuah vault aktif, atau apakah biasanya ditetapkan sekali lalu dibiarkan begitu saja.
@NewtonProtocol $NEWT #Newt
$LAB $TAG #LABTokenDrops94% #USNaturalGasFallsOver6%

Orang-orang menganggap begitu sebuah sistem memilih kriptografinya, itu pada dasarnya sudah terkunci. Cabut nanti dan Anda sedang membangun setengah bagian lagi.

Tapi, lapisan privasi Newton tidak dibangun dengan cara itu. Ia menggunakan HPKE, yang sebenarnya terdiri dari tiga bagian yang bisa dipertukarkan dan disatukan: pertukaran kunci, penurunan/derivasi kunci, dan enkripsi itu sendiri. Karena komponennya modular (tidak menyatu), mengganti pertukaran kunci dengan yang post-kuantum ternyata hanya perubahan konfigurasi, bukan pembangun ulang.

Kedengarannya nyaman sampai Anda sadar HPKE memang dirancang untuk hal ini. Newton tidak menciptakan fleksibilitasnya; mereka hanya membangun di atas sesuatu yang sudah punya fitur itu. Dan NIST sudah menstandarkan penggantian post-kuantum sejak 2024, jadi komponennya sudah ada—siap dipasang kapan saja.

Reaksi pertama saya: komputer kuantum yang mematahkan enkripsi terasa seperti masalah suatu hari nanti, bukan sesuatu yang mendesak. Tapi itu semacam jebakannya: data terenkripsi yang diambil hari ini bisa disimpan lalu didekripsi belakangan begitu kemampuan itu sudah ada. Jadi migrasi yang murah nanti justru penting sekarang, meski belum terasa mendesak.

Yang terus saya pikirkan, meski demikian, ini hanya mencakup sisi enkripsi. Operator menandatangani attestation dengan BLS aggregate signatures, dan itu adalah sistem kriptografi yang benar-benar terpisah dari kunci-kunci enkripsi. Apa pun yang saya lihat belum membahas apa yang diperlukan untuk memigrasikan BLS itu sendiri. Berbeda dengan pertukaran kunci modular HPKE, tanda tangan tidak dirancang sebagai pengganti yang bisa langsung “ditukar” begitu saja, jadi saya perkirakan migrasinya akan jauh lebih rumit.

Jadi, "enkripsi kami quantum ready" dan "seluruh stack kami quantum ready" bukan klaim yang sama. Keduanya hanya terdengar mirip.

Saya penasaran apakah ada yang benar-benar sudah melihat seperti apa jalur post-kuantum untuk sisi tanda tangan di sini, atau apakah itu masih pertanyaan desain yang terbuka.

@NewtonProtocol $NEWT #Newt
$LAB $SKYAI
#quantum

Orang sering mengasumsikan bahwa setelah Anda terverifikasi, layanan yang menangani verifikasi benar-benar melihat dokumen Anda, mengevaluasinya, dan sekadar mengingat hasilnya.

Verifikasi identitas Newton dirancang secara berbeda. Verifikasi berjalan di dalam sebuah TEE, Trusted Execution Environment (Lingkungan Eksekusi Tepercaya), sehingga infrastruktur normal verifikator tidak pernah mengakses langsung data identitas yang mendasarinya. Verifikator menerima hasil verifikasi, bukan input mentahnya.

Itu adalah model keamanan yang berbeda dibandingkan enkripsi saja. Enkripsi melindungi data saat disimpan atau ditransmisikan, tetapi biasanya ada proses yang perlu mendekripsinya untuk melakukan verifikasi. TEE bertujuan untuk menjaga komputasi tersebut tetap terisolasi, sementara sistem host yang menjalankan perangkat tidak dapat memeriksa apa yang terjadi di dalam enclave.

Ini juga selaras dengan model identitas Newton yang lebih luas. Verifikator memvalidasi bukti kredensial tanpa mempelajari informasi pribadi yang mendasarinya. Tujuannya bukan hanya Menjauhkan data dari chain, tetapi juga menyembunyikannya dari verifikator.

Pertanyaan yang tersisa adalah soal kepercayaan. TEE mengurangi seberapa banyak Anda harus mempercayai Verifikator, tetapi tidak menghilangkan kepercayaan sepenuhnya. Sebagian kepercayaan itu bergeser ke implementasi TEE, vendor perangkat keras, firmware, serta proses attestation. TEE pernah mengalami kerentanan perangkat keras dan side channel yang nyata di masa lalu, jadi TEE lebih merupakan mekanisme pengurangan risiko daripada jaminan.

Yang paling ingin saya ketahui adalah model kegagalannya. Jika ditemukan kerentanan TEE yang serius pada perangkat keras yang Newton andalkan, apa yang terjadi pada kredensial yang sebelumnya terverifikasi melalui enclave-enclave tersebut? Apakah dampaknya hanya terbatas pada attestation di masa depan setelah kerentanan diketahui, atau sesi verifikasi sebelumnya juga bisa dianggap telah terkompromi? Dan jika itu terjadi, apakah ada proses pemulihan yang terdokumentasi, seperti mencabut enclave tepercaya, memutar kunci attestation, atau mengharuskan kredensial untuk diverifikasi ulang?
$NEWT @NewtonProtocol #Newt
$LAB $TLM #labcrashed

Orang-orang beranggapan bahwa begitu sebuah protokol menyatakan "privacy preserving" (menjaga privasi), pada dasarnya itu sudah keadaan final—seolah bagian tersulitnya sudah selesai dan sisanya tinggal detail implementasi.

Tapi tidak benar demikian dalam rencana jangka panjang Newton. Ada satu bagian penuh di whitepaper yang membahas fully homomorphic encryption (FHE), yang pada dasarnya adalah versi ideal dari hal ini: menjalankan komputasi kebijakan langsung pada data yang dienkripsi tanpa pernah mendekripsinya sama sekali pada titik mana pun. Tidak ada langkah threshold decryption. Tidak ada data plaintext yang terekspos selama evaluasi.

Namun sekarang ini, semuanya baru dicantumkan sebagai arah riset. Belum dibangun. Terobosan FHE awal dari Craig Gentry terjadi pada tahun 2009, dan bahkan sampai hari ini kinerjanya masih jauh—hingga berorde-orde magnitudo—lebih lambat daripada komputasi pada data biasa (plaintext). Untuk use case Newton, yang sebagian besar berupa pemeriksaan boolean dan perbandingan berbasis ambang (threshold comparisons), whitepaper menyebutkan bahwa pendekatannya berada di ujung yang lebih rendah dari kisaran tersebut, tapi itu tetap masih jauh dari sesuatu yang praktis untuk produksi.

Jadi ada roadmap panjang di antara kondisi model privasi yang benar-benar sudah ada saat ini dan apa yang dikatakan whitepaper bahwa hal itu akan dituju pada akhirnya. Versi saat ini bergantung pada threshold decryption, yang berarti data didekripsi selama evaluasi kebijakan, alih-alih tetap dienkripsi end-to-end. Lapisan MPC setelahnya bertujuan untuk menghindari rekonstruksi plaintext selama evaluasi. FHE setelah itu akan memungkinkan kebijakan itu sendiri dievaluasi langsung pada data terenkripsi, sehingga menghilangkan kebutuhan akan MPC yang interaktif.

Cukup pantas juga karena mereka secara terbuka mengakui ini riset multi tahun, bukan berpura-pura bahwa itu sudah dekat. Tapi itu juga berarti ketika orang membaca "privacy preserving," ada baiknya menanyakan model privasi seperti apa yang mereka dapatkan hari ini dibandingkan dengan model yang coba dicapai oleh roadmap.

Penasaran, berapa banyak orang yang benar-benar menggunakan ini yang tahu ada perbedaan di antara dua hal itu, atau apakah semuanya hanya dibaca sebagai satu jaminan privasi yang menyeluruh.

@NewtonProtocol $NEWT #Newt
$LAB $TLM

Orang sering berasumsi bahwa begitu sebuah smart contract dideploy, aturannya sudah cukup untuk menjaga pengguna dan aset tetap aman. Untuk protokol yang mengelola modal yang bernilai besar, banyak pengamanan penting masih berada di luar blockchain.

Saya sedang melihat bagaimana @NewtonProtocol mendekatinya. Alih-alih mengandalkan daftar periksa offchain atau pengawasan manual, ia memungkinkan kebijakan diterapkan secara onchain sebelum sebuah transaksi mencapai penyelesaian (settlement). Kebijakan tersebut dapat mencakup kepatuhan, identitas, keamanan, dan risiko—sehingga menjadi bagian dari alur eksekusi, bukan sekadar pemikiran belakangan.

Hal ini mengubah komprominya. Alih-alih mempercayai setiap aplikasi untuk mengimplementasikan dan memelihara kontrolnya sendiri, protokol dapat mereferensikan lapisan otorisasi yang sama (common) yang mengevaluasi transaksi terhadap kebijakan aktif sebelum transaksi tersebut berlanjut. Secara teori, ini membuat penegakan lebih konsisten di antara berbagai aplikasi.

Bagian yang menarik adalah manajemen kebijakan dari waktu ke waktu. Kondisi risiko berubah, kebutuhan kepatuhan berkembang, dan ancaman keamanan muncul tanpa peringatan. Tantangannya bukan hanya menegakkan kebijakan secara onchain, tetapi juga memperbaruinya tanpa menimbulkan ketidakpastian tentang aturan mana yang aktif saat sebuah transaksi diotorisasi.

Saya tidak mengatakan itu sebuah kekurangan. Itu hanya jenis asumsi desain yang memang layak untuk diperhatikan. Lapisan otorisasi hanya seberguna keandalan dan transparansi kebijakan yang ditegakkannya.

Saya ingin tahu bagaimana Newton berencana menyeimbangkan pembaruan kebijakan yang cepat dengan kebutuhan akan keputusan otorisasi yang dapat diprediksi dan dapat diaudit.

@NewtonProtocol $NEWT #Newt
$TLM $VANRY
#SKHynixToIssue177.9MillionADSs