#dusk $DUSK The thing about Dusk's privacy pitch that I keep sitting with
I've noticed a pattern in projects that brand themselves privacy chains. The tagline promises confidentiality, but past the marketing page, that confidentiality is often a setting you reach for rather than a default.
Dusk is the case I've been sitting with lately.
The base layer runs two transaction models. Moonlight is public and account-based, similar to how Ethereum exposes balances. Phoenix is the shielded, note-based model doing the actual zero-knowledge work. Dusk's own docs frame the relationship as a system built with "dual transaction models to let you choose."...
I keep coming back to that word. Choice is a defensible design principle, but it also puts the burden on the user rather than the protocol. Privacy becomes a decision made transaction by transaction, one you can get wrong by defaulting to whichever model an app or exchange routes you through.
Moonlight's origin matters too. Dusk's account of its updated whitepaper says the model was added because exchange integration would be simpler under a public format, and that doing so removes any risk of being delisted.
An unofficial explorer I checked showed transparent Moonlight activity running around ten times shielded Phoenix activity over a recent day. One snapshot isn't proof, but it tracks with what the incentives would predict.
There's also a wrinkle I can't resolve. Dusk's CTO said earlier this year that transfers are "private by default," language that doesn't quite match how the docs frame the base-layer choice. I haven't found the two framings reconciled anywhere.
@Dusk_Foundation has clearly built real cryptography into Phoenix. What I keep turning over is whether that privacy model gets used at scale once Moonlight offers simpler reporting, or whether it ends up mostly sitting on the shelf.
I've noticed a pattern in projects that brand themselves privacy chains. The tagline promises confidentiality, but past the marketing page, that confidentiality is often a setting you reach for rather than a default.
Dusk is the case I've been sitting with lately.
The base layer runs two transaction models. Moonlight is public and account-based, similar to how Ethereum exposes balances. Phoenix is the shielded, note-based model doing the actual zero-knowledge work. Dusk's own docs frame the relationship as a system built with "dual transaction models to let you choose."...
I keep coming back to that word. Choice is a defensible design principle, but it also puts the burden on the user rather than the protocol. Privacy becomes a decision made transaction by transaction, one you can get wrong by defaulting to whichever model an app or exchange routes you through.
Moonlight's origin matters too. Dusk's account of its updated whitepaper says the model was added because exchange integration would be simpler under a public format, and that doing so removes any risk of being delisted.
An unofficial explorer I checked showed transparent Moonlight activity running around ten times shielded Phoenix activity over a recent day. One snapshot isn't proof, but it tracks with what the incentives would predict.
There's also a wrinkle I can't resolve. Dusk's CTO said earlier this year that transfers are "private by default," language that doesn't quite match how the docs frame the base-layer choice. I haven't found the two framings reconciled anywhere.
@Dusk_Foundation has clearly built real cryptography into Phoenix. What I keep turning over is whether that privacy model gets used at scale once Moonlight offers simpler reporting, or whether it ends up mostly sitting on the shelf.