I wanted to know what "Connect Wallet" actually gives a dApp access to, so I tested the real flow on Dario and Pieswap on Dusk testnet. On both, the first connection returned only the profile ID and public account. The popup was explicit: "The site will only be able to use the selected profile's public account." Only when I requested the shielded receive address did a second consent step appear, and only then did the response include shieldedAddress. The popup changed too, naming the "shareable shielded receive address." Both integrations showed the same sequence.
Here's the flip: I was treating "Connect Wallet" as one permission event. It isn't. The controlled test separated public-account access from sharing the shielded receive address at the point of consent.
That separation puts part of the minimum-disclosure boundary in the wallet's consent flow, not entirely on the user to manage. In both tests, clicking "Connect" alone never granted the shielded-address scope; a dApp had to cross a separate consent step to get it.
I also got one thing wrong while investigating. I thought the 132-character account string might hint at shielded access. It doesn't. Both dApps returned the same account format on baseline, while shieldedAddress stayed absent until the explicit request.
There's still one unresolved question. An earlier Dario mainnet session behaved differently, but I haven't reproduced it under the same controlled conditions, so I'm not calling it a leak. I can only say the public-only permission boundary held across the two testnet integrations I checked, not that it is guaranteed across every environment.
"A wallet connection should expose the scope you approved, not leave you to infer it."
What I'd want to see next: the same controlled test on mainnet with the same wallet version, clean permissions, and identical instrumentation, to see whether the boundary holds across environments.
#dusk $DUSK @Dusk
Here's the flip: I was treating "Connect Wallet" as one permission event. It isn't. The controlled test separated public-account access from sharing the shielded receive address at the point of consent.
That separation puts part of the minimum-disclosure boundary in the wallet's consent flow, not entirely on the user to manage. In both tests, clicking "Connect" alone never granted the shielded-address scope; a dApp had to cross a separate consent step to get it.
I also got one thing wrong while investigating. I thought the 132-character account string might hint at shielded access. It doesn't. Both dApps returned the same account format on baseline, while shieldedAddress stayed absent until the explicit request.
There's still one unresolved question. An earlier Dario mainnet session behaved differently, but I haven't reproduced it under the same controlled conditions, so I'm not calling it a leak. I can only say the public-only permission boundary held across the two testnet integrations I checked, not that it is guaranteed across every environment.
"A wallet connection should expose the scope you approved, not leave you to infer it."
What I'd want to see next: the same controlled test on mainnet with the same wallet version, clean permissions, and identical instrumentation, to see whether the boundary holds across environments.
#dusk $DUSK @Dusk
