Does DuskEVM Make Solidity Contracts Private by Default?
DuskEVM creates an easy assumption: if an application runs on Dusk, it must automatically inherit Dusk’s privacy model.
The architecture says something more precise.
DuskEVM is an OP Stack-based EVM execution environment. Solidity contracts execute there with familiar Ethereum tooling, while batches and state commitments settle through DuskDS, which provides consensus, deterministic finality and data availability.
That separation matters because execution compatibility and privacy capability are not the same guarantee.
Dusk’s own docs position DuskVM as the path for contracts that need direct access to L1 assets, transaction models, privacy or zero-knowledge capabilities. DuskEVM, by contrast, solves a different problem first: EVM-equivalent execution and developer compatibility. Privacy-oriented workflows can connect into the wider Dusk stack, but they still depend on how the application is designed.
So the useful question is not, “Can Ethereum developers deploy on Dusk?” They can.
The harder question is: which guarantees come from the EVM layer, and which must be deliberately composed from DuskDS or Dusk-native primitives?
That changes the mental model. Dusk is not simply wrapping privacy around the EVM. It is separating execution, settlement and privacy-capable infrastructure so developers can choose where each guarantee comes from.
For regulated finance, that modularity is powerful—but it also makes architecture choices part of the compliance and confidentiality model.
@Dusk_Foundation $DUSK #dusk $HEMI $ACE
DuskEVM creates an easy assumption: if an application runs on Dusk, it must automatically inherit Dusk’s privacy model.
The architecture says something more precise.
DuskEVM is an OP Stack-based EVM execution environment. Solidity contracts execute there with familiar Ethereum tooling, while batches and state commitments settle through DuskDS, which provides consensus, deterministic finality and data availability.
That separation matters because execution compatibility and privacy capability are not the same guarantee.
Dusk’s own docs position DuskVM as the path for contracts that need direct access to L1 assets, transaction models, privacy or zero-knowledge capabilities. DuskEVM, by contrast, solves a different problem first: EVM-equivalent execution and developer compatibility. Privacy-oriented workflows can connect into the wider Dusk stack, but they still depend on how the application is designed.
So the useful question is not, “Can Ethereum developers deploy on Dusk?” They can.
The harder question is: which guarantees come from the EVM layer, and which must be deliberately composed from DuskDS or Dusk-native primitives?
That changes the mental model. Dusk is not simply wrapping privacy around the EVM. It is separating execution, settlement and privacy-capable infrastructure so developers can choose where each guarantee comes from.
For regulated finance, that modularity is powerful—but it also makes architecture choices part of the compliance and confidentiality model.
@Dusk_Foundation $DUSK #dusk $HEMI $ACE