Buried in DuskEVM’s own docs is a detail that changes how I think about the “which layer is built for what” question: DuskEVM currently runs with no public mempool — sequencer only.
That’s a real architectural choice, not a rounding error. On most EVM chains, pending transactions sit in a visible mempool before inclusion, which is exactly the surface MEV bots and frontrunners exploit. DuskEVM skips that entirely, executing through a single sequencer, then posting batch data back to DuskDS for settlement and availability. DuskVM, by contrast, runs Dusk’s native Rust/WASM contracts directly against Phoenix/Moonlight transaction models — no EVM tooling, but privacy is native rather than bolted on.
What pulled me deeper: the August 16 bridge incident. A team-managed wallet used for bridge operations got flagged, addresses were disabled, and bridge services paused — the same bridge that moves DUSK between DuskDS and DuskEVM for gas. It’s a reminder that the connective layer between these two VMs is still an operational dependency, not a fully protocol-enforced handoff.
What I can’t confirm: actual DuskEVM testnet transaction counts or contract-deployment volume this week — Blockscout’s stats didn’t return without a JS-rendered session, so I’m going off documented architecture, not live throughput.
Which layer are builders actually choosing right now, and why?
@Dusk_Foundation $DUSK #dusk
That’s a real architectural choice, not a rounding error. On most EVM chains, pending transactions sit in a visible mempool before inclusion, which is exactly the surface MEV bots and frontrunners exploit. DuskEVM skips that entirely, executing through a single sequencer, then posting batch data back to DuskDS for settlement and availability. DuskVM, by contrast, runs Dusk’s native Rust/WASM contracts directly against Phoenix/Moonlight transaction models — no EVM tooling, but privacy is native rather than bolted on.
What pulled me deeper: the August 16 bridge incident. A team-managed wallet used for bridge operations got flagged, addresses were disabled, and bridge services paused — the same bridge that moves DUSK between DuskDS and DuskEVM for gas. It’s a reminder that the connective layer between these two VMs is still an operational dependency, not a fully protocol-enforced handoff.
What I can’t confirm: actual DuskEVM testnet transaction counts or contract-deployment volume this week — Blockscout’s stats didn’t return without a JS-rendered session, so I’m going off documented architecture, not live throughput.
Which layer are builders actually choosing right now, and why?
@Dusk_Foundation $DUSK #dusk