@Dusk #dusk $DUSK

I almost skipped over one detail in Dusk's technical docs that changed how I think about DuskEVM. It runs on the OP Stack, the same framework Optimism uses for rollups. At first that seemed like smart engineering, reuse proven code instead of reinventing an EVM environment from zero.

The deeper I went, the more it looked like a real dependency, not just borrowed infrastructure. Building a fully compatible EVM environment is slow and risky. Plenty of chains shipped buggy implementations because matching Ethereum's subtle behavior is harder than it looks. OP Stack sidesteps that risk.

But it creates a different one. DuskEVM's execution layer now inherits design decisions, upgrade cycles, and security assumptions from code Dusk doesn't fully control. Settlement and data availability stay on DuskDS, which keeps core financial guarantees native. The execution layer where Solidity contracts run is coupled to another ecosystem's roadmap.

Here's what doesn't get discussed. EVM compatibility isn't just a developer win. It means Dusk's execution security is partly a function of how well OP Stack gets maintained over time. That's not necessarily bad, but it's a risk transfer.

I wonder if builders evaluating DuskEVM are actually pricing in that dependency, or just seeing "EVM compatible" and assuming the risk profile is the same as building on Dusk natively.

Is borrowing infrastructure like OP Stack a smart trade-off for newer chains, or does it quietly transfer risk that gets underestimated?

$RED $MAGMA

How do you view Dusk's OP Stack dependency for DuskEVM?