#dusk $DUSK @Dusk #dusk $DUSK @Dusk_Foundation
Most L2s rent their data availability. Ethereum blobs, Celestia, somebody.
DuskEVM doesn't. Read the transaction lifecycle in the docs and it goes: the sequencer includes your transaction in an L2 block, then a batcher publishes that transaction data to DuskDS, then state commitments and fault proofs anchor it back to DuskDS settlement. Same chain doing consensus, settlement and DA for its own execution layer.
Then check the network updates page and there's a matching entry: blob transactions activated on mainnet at block 2,873,420 on 10 December 2025, requiring Rusk 1.4.1.
Two things follow from that, and they pull in opposite directions.
The good one: no external dependency in the settlement path. For a chain arguing that regulated assets need one coherent venue with one finality guarantee, outsourcing DA to a third network would have punched a hole straight through the pitch. This is architecturally consistent with what they say they're building.
The harder one: DA demand and L1 blockspace are now the same resource. Every DuskEVM transaction eventually costs DuskDS block space. If EVM usage ever gets heavy, L1 fee pressure and L2 cost stop being separate conversations. That's a real coupling, and it cuts both ways — it's also the mechanism by which EVM activity would actually generate fees for L1 validators rather than sitting in a parallel economy.
The honest caveat: DuskEVM is still labelled Testnet on Dusk's own homepage. So this coupling is designed, not yet stress-tested. The blob machinery is live on mainnet ahead of the load it was built for.
Would you rather an L2 own its DA and share its parent's blockspace, or rent DA elsewhere and stay cheap?
Most L2s rent their data availability. Ethereum blobs, Celestia, somebody.
DuskEVM doesn't. Read the transaction lifecycle in the docs and it goes: the sequencer includes your transaction in an L2 block, then a batcher publishes that transaction data to DuskDS, then state commitments and fault proofs anchor it back to DuskDS settlement. Same chain doing consensus, settlement and DA for its own execution layer.
Then check the network updates page and there's a matching entry: blob transactions activated on mainnet at block 2,873,420 on 10 December 2025, requiring Rusk 1.4.1.
Two things follow from that, and they pull in opposite directions.
The good one: no external dependency in the settlement path. For a chain arguing that regulated assets need one coherent venue with one finality guarantee, outsourcing DA to a third network would have punched a hole straight through the pitch. This is architecturally consistent with what they say they're building.
The harder one: DA demand and L1 blockspace are now the same resource. Every DuskEVM transaction eventually costs DuskDS block space. If EVM usage ever gets heavy, L1 fee pressure and L2 cost stop being separate conversations. That's a real coupling, and it cuts both ways — it's also the mechanism by which EVM activity would actually generate fees for L1 validators rather than sitting in a parallel economy.
The honest caveat: DuskEVM is still labelled Testnet on Dusk's own homepage. So this coupling is designed, not yet stress-tested. The blob machinery is live on mainnet ahead of the load it was built for.
Would you rather an L2 own its DA and share its parent's blockspace, or rent DA elsewhere and stay cheap?