Eman098

ENA baru saja mengalami pergerakan besar naik 25% ke 0.1854, memantul kuat dari level terendah 0.1349 dari beberapa hari lalu. Ini adalah pembalikan berbentuk V yang klasik setelah tren penurunan yang melemah terus-menerus.

Namun, volume yang menceritakan kisah sebenarnya: batang hijau besar tepat saat harga menembus ke atas mengonfirmasi ini bukan false breakout—pembelian nyata benar-benar muncul. RSI(6) di 87 sedang berteriak kondisi overbought dalam jangka pendek, sementara RSI(14) di 74 turut menguatkan; jadi koreksi atau konsolidasi di sini sama sekali tidak mengejutkan. MACD baru saja beralih bullish dan histogramnya mulai berwarna hijau, yang mendukung pergerakan ini, tapi ini masih baru—belum matang.

Terus terang, ini terlihat seperti breakout momentum yang kuat yang layak untuk jeda. Mengejar di 0.1854 berisiko; menunggu pullback menuju 0.165 hingga 0.170 untuk entry terlihat lebih cerdas daripada membeli puncak candle ini.
$ENA

#dusk $DUSK @Dusk
Hal yang menarik perhatian saya saat menelusuri dokumentasi Dusk: hanya ada dua kontrak. Pada genesis hanya ada kontrak stake dan kontrak transfer. Semua yang lain—termasuk DuskVM dan DuskEVM—dibangun di atas keduanya.

Itu jumlah konsentrasi yang aneh untuk sebuah chain yang dibangun untuk menyelesaikan aset yang teregulasi. Jadi saya ingin memeriksa apa yang benar-benar dilakukan kedua kontrak ini dan apakah keduanya bisa diubah nanti.

Kontrak stake melacak provisioner: berapa yang distake, kapan reward matang, dan kapan slashing diterapkan. Kontrak transfer menangani saldo publik (Moonlight) dan saldo terselubung (Phoenix), dan ini satu-satunya tempat terjadinya perpindahan dana antarkontrak. Setiap environment eksekusi mengarah ke kontrak ini untuk penyelesaian dan ketersediaan data sesuai dokumentasi yang ada.

Mengapa ini penting: jika Anda membangun di atas DuskEVM atau menerbitkan aset melalui Dusk Trade, Anda tidak hanya mempercayai logika kontrak Anda sendiri. Anda mempercayai bahwa kedua kontrak genesis ini berperilaku dengan benar untuk jangka waktu yang tak terbatas, karena merekalah fondasi penyelesaian (settlement substrate) di bawah semuanya.

Berikut yang tidak bisa saya pastikan. Dokumentasi menjelaskan bahwa kontrak-kontrak ini direfaktorkan dari waktu ke waktu: kontrak staking dibangun ulang untuk memperbaiki masalah storage, dan kemudian pembaruan rekayasa mengubah struktur Event-nya. Jadi jelas keduanya tidak “beku” secara immutable sejak genesis.

Yang masih membingungkan bagi saya adalah jalur upgrade yang sebenarnya: apakah itu diskresioner (tim protokol merilis upgrade jaringan) atau ada langkah tata kelola on-chain yang formal yang dipilih oleh provisioner sebelum logika kontrak genesis diubah? Dokumentasi yang saya temukan menjelaskan apa yang dilakukan kontrak-kontrak tersebut, bukan bagaimana modifikasi terhadap kontrak-kontrak itu diberi wewenang.

Untuk sebuah chain yang memposisikan dirinya bagi penyelesaian institusional, pembedaan antara upgrade yang diotorisasi oleh tim vs upgrade yang disahkan oleh provisioner seharusnya terdokumentasi secara eksplisit di suatu tempat.

Apakah ada yang pernah melihat di mana <@Dusk > menetapkan proses Authorization yang sebenarnya untuk perubahan kontrak genesis?

$DUSK #dusk

#dusk $DUSK @Dusk
Yang menarik perhatian saya bukan pesan kepatuhan Dusk, melainkan temuan apa yang didapatkan oleh sebuah firma audit independen—terselip di dalam Dusk—sistem pembuktian yang mengamankan model transaksi terselubung Phoenix @Dusk pada DuskDS.

Mekanismenya: Phoenix menggunakan bukti PLONK agar sebuah pengeluaran bisa diverifikasi tanpa mengungkap saldo. Verifikator seharusnya memeriksa sekumpulan komitmen polinomial terhadap kunci verifikator tepercaya sebelum menerima setiap bukti sebagai valid.

Bagian yang ingin saya verifikasi: menurut penulisan sebuah firma keamanan, empat evaluasi selector tersebut sebenarnya tidak pernah dicek terhadap komitmen mereka—verifikator mengonsumsinya tanpa memvalidasi. Secara teori, celah ini bisa memungkinkan sebuah bukti palsu lolos sebagai sesuatu yang sah.

Mengapa ini penting: ini ada tepat di bawah kumpulan terselubung yang dimaksudkan agar aliran aset yang teregulasi bisa mewarisi privasi dari sistem tersebut. Bukti palsu dalam sistem catatan yang buram sulit ditangkap setelah kejadian—itulah inti dari proses penyelubungan.

Detail yang mungkin luput dari kebanyakan orang: perbaikannya masuk pada pertengahan Februari 2026, sebelum pengungkapan publik pada April, jadi sudah ditambal sebelum dieksploitasi berdasarkan yang telah dipublikasikan. Yang belum jelas bagi saya adalah apakah temuan ini tertangkap melalui peninjauan internal Dusk atau oleh pihak luar terlebih dahulu, serta bagaimana kronologi itu dikomunikasikan kepada mitra yang bergantung pada lapisan ini.
Apakah “Audited” berarti banyak jika perbaikannya lebih dulu dua bulan sebelum pengungkapan?

$DUSK #dusk

#dusk $DUSK @Dusk
Hal yang menarik perhatian saya tentang NPEX bukanlah angka €300M tersebut, melainkan fakta bahwa NPEX sudah memegang lisensi MTF, lisensi broker, dan lisensi ECSP sesuai aturan Belanda/EU, dan Dusk membangun langsung di atas tumpukan regulasi yang sudah ada itu—bukan meminta regulator untuk kerangka kerja kripto yang benar-benar baru. Jadi bagian yang ingin saya verifikasi adalah: bagaimana perdagangan onchain benar-benar tetap patuh dengan aturan kelayakan investor milik MTF tanpa adanya penjaga gerbang terpusat yang memeriksa setiap transaksi?

Mekanisme, sejauh yang dijelaskan dalam dokumentasi saat ini, berjalan melalui selective disclosure milik Citadel.
Seorang investor membuktikan status klaim tertentu—misalnya akreditasi residensi—dan penyelesaian KYC sebagai bukti pengetahuan nol (zero-knowledge proof) yang terikat pada dompet mereka tanpa mengungkap dokumen yang mendasarinya atau data pribadi. Pihak lawan atau logika protokol memverifikasi bukti tersebut, bukan data itu sendiri.

Mengapa ini penting untuk venue yang teregulasi secara khusus: NPEX tidak bisa secara legal mengizinkan sembarang orang memperdagangkan instrumen tertentu. Secara historis, itu berarti broker terpusat yang memeriksa ID sebelum setiap order. Di sini, kelayakan menjadi kredensial kriptografis yang dapat digunakan kembali, bukan pemeriksaan manual yang berulang—dan inilah yang membuat penyelesaian instan menjadi masuk akal untuk aset yang teregulasi, bukan sekadar klaim pemasaran.

Hal yang belum bisa saya konfirmasi dari dokumentasi saat ini adalah bagaimana pencabutan kredensial bekerja dalam praktiknya: jika status Kelayakan seseorang berubah (misalnya perubahan tempat tinggal, atau munculnya penanda sanksi), seberapa cepat hal itu merambat ke dompet yang memegang bukti yang dikeluarkan berdasarkan status lama? Dan apakah investor perlu membuktikan ulang, atau apakah penerbit bisa membatalkan bukti secara sepihak?

Kesenjangan itu—kesegaran (freshness) dari bukti disclosure dibanding ekspektasi regulator yang bersifat real-time—tampaknya menjadi uji sebenarnya apakah ini bisa diskalakan melewati satu pilot exchange. Siapa pun yang sudah melihat spesifikasi Citadel pasti tahu bagaimana pencabutan saat ini ditangani?

$DUSK #dusk @Dusk

#dusk $DUSK @Dusk
Yang menarik perhatian saya bukan sisi zero knowledge dari Dusk yang biasanya mendapat sorotan, melainkan detail yang lebih kecil tentang bagaimana sebuah blok benar-benar menjadi final.

Saya ingin melihat bagaimana Succinct Attestation, protokol konsensus proof-of-stake berbasis komite yang permissionless milik DuskDS, benar-benar mengonfirmasi sebuah transaksi, karena istilah instant settlement di bidang ini sering dipakai secara longgar.

Setiap putaran terdiri dari tiga langkah: seorang provisioner mengusulkan dan menyiarkan kandidat blok, sebuah komite memvalidasinya, lalu komite kedua meratifikasi validasi tersebut dan memfinalkan blok. Baru setelah kedua komite setuju, blok akan melangkah ke tahap berikutnya.

Yang menarik, @Dusk tidak memperlakukan finalitas sebagai satu peristiwa biner. Sebuah blok menjadi Accepted setelah melewati semua tiga langkah. Menjadi Confirmed setelah blok-blok berikutnya dibangun di atasnya. Menjadi Stable setelah terkubur cukup dalam, dan akhirnya menjadi Final—final yang deterministik dan dijamin secara kriptografis, artinya tidak bisa dibalik.

Untuk penyelesaian yang teregulasi, pembedaan bertahap ini lebih penting daripada kecepatan mentah. Seorang kustodian tidak hanya butuh transaksi yang cepat; ia butuh titik yang terdefinisi di mana “irreversibel” dapat dibuktikan, bukan sekadar diasumsikan.

Hal yang ingin saya klarifikasi adalah perilaku di bawah beban yang berkelanjutan. Dua komite terpisah yang menyetujui menambah langkah koordinasi yang tidak dilewati oleh rantai dengan proposer tunggal. Ketika kumpulan provisioner dan distribusi stake bertambah, apakah ratifikasi tetap cepat, atau koordinasi komite itu sendiri menjadi kendalanya?

Dokumen tersebut menguraikan fase-fase dan pembagian imbalan 70% untuk proposer, serta 5%/5% untuk komite validasi dan ratifikasi. Yang tidak dijelaskan secara jelas adalah adanya batas throughput di bawah kemacetan jaringan dunia nyata—hanya perilaku testnet.

Ada yang pernah melihat data pemilihan komite atau data waktu finalitas dari Dusk di bawah beban transaksi berkelanjutan yang nyata, bukan angka jaringan yang menganggur?

$DUSK #Dusk

#dusk $DUSK @Dusk
Saya bolak-balik antara dua dokumen Dusk yang menjelaskan privasi dengan cara yang benar-benar berbeda, dan celah di antara keduanya adalah cerita sesungguhnya.

Zedger, protokol aset teregulasi asli Dusk, berjalan secara native di DuskDS dan berbasis UTXO—model akuntansi yang sama seperti yang digunakan Bitcoin. l
diperluas untuk kepatuhan. Hedger, penerusnya, berjalan di DuskEVM dan mengambil rute yang berbeda: ia menggabungkan enkripsi homomorfik (ElGamal di atas kurva eliptik) dengan bukti pengetahuan nol di atas model hibrida UTXO/akun.

Yang menarik perhatian saya adalah apa yang sebenarnya dibeli dari kombinasi itu. Dalam komputasi HE, proses terjadi langsung pada saldo terenkripsi; tidak ada yang perlu mendekripsi nilai untuk menambah atau menguranginya. Bukti ZK kemudian memverifikasi bahwa komputasi dilakukan dengan benar tanpa mengungkap inputnya. Saldo dan jumlah transfer tetap terenkripsi dari ujung ke ujung, sementara jaringan tetap dapat mengonfirmasi bahwa tidak ada pemalsuan.

Bagian yang ingin saya pastikan: apakah ini menambah biaya apa pun dibandingkan dengan Zedger? Menurut materi @Dusk miliknya, model berbasis akun milik EVM tidak bisa memberikan anonimitas penuh seperti yang diberikan lapisan UTXO seperti Zedger. Hedger memberi Anda saldo yang rahasia dan dapat diaudit, bukan ketidak-terkaitan (unlinkability).

Jadi, trade-off- nya bukan privasi vs kepatuhan, melainkan privasi vs. permukaan (developer surface). Zedger mempertahankan anonimitas yang lebih kuat tetapi tetap native UTXO. Hedger mengorbankan sebagian dari itu demi alat tooling EVM yang siap pakai (plug and play).

Yang masih ingin saya ketahui: dalam sebuah instrumen teregulasi yang menyentuh keduanya—Zedger di DuskDS dan Hedger di DuskEVM—jaminan privasi yang mana sebenarnya yang berlaku saat penyelesaian (settlement)?

$DUSK #dusk

#dusk $DUSK @Dusk
Phoenix menyimpan bukti double spend dalam pohon Merkle dari catatan (notes), bukan dalam ledger akun. Belum ada saldo yang terlihat, namun tidak seorang pun bisa menghabiskan output yang sama dua kali. Saya ingin melihat bagaimana itu benar-benar bekerja.

Phoenix memperlakukan setiap unit sebesar @Dusk sebagai UTXO yang disebut note. Setiap note hidup sebagai sebuah hash di dalam pohon Merkle. Menghabiskan sebuah note tidak menghapusnya—begitulah cara kerja pohon-pohon ini. Sebagai gantinya, menghabiskan note menghasilkan nullifier: sebuah nilai yang diturunkan dari kunci rahasia note, yang muncul ke publik setelah digunakan. Jaringan tidak pernah mempelajari note mana yang berasal dari nullifier tersebut; jaringan hanya mengetahui bahwa itu sekarang menjadi tidak valid. Coba gunakan note yang sama lagi, dan nullifier duplikat akan langsung memberi tahu.

Desain itulah yang membuat Phoenix tetap terlindungi (shielded) sekaligus tetap bisa ditegakkan. Keuangan yang teregulasi tidak bisa mentoleransi penyelesaian (settlement) yang ambigu, dan nullifier memberi kepastian final yang deterministik tanpa mengekspos pengirim, penerima, atau jumlah. Sebuah view key memungkinkan pemilik untuk secara selektif membuktikan isi dari sebuah note, sehingga auditabilitas tidak sepenuhnya dikorbankan—itu hanya ditunda untuk pemegang kunci.

Hal yang belum sepenuhnya bisa saya pahami dari dokumentasi: bagaimana pertumbuhan himpunan nullifier dikelola dalam jangka panjang, dan seperti apa overhead pembuktiannya ketika pohon note berkembang di bawah volume institusional yang berkelanjutan, bukan kondisi pengujian.

Saya benar-benar penasaran: apakah ada angka throughput untuk pembuatan proof Phoenix di bawah beban settlement nyata, bukan benchmark testnet?

$DUSK #dusk

#dusk $DUSK @Dusk

Saya menggunakan dua profil browser yang berbeda untuk pekerjaan dan hal-hal pribadi, orangnya sama, tetapi akun-akun tersebut tidak pernah saling bersentuhan. Ada sesuatu yang mirip yang terjadi di bawah kap mesin pada lapisan privasi DuskEVM, dan desainnya lebih asing daripada yang saya bayangkan.

Hal yang menarik perhatian saya saat membaca spesifikasi Hedger: sebuah identitas pengguna dengan @Dusk yang beroperasi di sistem ini tidak memiliki satu alamat—mereka memiliki dua. Alamat EVM biasa untuk panggilan kontrak standar, dan alamat Hedger terpisah yang menyimpan saldo terenkripsi. Bagian menariknya adalah mengapa ini bukan sekadar pajangan.

Mekanismenya langkah demi langkah: saldo Hedger Anda dienkripsi menggunakan ElGamal pada kurva eliptik (skema homomorfik) sehingga jaringan dapat menambah dan mengurangi jumlah terenkripsi tanpa pernah mendekripsinya. Saat Anda mengirim transfer privat, Anda menyertakan bukti zero-knowledge untuk menunjukkan bahwa matematikanya sesuai: input cocok dengan output, dan tidak ada saldo negatif—tanpa mengungkap angka sebenarnya. Kepatuhan ditangani melalui allowlisting, bukan transparansi menyeluruh, jadi seorang auditor dapat diberi akses tanpa seluruh rantai mengamatinya.

Mengapa ini penting: ini benar-benar tradeoff yang berbeda dibanding sebagian besar pengaturan DeFi privat lainnya yang biasanya menyembunyikan transaksi, tetapi membuat Anda tetap bekerja di dalam satu identitas. Memisahkan identitas eksekusi publik dari identitas saldo rahasia berarti sebuah aplikasi bisa terhubung ke alat EVM normal untuk logika, dan hanya mengarahkan sisi uang melalui jalur terenkripsi.

Hal yang belum bisa sepenuhnya saya pahami dari dokumentasi: bagaimana dua alamat tersebut dimaksudkan untuk dihubungkan atau tidak dihubungkan pada lapisan UX—apakah pengikatan terjadi sekali saat setup dompet, per sesi, atau per kontrak?
Detail itu tampaknya yang menentukan apakah pengalaman ini terasa mulus atau seperti harus mengelola dua akun terpisah selamanya.

Ada yang benar-benar sudah menguji Hedger di Sepolia—bagaimana cara pengikatan itu bekerja dalam praktik?

$DUSK #dusk