$DUSK
I assumed the new Dusk Wallet was mainly a redesign of the existing web wallet.
Then I read the April developer-preview announcement and checked the repositories.
The old web wallet could interact with Dusk directly, but it was a standalone application. A dApp could not discover it, request a profile or ask it to sign a transaction through a standard connection flow.
That left a gap between Dusk contracts and actual users.
Dusk Connect fills the application side of that gap. It lets a dApp discover compatible wallets, request profile access and send user-approved actions through a shared provider interface.
The new Dusk Wallet sits on the other side.
It keeps the keys locally, shows the request and lets the user approve or reject it. Its first release includes public and Phoenix balances, shielding, private transfers, staking and DRC-20/DRC-721 asset flows.
One implementation detail stood out to me.
A dApp does not automatically receive everything after “Connect Wallet.” Public profile access, shielded receive addresses, message signing and transactions have separate request and approval flows. Permissions are also stored per origin.
That matters on Dusk because connecting to a financial application may involve more than exposing one public address.
But this is still a developer-preview story.
A connection standard becomes valuable only when real dApps adopt it and compatible wallets implement it correctly. One first-party wallet proves the interface can work; it does not yet prove a broad application ecosystem.
Dusk already had contracts, privacy and settlement.
Dusk Connect and the new wallet provide the missing interaction layer between them and the person clicking the button.
The milestone I would watch next is simple: a production DuskDS dApp where a user can connect, approve and complete a shielded or tokenized-asset action without leaving the application.
#dusk @Dusk
I assumed the new Dusk Wallet was mainly a redesign of the existing web wallet.
Then I read the April developer-preview announcement and checked the repositories.
The old web wallet could interact with Dusk directly, but it was a standalone application. A dApp could not discover it, request a profile or ask it to sign a transaction through a standard connection flow.
That left a gap between Dusk contracts and actual users.
Dusk Connect fills the application side of that gap. It lets a dApp discover compatible wallets, request profile access and send user-approved actions through a shared provider interface.
The new Dusk Wallet sits on the other side.
It keeps the keys locally, shows the request and lets the user approve or reject it. Its first release includes public and Phoenix balances, shielding, private transfers, staking and DRC-20/DRC-721 asset flows.
One implementation detail stood out to me.
A dApp does not automatically receive everything after “Connect Wallet.” Public profile access, shielded receive addresses, message signing and transactions have separate request and approval flows. Permissions are also stored per origin.
That matters on Dusk because connecting to a financial application may involve more than exposing one public address.
But this is still a developer-preview story.
A connection standard becomes valuable only when real dApps adopt it and compatible wallets implement it correctly. One first-party wallet proves the interface can work; it does not yet prove a broad application ecosystem.
Dusk already had contracts, privacy and settlement.
Dusk Connect and the new wallet provide the missing interaction layer between them and the person clicking the button.
The milestone I would watch next is simple: a production DuskDS dApp where a user can connect, approve and complete a shielded or tokenized-asset action without leaving the application.
#dusk @Dusk