I first paid attention to Dusk Foundation because it was trying to solve a problem that traders and builders both run into: the same ledger can’t be perfectly private and perfectly auditable at the same time. Every time a chain picks one extreme, the other side leaks into the user experience as friction. Over time I’ve gotten more interested in designs that admit this trade-off instead of pretending it doesn’t exist.
The core friction is simple: public transfers are easy to reason about (balances, addresses, and flows are visible), but they can be unacceptable for financial activity where counterparties, sizes, and positions shouldn’t be broadcast. Fully private transfers fix that, but they can complicate basic UX and compliance expectations, because “what happened” isn’t trivially readable by any observer. If a protocol tries to force one model onto every use case, it either becomes a surveillance rail or a black box.It’s like running a store where the front counter needs a clear receipt, but the vault ledger can’t be left open on the table.
The network’s answer is to split how value moves at the base layer, without splitting final settlement. On the same chain, users can choose a transparent path for flows that benefit from public clarity, and a shielded path for flows that need confidentiality, with the option to reveal details selectively when required. In other words, “public UX” and “private settlement requirements” are treated as different transaction shapes, not different chains.
Mechanically, this shows up as two native transaction models on the settlement layer: Moonlight is account-based and public, where balances and transfers are straightforward to observe; Phoenix is note-based and shielded, where funds live as encrypted notes and the sender proves correctness with zero-knowledge proofs rather than exposing the amounts and linkages. Both routes converge into the same settlement rules, but they expose different information to observers, which is the whole point of the design.
That split only works if consensus and state handling stay disciplined. On the settlement side, the chain uses a permissionless, committee-based proof-of-stake consensus (Succinct Attestation) with a round structure that separates block proposal, validation by a committee, and ratification by another committee for deterministic finality. The practical takeaway is that “who gets to speak” and “who gets to confirm” are separated roles, which helps the chain finalize cleanly while still being open to participants who stake and run nodes.
On the state model, the public path can track balances in an account-style view, while the shielded path tracks note commitments and spend conditions, where validity is shown via proofs rather than visible arithmetic. A Transfer Contract sits at the base layer as the settlement engine: it accepts different payload types (Moonlight-style or Phoenix-style), routes each to the right verification logic, and enforces global consistency (no double spends, fees handled, state updated). This is the “bridge” between a simple wallet experience and the stricter cryptographic checks that private settlement demands.Token utility is tied to operation, not storytelling: fees pay for transaction inclusion/execution at the protocol level, staking is required for provisioners to participate in consensus and earn protocol rewards, and governance is the mechanism for upgrading protocol parameters and rules over time.
One honest limit: if proof generation costs, committee behavior, or wallet abstractions evolve differently than expected, the “dual model” can still drift into complexity that users feel even when the underlying cryptography is sound.
