Senja baru saja meluncurkan wallet dan SDK, tapi kenapa mereka tidak melakukannya seperti yang dilakukan pasar—bagian ini layak dibaca
Sebagian besar yang sudah saya tulis tentang Senja selama kampanye ini berputar di sekitar protokol: penerbitan native, model privasi, dan mitra institusional. Tapi ada satu hal yang terus saya lewatkan—hal yang menentukan apakah suatu protokol benar-benar akan digunakan oleh pembangun sungguhan: developer experience.
Pada April 2026, Senja merilis beta dari Dusk Wallet dan Dusk Connect SDK. Ekstensi Chrome dan Firefox, satu codebase, mendukung akun publik dan terselubung (shielded) dalam satu antarmuka yang sama.
API penyedianya dimodelkan setelah EIP-1193, yaitu antarmuka persis yang digunakan MetaMask—akrab bagi kebanyakan pengembang Web3. Karena Senja tidak berbasis EVM, metode menggunakan awalan dusk_* , dan protokol discovery berbasis event, sehingga banyak wallet yang kompatibel bisa hidup berdampingan di halaman yang sama tanpa konflik.
Arsitektur drivernya adalah bagian yang paling berbeda: pengembang men-deploy sebuah smart contract bersama dengan “driver” yang pengguna instal di wallet agar bisa berinteraksi persis seperti yang dimaksudkan pengembang. Ini menyelesaikan masalah nyata: proof ZK awalnya membutuhkan prover keys yang ukurannya lebih dari 200MB. Tim itu menekannya hingga hanya beberapa KB dengan teknologi circuit descriptor.
Ini juga menjelaskan kenapa Senja tidak mengikuti tren embedded wallet yang dominan di 2026—di mana pengguna masuk memakai email atau Google dan sebuah wallet dibuat diam-diam di belakang layar oleh SDK. Model itu menempatkan pembuatan proof ZK pada server pihak ketiga. Dengan Senja, proof harus berjalan di sisi klien; Anda tidak bisa mendelegasikannya tanpa tetap menjaga model privasi.
Pertanyaan yang sedang saya renungkan: laju di mana pembangun sungguhan benar-benar melakukan deploy dApps akan menjadi metrik yang lebih jujur daripada benchmark protokol mana pun.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
Sebagian besar yang sudah saya tulis tentang Senja selama kampanye ini berputar di sekitar protokol: penerbitan native, model privasi, dan mitra institusional. Tapi ada satu hal yang terus saya lewatkan—hal yang menentukan apakah suatu protokol benar-benar akan digunakan oleh pembangun sungguhan: developer experience.
Pada April 2026, Senja merilis beta dari Dusk Wallet dan Dusk Connect SDK. Ekstensi Chrome dan Firefox, satu codebase, mendukung akun publik dan terselubung (shielded) dalam satu antarmuka yang sama.
API penyedianya dimodelkan setelah EIP-1193, yaitu antarmuka persis yang digunakan MetaMask—akrab bagi kebanyakan pengembang Web3. Karena Senja tidak berbasis EVM, metode menggunakan awalan dusk_* , dan protokol discovery berbasis event, sehingga banyak wallet yang kompatibel bisa hidup berdampingan di halaman yang sama tanpa konflik.
Arsitektur drivernya adalah bagian yang paling berbeda: pengembang men-deploy sebuah smart contract bersama dengan “driver” yang pengguna instal di wallet agar bisa berinteraksi persis seperti yang dimaksudkan pengembang. Ini menyelesaikan masalah nyata: proof ZK awalnya membutuhkan prover keys yang ukurannya lebih dari 200MB. Tim itu menekannya hingga hanya beberapa KB dengan teknologi circuit descriptor.
Ini juga menjelaskan kenapa Senja tidak mengikuti tren embedded wallet yang dominan di 2026—di mana pengguna masuk memakai email atau Google dan sebuah wallet dibuat diam-diam di belakang layar oleh SDK. Model itu menempatkan pembuatan proof ZK pada server pihak ketiga. Dengan Senja, proof harus berjalan di sisi klien; Anda tidak bisa mendelegasikannya tanpa tetap menjaga model privasi.
Pertanyaan yang sedang saya renungkan: laju di mana pembangun sungguhan benar-benar melakukan deploy dApps akan menjadi metrik yang lebih jujur daripada benchmark protokol mana pun.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
