Many people look at the Dusk roadmap and think DuskEVM mainnet (2027) is the “ultimate move,” porting the entire on-chain ecosystem over to compete with Ethereum. After I reviewed the two layers—Rusk/DuskVM and DuskEVM—I think a more accurate way to put it is this: DuskVM (the original Piecrust VM, Rust/WASM confidential contracts) is the main gate for Dusk as a securities settlement layer, while DuskEVM is a side door opened for Solidity teams that don’t know how to write Rust. It lets them “attach” business contracts into the Zedger privacy model using Hedger annotations.
What does the main gate do? The core of the XSC standard, the Phoenix note lifecycle, Citadel ZK-KYC verification, and the SBA consensus interfaces are all implemented in DuskVM using Rust. Performance and direct control over PLONK circuits are things Solidity can’t provide. NPEX bond primary issuance, institutional custody sub-accounts, regulatory view-key management—these heavy-duty asset logic flows through the main gate.
What does the side door solve? In reality, 90% of Web3 developers only know Solidity. Asking them to relearn Rust+WASM+ZK circuits for Dusk isn’t realistic. DuskEVM uses an equivalent stack like OP Stack to run Solidity. Hedger removes the “hedged variables” at compile time from Zedger, so developers write it almost the same way as a normal ERC-20, but the resulting artifacts automatically carry confidentiality. In other words, Dusk lowers the barrier of the “privacy securities chain” from the Rust kernel level down to the Solidity surface.
I deployed XSC dividend on testnet using Solidity+Hedger, and got it working in three days. If you force me to write Rust/Piecrust code to tweak Zedger notes, at least three weeks. That’s where the side door’s value lies.
But the side door isn’t the main engine: the finality of DuskEVM’s State root still ultimately returns to DuskDS. For heavy compliance logic (like forced transfers and issuer force transfer), you still need native contracts in DuskVM. The Solidity side door can’t tune the underlying SBA signing.
Do you think the side door should be the flagship?
@Dusk $DUSK #dusk
What does the main gate do? The core of the XSC standard, the Phoenix note lifecycle, Citadel ZK-KYC verification, and the SBA consensus interfaces are all implemented in DuskVM using Rust. Performance and direct control over PLONK circuits are things Solidity can’t provide. NPEX bond primary issuance, institutional custody sub-accounts, regulatory view-key management—these heavy-duty asset logic flows through the main gate.
What does the side door solve? In reality, 90% of Web3 developers only know Solidity. Asking them to relearn Rust+WASM+ZK circuits for Dusk isn’t realistic. DuskEVM uses an equivalent stack like OP Stack to run Solidity. Hedger removes the “hedged variables” at compile time from Zedger, so developers write it almost the same way as a normal ERC-20, but the resulting artifacts automatically carry confidentiality. In other words, Dusk lowers the barrier of the “privacy securities chain” from the Rust kernel level down to the Solidity surface.
I deployed XSC dividend on testnet using Solidity+Hedger, and got it working in three days. If you force me to write Rust/Piecrust code to tweak Zedger notes, at least three weeks. That’s where the side door’s value lies.
But the side door isn’t the main engine: the finality of DuskEVM’s State root still ultimately returns to DuskDS. For heavy compliance logic (like forced transfers and issuer force transfer), you still need native contracts in DuskVM. The Solidity side door can’t tune the underlying SBA signing.
Do you think the side door should be the flagship?
@Dusk $DUSK #dusk