Adding EVM support is usually framed as a compatibility win: more wallets, more tooling, more Solidity developers. But that framing hides a bigger architectural question — should developer familiarity also determine where a financial system settles?
Dusk’s current stack separates those choices. DuskEVM provides EVM-compatible execution settled through DuskDS, while DuskVM runs Rust/WASM contracts directly on the L1. DuskDS remains the settlement and data-availability foundation. That makes EVM compatibility an execution option rather than the definition of the base layer.
The implication is more interesting than “Dusk supports two VMs.” A regulated application can choose familiar EVM tooling without requiring the settlement layer itself to become EVM-shaped.
Meanwhile, workflows that need direct L1 access to Dusk transaction models, privacy or zero-knowledge capabilities can stay native.
The trade-off is coordination. Two execution paths do not make their capabilities identical, and builders still have to decide which guarantees belong at execution and which must be anchored at settlement.
So the real modularity test is not how many environments Dusk supports. It is whether execution can vary without fragmenting the settlement assumptions beneath them.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO
Dusk’s current stack separates those choices. DuskEVM provides EVM-compatible execution settled through DuskDS, while DuskVM runs Rust/WASM contracts directly on the L1. DuskDS remains the settlement and data-availability foundation. That makes EVM compatibility an execution option rather than the definition of the base layer.
The implication is more interesting than “Dusk supports two VMs.” A regulated application can choose familiar EVM tooling without requiring the settlement layer itself to become EVM-shaped.
Meanwhile, workflows that need direct L1 access to Dusk transaction models, privacy or zero-knowledge capabilities can stay native.
The trade-off is coordination. Two execution paths do not make their capabilities identical, and builders still have to decide which guarantees belong at execution and which must be anchored at settlement.
So the real modularity test is not how many environments Dusk supports. It is whether execution can vary without fragmenting the settlement assumptions beneath them.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO