#dusk $DUSK When I read the Dusk documentation, what interests me most is that it turns “transparency” and “confidentiality” into two parallel native transaction models, rather than patching the design later.
In Dusk Settlement Layer, Moonlight is an account-based model: balances, sender/receiver, and amounts are all公开—just like a normal ERC-style transfer. But Phoenix is different: it’s a note-based confidential model, where funds exist as encrypted notes. During transfers, it uses PLONK-family zk-SNARK proofs to prove three things: there is no double-spending, the input is not less than the output, and the amount falls within a valid range. Observers can’t see the amount or the address linkages; only holders of the viewing key can decrypt and audit.
At first, I thought this was basically the same as Zcash. But on closer inspection, the key difference is “selective disclosure.” A Phoenix note can be bound to a viewing key. When an institution needs to prove that a particular transaction complies with regulations, it doesn’t have to reveal the entire chain’s data—it only needs to provide that single transaction’s plaintext plus a zero-knowledge proof. This granularity of “encrypted by default, decrypted on demand” fits regulated financial scenarios better than global anonymity.
Even better, both models settle within the same Transfer Contract, and their state doesn’t contaminate each other. You can use Moonlight to make treasury funds public, and use Phoenix to hide the counterparty in OTC trades—then both deterministically land in the same block. Letting users choose whether to be transparent for each scenario, rather than having the protocol force a single uniform policy, is Dusk’s biggest correction to the privacy track.
One more detail: Phoenix’s note structure includes an expiration mechanism. Each note has an upper bound on block height; if it hasn’t been spent after that height, the note automatically expires and the funds return to the sender. This prevents “zombie notes” from accumulating endlessly and keeps the chain state from growing without bound. These kinds of engineering refinements show that the team is genuinely considering long-term operational costs.@Dusk
In Dusk Settlement Layer, Moonlight is an account-based model: balances, sender/receiver, and amounts are all公开—just like a normal ERC-style transfer. But Phoenix is different: it’s a note-based confidential model, where funds exist as encrypted notes. During transfers, it uses PLONK-family zk-SNARK proofs to prove three things: there is no double-spending, the input is not less than the output, and the amount falls within a valid range. Observers can’t see the amount or the address linkages; only holders of the viewing key can decrypt and audit.
At first, I thought this was basically the same as Zcash. But on closer inspection, the key difference is “selective disclosure.” A Phoenix note can be bound to a viewing key. When an institution needs to prove that a particular transaction complies with regulations, it doesn’t have to reveal the entire chain’s data—it only needs to provide that single transaction’s plaintext plus a zero-knowledge proof. This granularity of “encrypted by default, decrypted on demand” fits regulated financial scenarios better than global anonymity.
Even better, both models settle within the same Transfer Contract, and their state doesn’t contaminate each other. You can use Moonlight to make treasury funds public, and use Phoenix to hide the counterparty in OTC trades—then both deterministically land in the same block. Letting users choose whether to be transparent for each scenario, rather than having the protocol force a single uniform policy, is Dusk’s biggest correction to the privacy track.
One more detail: Phoenix’s note structure includes an expiration mechanism. Each note has an upper bound on block height; if it hasn’t been spent after that height, the note automatically expires and the funds return to the sender. This prevents “zombie notes” from accumulating endlessly and keeps the chain state from growing without bound. These kinds of engineering refinements show that the team is genuinely considering long-term operational costs.@Dusk