On August 18, the U.S. SEC proposed new rules for certain crypto-asset investment contracts, including a targeted issuance pathway with a potential exemption of up to $75 million per 12 months. However, this is still a proposal—not an already effective law.
This hot topic reminded me of a frequently overlooked question: if securities truly go on-chain, should the ledger be fully public, or fully hidden? Dusk’s answer is not a choice between the two—it keeps both Moonlight and Phoenix.
First, let’s use two familiar analogies. Moonlight is more like a bank account: it’s a transparent, account-based model where accounts are identified by public keys, and balances, nonces, as well as the sender, receiver, and amount of transfers are all visible—making it suitable for processes that require reconciliation, reporting, or public verification.
Phoenix, on the other hand, is like a set of password-protected vouchers: assets are stored as encrypted notes and belong to a UTXO-based model. Transactions can use zero-knowledge proofs to show that “I have the right to spend, the balance is sufficient, and there is no double-spending,” without having to reveal the amounts, the specific notes, or all sending details.
But Phoenix is not “fully anonymous.” The official documentation explicitly states that sender information is visible to the receiver, and users can also use a viewing key to selectively disclose information when needed for regulatory or audit purposes. This point is crucial: privacy protection is about preventing unnecessary exposure across the entire network—not about wiping away all responsibility.
Both models are ultimately coordinated by DuskDS’s Transfer Contract. It accepts transactions in different formats, routes them to the corresponding verification logic, and consistently handles fees, global state, and double-spend issues. In terms of nature, transactions must satisfy ownership, balance and fee requirements, anti–double-spending, and tamper resistance; the difference is that Moonlight directly checks public state, while Phoenix mainly checks ZK proofs.
@Dusk $DUSK #dusk
In summary, the real trade-off in Dusk isn’t “transparency is better” versus “privacy is better,” but enabling the same financial system to choose ledger semantics according to the scenario: use Moonlight when public verification is needed, and use Phoenix when exposure should be reduced.
This hot topic reminded me of a frequently overlooked question: if securities truly go on-chain, should the ledger be fully public, or fully hidden? Dusk’s answer is not a choice between the two—it keeps both Moonlight and Phoenix.
First, let’s use two familiar analogies. Moonlight is more like a bank account: it’s a transparent, account-based model where accounts are identified by public keys, and balances, nonces, as well as the sender, receiver, and amount of transfers are all visible—making it suitable for processes that require reconciliation, reporting, or public verification.
Phoenix, on the other hand, is like a set of password-protected vouchers: assets are stored as encrypted notes and belong to a UTXO-based model. Transactions can use zero-knowledge proofs to show that “I have the right to spend, the balance is sufficient, and there is no double-spending,” without having to reveal the amounts, the specific notes, or all sending details.
But Phoenix is not “fully anonymous.” The official documentation explicitly states that sender information is visible to the receiver, and users can also use a viewing key to selectively disclose information when needed for regulatory or audit purposes. This point is crucial: privacy protection is about preventing unnecessary exposure across the entire network—not about wiping away all responsibility.
Both models are ultimately coordinated by DuskDS’s Transfer Contract. It accepts transactions in different formats, routes them to the corresponding verification logic, and consistently handles fees, global state, and double-spend issues. In terms of nature, transactions must satisfy ownership, balance and fee requirements, anti–double-spending, and tamper resistance; the difference is that Moonlight directly checks public state, while Phoenix mainly checks ZK proofs.
@Dusk $DUSK #dusk
In summary, the real trade-off in Dusk isn’t “transparency is better” versus “privacy is better,” but enabling the same financial system to choose ledger semantics according to the scenario: use Moonlight when public verification is needed, and use Phoenix when exposure should be reduced.