Phoenix vs Moonlight: Why Dusk Needed Two Transaction Models
I think the most misunderstood part of @Dusk_Foundation is not its privacy layer.
It is why Dusk built a transparent transaction model beside Phoenix in the first place.
The answer is simple: financial markets do not operate with one privacy requirement.
The 2024 Dusk whitepaper describes Moonlight as the public transaction layer added alongside Phoenix. Moonlight uses an account-based model, where addresses and balances are visible. Phoenix takes the opposite route: shielded, note-based transactions using zero-knowledge proofs.
With Moonlight, an exchange can scan accounts, reconcile balances and process deposits using a familiar public ledger model. Dusk's current integration documentation actually recommends Moonlight for exchange deposits and withdrawals because Phoenix requires a different custody and scanning architecture.
Its notes are encrypted, while ZK proofs let the network verify things like validity and double-spend protection without revealing the transaction amount or the specific notes being spent. Dusk also designed selective disclosure so privacy doesn't automatically mean “no accountability.”
So the original design choice was not:
Phoenix vs Moonlight.
It was:
privacy when needed + transparency when required.
And there is an important 2026 update here.
Dusk's AEGIS hard fork addressed 39 findings, including 7 critical issues, with one critical root cause involving Phoenix fee/refund binding.
More importantly, the latest network documentation says the Boreas upgrade retires Phoenix transactions on the network, while canonical transaction handling has moved forward.
Phoenix was not simply a privacy feature. It was an experiment in making confidential settlement work alongside a public financial rail.
They are different settlement requirements.
Dusk's evolution is interesting precisely because the protocol is now refining which parts of that original dual-model architecture still belong in the production stack.
#dusk
$DUSK
I think the most misunderstood part of @Dusk_Foundation is not its privacy layer.
It is why Dusk built a transparent transaction model beside Phoenix in the first place.
The answer is simple: financial markets do not operate with one privacy requirement.
The 2024 Dusk whitepaper describes Moonlight as the public transaction layer added alongside Phoenix. Moonlight uses an account-based model, where addresses and balances are visible. Phoenix takes the opposite route: shielded, note-based transactions using zero-knowledge proofs.
With Moonlight, an exchange can scan accounts, reconcile balances and process deposits using a familiar public ledger model. Dusk's current integration documentation actually recommends Moonlight for exchange deposits and withdrawals because Phoenix requires a different custody and scanning architecture.
Its notes are encrypted, while ZK proofs let the network verify things like validity and double-spend protection without revealing the transaction amount or the specific notes being spent. Dusk also designed selective disclosure so privacy doesn't automatically mean “no accountability.”
So the original design choice was not:
Phoenix vs Moonlight.
It was:
privacy when needed + transparency when required.
And there is an important 2026 update here.
Dusk's AEGIS hard fork addressed 39 findings, including 7 critical issues, with one critical root cause involving Phoenix fee/refund binding.
More importantly, the latest network documentation says the Boreas upgrade retires Phoenix transactions on the network, while canonical transaction handling has moved forward.
Phoenix was not simply a privacy feature. It was an experiment in making confidential settlement work alongside a public financial rail.
They are different settlement requirements.
Dusk's evolution is interesting precisely because the protocol is now refining which parts of that original dual-model architecture still belong in the production stack.
#dusk
$DUSK