$TRUMP +36%, MAGMA +29%, $ZEC +23%… 😂

I’ve been holding my Polygon campaign rewards for the last 6 months, waiting for that one good pump. 😭

originally thought connecting a wallet to a dApp was basically one permission.

The user connects, the application sees the account, and every later action flows through that relationship.

the more i looked into the new @Dusk_Foundation Wallet, the more it seemed like connecting is only the beginning of the permission model.

Through $DUSK Connect, a dApp can request profile access, signatures, transactions, contract calls, or a shielded receive address.

But requesting an action does not give the application the user’s keys.

The keys stay local. Dusk says extension builds protect them using PBKDF2 and AES-GCM, while native builds use Stronghold with Argon2. The wallet also includes auto-lock, failed-unlock backoff, and permissions scoped to each requesting origin. #dusk

That changed how i think about dApp access.
A connected site can be allowed to request an action without gaining the authority to execute it silently.

The wallet remains the approval boundary.
What got my attention wasnt only the local key storage.

Its how much security now depends on what the approval screen communicates.
A private key can remain protected while the user still approves a misleading contract call, unreadable message, or unexpected account request. Per-origin permissions restrict which site receives access, but they cannot prove every request from that site is safe.

The wallet repository separates approvals for transactions, readable and opaque messages, authentication signing, contract calls, and shielded addresses.

But Dusk Connect and the new Wallet were introduced for developer preview, so this permission experience still has to prove itself across real dApps and real user behaviour.

Does keeping keys local and permissions per origin create the right security boundary, or will the clarity of each approval screen matter more than the connection standard underneath it??