Saya sempat mengira bahwa karena Moonlight dan Phoenix sejajar dalam halaman arsitektur, maka pengguna mainnet hari ini masih bisa memilih dengan bebas antara akun publik dan transaksi yang diblokir. Setelah saya meninjau kembali pembaruan Boreas untuk nomor @Dusk , saya menemukan bahwa yang benar-benar menentukan apakah sebuah institusi dapat Go-Live bukanlah diagram arsitekturnya, melainkan transaksi jenis apa yang benar-benar diterima oleh jaringan saat ini.
Pembaruan resmi tertulis sangat jelas: mainnet pada 10 Juni 2026, bersamaan dengan restart Boreas, berhenti menerima transaksi Phoenix baru pada blok `4,414,095`; testnet juga menonaktifkan setelah 7 Agustus, tepatnya pada blok `4,000,000`. Moonlight adalah model transaksi yang saat ini didukung.
Ketika dimasukkan ke dalam alur treasury institusi untuk membeli obligasi terbatas, perbedaannya langsung terlihat. Tim produk mungkin ingin menyembunyikan nilai pembayaran dan keterkaitan dengan akun, sambil tetap memberikan bukti kepada tempat/venue atau pihak audit sesuai kewenangan. Namun jika daftar Go-Live hanya menulis “Dusk mendukung Phoenix”, maka pada tahap akhir—di wallet, custody, dan sistem settlement—akan baru ditemukan: batas koneksi mainnet saat ini telah berubah, sehingga keluarga transaksi yang semula direncanakan tidak bisa diajukan.
Ini bukan berarti arah privasi Dusk hilang. Situs resmi masih mencantumkan privasi, selective disclosure, dan kontrak native ZK sebagai kemampuan inti, dan Hedger di DuskEVM juga menyediakan jalur EVM rahasia yang berbeda; tetapi pada hari yang sama, situs resmi menandai DuskEVM dan Hedger sama-sama sebagai `Testnet`. Karena itu, status penandaan harus dipisahkan untuk: Phoenix historis, kemampuan ZK native, Hedger testnet, serta workflow produksi yang tersedia bagi institusi; tidak bisa saling menggantikan hanya dalam satu kalimat “mendukung privasi”.
Materi resmi tidak dapat membuktikan bahwa workflow privasi mainnet sudah berjalan dalam skala besar, dan tidak juga dapat membuktikan bahwa kemampuan Hedger di testnet sudah memiliki SLA level institusi. Tidak ada jalan pintas: “fitur bernama lebih banyak berarti adopsi lebih kuat”.
Observasi ke depan hanya menyisakan empat tanda terima: jumlah jalur transaksi rahasia yang bisa dibuat baru di mainnet, jumlah dukungan wallet produksi dan custody, volume eksekusi kontrak rahasia yang benar-benar terjadi, serta tingkat keberhasilan disclosure terotorisasi. Di level token, saya tidak menambahkan narasi manfaat: titik sandaran dokumentasi $DUSK tetap pada biaya eksekusi pembayaran dan staking jaringan; hanya setelah jalur yang tersedia mampu menampung eksekusi yang berkelanjutan, barulah kita bicara tentang kebutuhan yang bisa diamati.
Menurut Anda langkah berikutnya yang paling penting adalah A memulihkan transaksi native yang diblokir, B mendorong Hedger menuju produksi, atau C terlebih dahulu mempublikasikan matriks ketersediaan yang akurat? #dusk
Pembaruan resmi tertulis sangat jelas: mainnet pada 10 Juni 2026, bersamaan dengan restart Boreas, berhenti menerima transaksi Phoenix baru pada blok `4,414,095`; testnet juga menonaktifkan setelah 7 Agustus, tepatnya pada blok `4,000,000`. Moonlight adalah model transaksi yang saat ini didukung.
Ketika dimasukkan ke dalam alur treasury institusi untuk membeli obligasi terbatas, perbedaannya langsung terlihat. Tim produk mungkin ingin menyembunyikan nilai pembayaran dan keterkaitan dengan akun, sambil tetap memberikan bukti kepada tempat/venue atau pihak audit sesuai kewenangan. Namun jika daftar Go-Live hanya menulis “Dusk mendukung Phoenix”, maka pada tahap akhir—di wallet, custody, dan sistem settlement—akan baru ditemukan: batas koneksi mainnet saat ini telah berubah, sehingga keluarga transaksi yang semula direncanakan tidak bisa diajukan.
Ini bukan berarti arah privasi Dusk hilang. Situs resmi masih mencantumkan privasi, selective disclosure, dan kontrak native ZK sebagai kemampuan inti, dan Hedger di DuskEVM juga menyediakan jalur EVM rahasia yang berbeda; tetapi pada hari yang sama, situs resmi menandai DuskEVM dan Hedger sama-sama sebagai `Testnet`. Karena itu, status penandaan harus dipisahkan untuk: Phoenix historis, kemampuan ZK native, Hedger testnet, serta workflow produksi yang tersedia bagi institusi; tidak bisa saling menggantikan hanya dalam satu kalimat “mendukung privasi”.
Materi resmi tidak dapat membuktikan bahwa workflow privasi mainnet sudah berjalan dalam skala besar, dan tidak juga dapat membuktikan bahwa kemampuan Hedger di testnet sudah memiliki SLA level institusi. Tidak ada jalan pintas: “fitur bernama lebih banyak berarti adopsi lebih kuat”.
Observasi ke depan hanya menyisakan empat tanda terima: jumlah jalur transaksi rahasia yang bisa dibuat baru di mainnet, jumlah dukungan wallet produksi dan custody, volume eksekusi kontrak rahasia yang benar-benar terjadi, serta tingkat keberhasilan disclosure terotorisasi. Di level token, saya tidak menambahkan narasi manfaat: titik sandaran dokumentasi $DUSK tetap pada biaya eksekusi pembayaran dan staking jaringan; hanya setelah jalur yang tersedia mampu menampung eksekusi yang berkelanjutan, barulah kita bicara tentang kebutuhan yang bisa diamati.
Menurut Anda langkah berikutnya yang paling penting adalah A memulihkan transaksi native yang diblokir, B mendorong Hedger menuju produksi, atau C terlebih dahulu mempublikasikan matriks ketersediaan yang akurat? #dusk
