A couple of days ago, while scrolling through X, I came across a post about the DuskEVM testnet, and one detail caught my attention. On August 10, DuskEVM testnet went live, Solidity and Hardhat were running smoothly, but Hedger, the core confidential contract engine, has been running separately on Ethereum Sepolia testnet since November 2025. The official team has still not announced when the two will be merged.
When people see this 9-month gap, the first reaction is concern. A privacy-focused chain having its privacy layer and EVM layer tested separately might sound unusual.
But after going through the technical documentation, I started thinking that this dual-track testing could actually be an underestimated choice in Dusk's architecture. Dusk's stack is layered. #Dusk handles settlement and data availability, DuskEVM is the EVM layer, and Hedger is the privacy layer using homomorphic encryption and zero-knowledge proofs.
If all three layers were tested together, a cryptography bug and a contract bug could become difficult to distinguish. Testing them separately allows the team to get the EVM layer running first, let developers deploy applications, then validate Hedger separately on Sepolia, and finally merge it back into $DUSK . This makes the debugging process much clearer.
I'm not sure whether this judgment is correct. It's also possible that protocol conflicts could appear during the final merge and require some previous work to be redone. Modularity sounds good, but engineering always comes with coordination costs.
But from another angle, institutional clients are more afraid of something breaking than something being slow. A phased rollout can be more trustworthy than pushing everything at once and then having to roll back.
Launching the EVM first and merging Hedger after proper validation could simply be a way of making sure the foundation is solid.
What do you guys think about this dual-track testing strategy? I want to hear everyone's opinion.@Dusk
When people see this 9-month gap, the first reaction is concern. A privacy-focused chain having its privacy layer and EVM layer tested separately might sound unusual.
But after going through the technical documentation, I started thinking that this dual-track testing could actually be an underestimated choice in Dusk's architecture. Dusk's stack is layered. #Dusk handles settlement and data availability, DuskEVM is the EVM layer, and Hedger is the privacy layer using homomorphic encryption and zero-knowledge proofs.
If all three layers were tested together, a cryptography bug and a contract bug could become difficult to distinguish. Testing them separately allows the team to get the EVM layer running first, let developers deploy applications, then validate Hedger separately on Sepolia, and finally merge it back into $DUSK . This makes the debugging process much clearer.
I'm not sure whether this judgment is correct. It's also possible that protocol conflicts could appear during the final merge and require some previous work to be redone. Modularity sounds good, but engineering always comes with coordination costs.
But from another angle, institutional clients are more afraid of something breaking than something being slow. A phased rollout can be more trustworthy than pushing everything at once and then having to roll back.
Launching the EVM first and merging Hedger after proper validation could simply be a way of making sure the foundation is solid.
What do you guys think about this dual-track testing strategy? I want to hear everyone's opinion.@Dusk
