Digging into $DUSK confidential transactions, one line in #Dusk updated whitepaper stopped me: Phoenix was deliberately changed so the receiver can always identify the sender. @Duskfoundation calls this a compliance fix, not a leak — #dusk's Phoenix model was never built for anonymity.
So the shielding is narrower than it sounds. Notes, nullifiers, proofs — all of it hides sender, receiver, and amount from public chain observers. But the counterparty was never meant to be in the dark. It's a disclosure boundary drawn around specific parties, not a blackout.
What changed for me was treating "shielded" as binary — private or not. It isn't. Moonlight sits next to Phoenix as the fully public account model, and a convert function moves value between the two states atomically, with proof of ownership required either way you're switching.
That distinction matters for how you read any Phoenix walkthrough: "confidential" and "anonymous" aren't the same claim here, and it changes what a view key is actually protecting. Next thing I'd check: what a view key exposes to a third party versus what the receiver sees by default.
@Dusk_Foundation
So the shielding is narrower than it sounds. Notes, nullifiers, proofs — all of it hides sender, receiver, and amount from public chain observers. But the counterparty was never meant to be in the dark. It's a disclosure boundary drawn around specific parties, not a blackout.
What changed for me was treating "shielded" as binary — private or not. It isn't. Moonlight sits next to Phoenix as the fully public account model, and a convert function moves value between the two states atomically, with proof of ownership required either way you're switching.
That distinction matters for how you read any Phoenix walkthrough: "confidential" and "anonymous" aren't the same claim here, and it changes what a view key is actually protecting. Next thing I'd check: what a view key exposes to a third party versus what the receiver sees by default.
@Dusk_Foundation