The first time I saw the dual-account system of @Dusk , I instinctively understood it as “one public account, one private account—switch it in your wallet and you’re done.” But the real trouble with this kind of setup isn’t the buttons on the front end; it’s that, at the ledger level, the underlying structure is completely different. $DUSK
Moonlight uses an account-based model, where the balance, address relationships, and fund flows are easier to audit. For exchanges, custodians, and KYC institutions, this kind of public path is crucial, because compliance checks need to be able to clearly explain where the funds came from and where they go. Phoenix is a different logic: it overlays a UTXO structure with PLONK zero-knowledge proofs to hide the amounts and counterparty information. Verifiers only need to confirm that a transaction is valid; they don’t need to see the original data. $BTC
So moving from Moonlight to Phoenix isn’t just changing a display mode. The public balance has to first go through a shield step, which regenerates privacy commitments; locally you also have to generate proofs, and then the chain verifies them on-chain. It’s like taking a regular, transparent transfer and putting it into a sealed box again—not that the product simply skipped a hotkey. Instead, there must be a cryptographic transformation between the account model and the privacy UTXO.
This also explains why cross-rail operations are heavier. A typical Moonlight transfer path is shorter and cheaper; once you go into Phoenix, you add proof generation, contract interactions, and confirmation waiting. For small-amount users, these costs become very obvious. What started as simply protecting the privacy of a transfer ends up with more complicated operations and higher fees, so the experience naturally takes a hit.
But if you shift to RWA or institutional trading scenarios, Dusk’s dual-rail design shows its purpose. Moonlight can handle the parts that must be “visible,” like compliance, custody, and auditing. Phoenix handles the parts that aren’t suitable for the whole market to scrutinize—things like quoting, counterparties, and position adjustments. It’s not trying to solve only privacy transfers; it’s about how to分工 when compliance and privacy both need to exist. $ETH
#dusk The biggest barrier right now is that when users move assets between two rails, they must be aware of the conversion process, and they must pay for it and wait. If later on they can support batch shielding, proof aggregation, and routing abstraction—compressing multiple actions into an experience closer to a single settlement—then Phoenix’s use cases would expand a lot. Until then, Moonlight will remain the main entry point for most people.
Moonlight uses an account-based model, where the balance, address relationships, and fund flows are easier to audit. For exchanges, custodians, and KYC institutions, this kind of public path is crucial, because compliance checks need to be able to clearly explain where the funds came from and where they go. Phoenix is a different logic: it overlays a UTXO structure with PLONK zero-knowledge proofs to hide the amounts and counterparty information. Verifiers only need to confirm that a transaction is valid; they don’t need to see the original data. $BTC
So moving from Moonlight to Phoenix isn’t just changing a display mode. The public balance has to first go through a shield step, which regenerates privacy commitments; locally you also have to generate proofs, and then the chain verifies them on-chain. It’s like taking a regular, transparent transfer and putting it into a sealed box again—not that the product simply skipped a hotkey. Instead, there must be a cryptographic transformation between the account model and the privacy UTXO.
This also explains why cross-rail operations are heavier. A typical Moonlight transfer path is shorter and cheaper; once you go into Phoenix, you add proof generation, contract interactions, and confirmation waiting. For small-amount users, these costs become very obvious. What started as simply protecting the privacy of a transfer ends up with more complicated operations and higher fees, so the experience naturally takes a hit.
But if you shift to RWA or institutional trading scenarios, Dusk’s dual-rail design shows its purpose. Moonlight can handle the parts that must be “visible,” like compliance, custody, and auditing. Phoenix handles the parts that aren’t suitable for the whole market to scrutinize—things like quoting, counterparties, and position adjustments. It’s not trying to solve only privacy transfers; it’s about how to分工 when compliance and privacy both need to exist. $ETH
#dusk The biggest barrier right now is that when users move assets between two rails, they must be aware of the conversion process, and they must pay for it and wait. If later on they can support batch shielding, proof aggregation, and routing abstraction—compressing multiple actions into an experience closer to a single settlement—then Phoenix’s use cases would expand a lot. Until then, Moonlight will remain the main entry point for most people.