DuskEVM looks for a separate fee for each transaction—an EIP-1559-style execution fee, and a separate data-availability fee charged for posting batch data on DuskDS. This two-tier fee model is automatically estimated in wallets/SDKs, so most users don’t even realize that the gas they pay is actually the combined cost of two different things. What’s interesting is that DuskEVM is pitched as an “EVM-compatible scaling layer,” but this data-availability dependency reveals that DuskEVM isn’t actually independent—finality and data storage for every transaction are still settled on DuskDS. In other words, DuskEVM doesn’t have its own throughput capacity; it’s directly bounded by the capacity of the base layer (DuskDS), just like a rollup architecture where L2 appears “faster,” but its security and data guarantees still depend on L1. That’s why when DuskDS is under load, both the cost and speed of DuskEVM can be automatically affected—regardless of whether DuskEVM has its own separate execution layer.
$DUSK #dusk @Dusk