DuskEVM is interesting because it doesn't ask EVM developers to start from scratch.
If you're already building with Solidity, Vyper, Foundry, Hardhat, viem or ethers, the idea is to bring that familiar workflow into the Dusk stack.
But the part I find more interesting is what happens underneath.
DuskEVM is the Ethereum-compatible execution environment, while DuskDS handles consensus, settlement and data availability. DUSK is used for execution and can move between Dusk L1 and DuskEVM through the bridge.
The transaction flow is also worth paying attention to.
A transaction first reaches the DuskEVM sequencer, then gets included in an L2 block. The batcher publishes the transaction data to DuskDS, while state commitments and fault proofs connect the resulting state to DuskDS settlement.
That last part is important because transaction inclusion and settlement aren't the same thing. Just seeing a transaction included doesn't mean you should assume finality based only on how much time has passed.
I also like that Dusk isn't forcing every application into the same environment.
For Solidity applications, EVM wallets and existing Ethereum tooling, DuskEVM is the obvious route.
For Rust/WASM contracts that need to work directly with the Dusk L1, DuskVM remains the option.
So the interesting part isn't simply "Dusk now has EVM."
It's that Dusk is giving developers a familiar execution environment while keeping it connected to its own settlement and data-availability layer.
@Dusk_Foundation
#dusk
$DUSK
If you're already building with Solidity, Vyper, Foundry, Hardhat, viem or ethers, the idea is to bring that familiar workflow into the Dusk stack.
But the part I find more interesting is what happens underneath.
DuskEVM is the Ethereum-compatible execution environment, while DuskDS handles consensus, settlement and data availability. DUSK is used for execution and can move between Dusk L1 and DuskEVM through the bridge.
The transaction flow is also worth paying attention to.
A transaction first reaches the DuskEVM sequencer, then gets included in an L2 block. The batcher publishes the transaction data to DuskDS, while state commitments and fault proofs connect the resulting state to DuskDS settlement.
That last part is important because transaction inclusion and settlement aren't the same thing. Just seeing a transaction included doesn't mean you should assume finality based only on how much time has passed.
I also like that Dusk isn't forcing every application into the same environment.
For Solidity applications, EVM wallets and existing Ethereum tooling, DuskEVM is the obvious route.
For Rust/WASM contracts that need to work directly with the Dusk L1, DuskVM remains the option.
So the interesting part isn't simply "Dusk now has EVM."
It's that Dusk is giving developers a familiar execution environment while keeping it connected to its own settlement and data-availability layer.
@Dusk_Foundation
#dusk
$DUSK