Once DuskEVM existed, Dusk Network could have made a simpler pitch: one execution environment, Solidity for everyone, done. Instead the documentation is explicit that native Dusk development, meaning Rust contracts compiled to WASM and executed by DuskVM, remains the recommended path whenever an application needs protocol-level control, custom transaction models, or zero-knowledge capabilities that sit close to the base layer. I find that an interesting decision to defend, because maintaining two execution paths is more expensive to build and to explain than maintaining one.
The logic seems to be that DuskEVM and DuskVM are optimized for different customers rather than competing for the same one. A team porting an existing Ethereum DeFi protocol wants familiar tooling, existing audits, and wallets that already work, which is what DuskEVM is for. A team building securities settlement logic with capped transfers, dividend distribution, or compliance rules baked directly into a contract sits closer to what Zedger and native DuskVM contracts were designed around from the start, since that hybrid transaction model was purpose-built for exactly this kind of security-token bookkeeping instead of being adapted from a general-purpose pattern after the fact.
I am not fully convinced this dual-track approach avoids fragmenting Dusk Network's own developer base and documentation effort across two audiences instead of concentrating it behind one. Two execution environments mean two sets of tooling to maintain, two mental models for new contributors, and two answers to the simple question of where a new application should actually be built. I understand the bet, since narrowing to one path this early would have quietly written off whichever audience got dropped. Whether Dusk Network stays big enough to properly support both paths over the next few years is worth watching.
#dusk $DUSK @Dusk
The logic seems to be that DuskEVM and DuskVM are optimized for different customers rather than competing for the same one. A team porting an existing Ethereum DeFi protocol wants familiar tooling, existing audits, and wallets that already work, which is what DuskEVM is for. A team building securities settlement logic with capped transfers, dividend distribution, or compliance rules baked directly into a contract sits closer to what Zedger and native DuskVM contracts were designed around from the start, since that hybrid transaction model was purpose-built for exactly this kind of security-token bookkeeping instead of being adapted from a general-purpose pattern after the fact.
I am not fully convinced this dual-track approach avoids fragmenting Dusk Network's own developer base and documentation effort across two audiences instead of concentrating it behind one. Two execution environments mean two sets of tooling to maintain, two mental models for new contributors, and two answers to the simple question of where a new application should actually be built. I understand the bet, since narrowing to one path this early would have quietly written off whichever audience got dropped. Whether Dusk Network stays big enough to properly support both paths over the next few years is worth watching.
#dusk $DUSK @Dusk
