I compared the Dusk Connect and new wallet documentation that were publicly released this year with @Dusk . I originally thought this was just “making another wallet.” But on closer inspection, the old web wallet lets users directly interact with the network—it isn’t a standard entry point for dApps: applications can’t uniformly discover wallets, request accounts, initiate signatures, or manage permissions. A contract can run, but that doesn’t mean ordinary users can seamlessly get in and use it.
Dusk Connect fills that missing layer of glue. It follows EIP-6963 for wallet discovery, provides RPC namespaces like dusk_requestAccounts and dusk_signMessage, and hands compatibility testing to wallet developers. The new first-party wallet is designed for browser extensions, desktop, and mobile—covering public/private transfers, shield/unshield, staking, claiming rewards, DRC-20, DRC-721, and dApp permissions. Keys stay on the local device: the extension uses PBKDF2 with AES-GCM, while the native side uses Stronghold and Argon2.
But the three words that are easiest for promo materials to gloss over here are “developer preview.” The Connect and wallet repos are already public, and the documentation shows a checkable implementation for the missing pieces. A preview doesn’t mean lots of dApps are already integrated, and it certainly doesn’t mean permission prompts, mobile UX, and recovery flows have been pressure-tested by real users. The front-end entry point just moves things from “can be developed” to “might actually be used.”
So now I’m observing $DUSK —not just watching TPS or new contracts, but also how many applications in the #dusk ecosystem truly connect to Connect, whether the signing flow involves fewer detours, and whether third-party wallets will follow suit. What do you think is hardest to fix for a new chain: the underlying performance, or this unglamorous but retention-defining wallet interface?
$AIO $ETH
Dusk Connect fills that missing layer of glue. It follows EIP-6963 for wallet discovery, provides RPC namespaces like dusk_requestAccounts and dusk_signMessage, and hands compatibility testing to wallet developers. The new first-party wallet is designed for browser extensions, desktop, and mobile—covering public/private transfers, shield/unshield, staking, claiming rewards, DRC-20, DRC-721, and dApp permissions. Keys stay on the local device: the extension uses PBKDF2 with AES-GCM, while the native side uses Stronghold and Argon2.
But the three words that are easiest for promo materials to gloss over here are “developer preview.” The Connect and wallet repos are already public, and the documentation shows a checkable implementation for the missing pieces. A preview doesn’t mean lots of dApps are already integrated, and it certainly doesn’t mean permission prompts, mobile UX, and recovery flows have been pressure-tested by real users. The front-end entry point just moves things from “can be developed” to “might actually be used.”
So now I’m observing $DUSK —not just watching TPS or new contracts, but also how many applications in the #dusk ecosystem truly connect to Connect, whether the signing flow involves fewer detours, and whether third-party wallets will follow suit. What do you think is hardest to fix for a new chain: the underlying performance, or this unglamorous but retention-defining wallet interface?
$AIO $ETH
