Yesterday while browsing the community, I noticed that recently some developers have been complaining there: writing a lending contract on Dusk requires managing two sets of state at the same time—Moonlight’s account balance and Phoenix’s privacy notes—and the liquidation logic has to be computed for both sides together.
I especially understand this kind of crash.
From the user side, Dusk’s design looks elegant: the same seed phrase derives two addresses, and the user can tap once to switch between transparent transactions and privacy transactions. But underneath, the protocol is completely two separate ledger logics. Moonlight is an account model, with balances written directly into the contract. Phoenix is UTXO plus notes, assembled using Pedersen commitments and nullifiers. In the docs, they mention almost casually to “choose as needed.” Translating that into plain human language is: the developer decides. This is the engineering reality of Dusk’s dual-execution-path architecture. DuskEVM solves the problem of how developers get in—Solidity Hardhat Foundry ethers, familiar tooling. But Hedger solves a different problem: after financial institutions come in, which data should never be exposed. The former is the entry point; the latter is the bottom line.
The issue is that when developers choose between these two logics, there’s no standard answer. If you implement Moonlight logic, it’s simple, transparent, and fits developers’ habits—but big players fear being targeted. If you implement Phoenix logic, privacy is solid—but regulators might directly cut off the interface. The NPEX story about security token-type assets sounds pretty convincing, but someone bet five cents and ended up with everyone stuck in Moonlight. Why? Because MiCA requires quarterly audits of stablecoin reserves, and regulators’ first instinct is always whether the code can one-click export to Excel. Phoenix’s selective disclosure looks like a technical black box to lawyers—if anything goes wrong, who signs.
@Dusk
So my current judgment is that getting DuskEVM onto the testnet is only the first step. What truly determines Dusk’s fate is the first case where someone dares to throw the core liquidity pool into Phoenix and receives written regulatory endorsement from the EU.
Before that, Dusk developers can only keep swinging back and forth between two choices with no standard answers. And having no default answer is precisely the biggest failure at the product level. #dusk $DUSK
I especially understand this kind of crash.
From the user side, Dusk’s design looks elegant: the same seed phrase derives two addresses, and the user can tap once to switch between transparent transactions and privacy transactions. But underneath, the protocol is completely two separate ledger logics. Moonlight is an account model, with balances written directly into the contract. Phoenix is UTXO plus notes, assembled using Pedersen commitments and nullifiers. In the docs, they mention almost casually to “choose as needed.” Translating that into plain human language is: the developer decides. This is the engineering reality of Dusk’s dual-execution-path architecture. DuskEVM solves the problem of how developers get in—Solidity Hardhat Foundry ethers, familiar tooling. But Hedger solves a different problem: after financial institutions come in, which data should never be exposed. The former is the entry point; the latter is the bottom line.
The issue is that when developers choose between these two logics, there’s no standard answer. If you implement Moonlight logic, it’s simple, transparent, and fits developers’ habits—but big players fear being targeted. If you implement Phoenix logic, privacy is solid—but regulators might directly cut off the interface. The NPEX story about security token-type assets sounds pretty convincing, but someone bet five cents and ended up with everyone stuck in Moonlight. Why? Because MiCA requires quarterly audits of stablecoin reserves, and regulators’ first instinct is always whether the code can one-click export to Excel. Phoenix’s selective disclosure looks like a technical black box to lawyers—if anything goes wrong, who signs.
@Dusk
So my current judgment is that getting DuskEVM onto the testnet is only the first step. What truly determines Dusk’s fate is the first case where someone dares to throw the core liquidity pool into Phoenix and receives written regulatory endorsement from the EU.
Before that, Dusk developers can only keep swinging back and forth between two choices with no standard answers. And having no default answer is precisely the biggest failure at the product level. #dusk $DUSK
