I was looking at Dusk modular architecture again and the diagram makes more sense once you stop looking at it as three separate chains.
It's really three different jobs being split across the stack.
1. DuskDS — the base layer
This is the foundation.
DuskDS is responsible for the underlying network functions around:
* consensus
* data availability
* settlement
So instead of putting every execution responsibility into the base layer, DuskDS is focused on keeping the underlying system coordinated and settled.
2. DuskEVM — the compatibility layer
This is where EVM execution comes in.
The interesting part isn't simply “Dusk supports EVM.”
It's that EVM execution gets its own layer inside the modular architecture, giving developers a more familiar environment while keeping the underlying DuskDS layer separate.
That separation can reduce the amount of integration work needed when building applications.
3. DuskVM — the privacy execution layer
Then there is DuskVM.
Its role is different again: privacy-focused execution.
So the architecture isn't forcing public-style EVM execution and privacy-oriented execution into exactly the same environment.
They're being separated into their own execution paths.
And then there are two pieces connecting the whole design.
4. One DUSK across the stack
The architecture keeps a single DUSK token across the layers.
That matters because modular execution doesn't automatically mean fragmented economics.
The execution environments can be separated while the token economy remains unified.
5. Native bridge between DuskDS and DuskEVM
The layers also aren't supposed to behave like isolated islands.
The architecture describes a native bridge concept between DuskDS and DuskEVM, giving the execution layer a path back to the underlying Dusk system.
That's the part I find more interesting than the diagram itself.
The architecture is basically saying:
DuskDS handles the foundation.
DuskEVM handles EVM execution.
DuskVM handles privacy-focused execution.
$DUSK #dusk @Dusk
It's really three different jobs being split across the stack.
1. DuskDS — the base layer
This is the foundation.
DuskDS is responsible for the underlying network functions around:
* consensus
* data availability
* settlement
So instead of putting every execution responsibility into the base layer, DuskDS is focused on keeping the underlying system coordinated and settled.
2. DuskEVM — the compatibility layer
This is where EVM execution comes in.
The interesting part isn't simply “Dusk supports EVM.”
It's that EVM execution gets its own layer inside the modular architecture, giving developers a more familiar environment while keeping the underlying DuskDS layer separate.
That separation can reduce the amount of integration work needed when building applications.
3. DuskVM — the privacy execution layer
Then there is DuskVM.
Its role is different again: privacy-focused execution.
So the architecture isn't forcing public-style EVM execution and privacy-oriented execution into exactly the same environment.
They're being separated into their own execution paths.
And then there are two pieces connecting the whole design.
4. One DUSK across the stack
The architecture keeps a single DUSK token across the layers.
That matters because modular execution doesn't automatically mean fragmented economics.
The execution environments can be separated while the token economy remains unified.
5. Native bridge between DuskDS and DuskEVM
The layers also aren't supposed to behave like isolated islands.
The architecture describes a native bridge concept between DuskDS and DuskEVM, giving the execution layer a path back to the underlying Dusk system.
That's the part I find more interesting than the diagram itself.
The architecture is basically saying:
DuskDS handles the foundation.
DuskEVM handles EVM execution.
DuskVM handles privacy-focused execution.
$DUSK #dusk @Dusk