The first time I saw @Dusk setting up two sets of trading models at the same time—Moonlight and Phoenix—I actually had a very straightforward question:
If you’re focusing on privacy, why not simply make everything privacy-preserving transactions?
One transparent, one private—doesn’t that feel like extra hassle?
Later, when I looked more closely at the whitepaper, I felt that this kind of “awkwardness” might actually be what makes it closest to real finance.
Moonlight is simple: it follows an account model similar to Ethereum. Things like balances, nonces, and transaction status are public, and transactions rely on signature verification.
Phoenix, on the other hand, is a completely different logic.
It’s a UTXO model that introduces stealth addresses, nullifiers, and zero-knowledge proofs. The network doesn’t need to directly see which specific payment you made or what your balance is—it only needs to verify that ZK proof: that you do own the assets, that you have sufficient balance, that there’s no double-spending, and that the transaction hasn’t been tampered with.
At first glance, it seems like the system is unnecessarily complicated.
But real finance itself isn’t about permission levels.
Exchange deposits and withdrawals might be better suited to a public account model.
Between institutions, securities transfers, asset holdings, and customer trading may require privacy.
And during audits, there must be a way to disclose.
If you force all business scenarios into a single transaction model, you’ll end up with either insufficient privacy or poor compliance.
So Moonlight + Phoenix gives me the feeling more like a bank that has both a “lobby” and a “vault.”
There’s no need to hide what happens in the lobby.
And there’s no need to show vault contents to passersby.
The key isn’t whether everything is fully transparent or fully private—it’s that different money is handled with different rules.
This also helps explain why Dusk is now continuing to build a native L1 while also developing DuskEVM and Hedger. DuskEVM gives Solidity developers a familiar EVM path, while Hedger uses homomorphic encryption and zero-knowledge proofs to fill in confidential transaction flows.
Personally, I actually feel this roadmap is more realistic than the idea that “all developers must learn a whole new thing.”
Of course, the issues are also obvious.
The more modules you add, the more complex the system becomes. Whether Native L1, DuskEVM, Hedger, and Dusk Trade can truly form a closed loop—rather than four products each telling their own story—that’s the part I’ll keep watching.
$DUSK #dusk
If you’re focusing on privacy, why not simply make everything privacy-preserving transactions?
One transparent, one private—doesn’t that feel like extra hassle?
Later, when I looked more closely at the whitepaper, I felt that this kind of “awkwardness” might actually be what makes it closest to real finance.
Moonlight is simple: it follows an account model similar to Ethereum. Things like balances, nonces, and transaction status are public, and transactions rely on signature verification.
Phoenix, on the other hand, is a completely different logic.
It’s a UTXO model that introduces stealth addresses, nullifiers, and zero-knowledge proofs. The network doesn’t need to directly see which specific payment you made or what your balance is—it only needs to verify that ZK proof: that you do own the assets, that you have sufficient balance, that there’s no double-spending, and that the transaction hasn’t been tampered with.
At first glance, it seems like the system is unnecessarily complicated.
But real finance itself isn’t about permission levels.
Exchange deposits and withdrawals might be better suited to a public account model.
Between institutions, securities transfers, asset holdings, and customer trading may require privacy.
And during audits, there must be a way to disclose.
If you force all business scenarios into a single transaction model, you’ll end up with either insufficient privacy or poor compliance.
So Moonlight + Phoenix gives me the feeling more like a bank that has both a “lobby” and a “vault.”
There’s no need to hide what happens in the lobby.
And there’s no need to show vault contents to passersby.
The key isn’t whether everything is fully transparent or fully private—it’s that different money is handled with different rules.
This also helps explain why Dusk is now continuing to build a native L1 while also developing DuskEVM and Hedger. DuskEVM gives Solidity developers a familiar EVM path, while Hedger uses homomorphic encryption and zero-knowledge proofs to fill in confidential transaction flows.
Personally, I actually feel this roadmap is more realistic than the idea that “all developers must learn a whole new thing.”
Of course, the issues are also obvious.
The more modules you add, the more complex the system becomes. Whether Native L1, DuskEVM, Hedger, and Dusk Trade can truly form a closed loop—rather than four products each telling their own story—that’s the part I’ll keep watching.
$DUSK #dusk