#dusk $DUSK Here's something that gets glossed over in most DUSK explainers: this isn't a chain with one privacy model bolted on. It's a chain running two distinct transaction models simultaneously, because a payment and a security aren't the same kind of object and don't fail the same way.
Phoenix is the UTxO-style model for everyday obfuscated transfers — balances and counterparties hidden, notes tracked in a Merkle tree, nullifiers preventing double-spends without revealing which note got spent. It's built for throughput and confidentiality on ordinary value transfer.
Zedger is different on purpose. It's modeled specifically for tokenized securities, where the whole point isn't just hiding a balance — it's proving lifecycle events (issuance, transfer restrictions, corporate actions, redemption) happened correctly under a regulatory framework, without leaking the cap table to the public chain. A security token has obligations Phoenix was never designed to carry: transfer restrictions tied to investor status, the ability for an issuer to freeze or reclaim under specific legal conditions, audit requirements that survive even when balances stay sealed.
Running both on one settlement layer is the actual engineering bet. Dusk isn't choosing between "private payments chain" and "compliant securities chain" — it's arguing you need both primitives available in the same execution environment because a regulated market touches both kinds of transaction in the same trading day. The transfer contract manages both flows through the same Merkle-tree-based integrity model, which is a cleaner architecture than bridging two chains with two different privacy guarantees.
The open question is whether that dual-model complexity becomes a maintenance burden as both specs evolve independently, or whether it's genuinely more robust than a one-size-fits-all privacy layer.
Does anyone know of another L1 shipping two production transaction models this deliberately split by asset class, rather than one generic privacy primitive stretched over everything?
@Dusk_Foundation $NVDAB
Phoenix is the UTxO-style model for everyday obfuscated transfers — balances and counterparties hidden, notes tracked in a Merkle tree, nullifiers preventing double-spends without revealing which note got spent. It's built for throughput and confidentiality on ordinary value transfer.
Zedger is different on purpose. It's modeled specifically for tokenized securities, where the whole point isn't just hiding a balance — it's proving lifecycle events (issuance, transfer restrictions, corporate actions, redemption) happened correctly under a regulatory framework, without leaking the cap table to the public chain. A security token has obligations Phoenix was never designed to carry: transfer restrictions tied to investor status, the ability for an issuer to freeze or reclaim under specific legal conditions, audit requirements that survive even when balances stay sealed.
Running both on one settlement layer is the actual engineering bet. Dusk isn't choosing between "private payments chain" and "compliant securities chain" — it's arguing you need both primitives available in the same execution environment because a regulated market touches both kinds of transaction in the same trading day. The transfer contract manages both flows through the same Merkle-tree-based integrity model, which is a cleaner architecture than bridging two chains with two different privacy guarantees.
The open question is whether that dual-model complexity becomes a maintenance burden as both specs evolve independently, or whether it's genuinely more robust than a one-size-fits-all privacy layer.
Does anyone know of another L1 shipping two production transaction models this deliberately split by asset class, rather than one generic privacy primitive stretched over everything?
@Dusk_Foundation $NVDAB