Beyond Private Transactions: Understanding the DUSK Architecture. I went in expecting the privacy layer to be the default rail, and found the opposite. Dusk ($DUSK , #dusk , @Dusk ) runs two transaction models side by side, Phoenix and Moonlight, and the docs describe Moonlight, the transparent account-based model, as "just the transparent way to move DUSK" at the protocol layer. Phoenix, the actual zero-knowledge shielded model with encrypted notes and nullifiers, is the one doing the harder cryptographic work, but it reads as the deliberate, opt-in path rather than the resting state. Both settle through the same Transfer contract, both pay gas, both can spin up a contract call, so the choice isn't functional friction, it's a design decision about which behavior gets treated as ordinary. A chain built specifically to solve private smart contract execution ends up describing its plain accounts as the default explanation, and its privacy engine as the feature you reach for. Maybe that's just sound UX sequencing for institutional onboarding. Or maybe it says something about which use case actually gets exercised first once real usage starts flowing through. Which one is Dusk actually optimizing adoption around?