Dusk Town Hall: Episode 1 w/ Emanuele & Hein

General
1

This week’s Town Hall opened with a deep dive into DuskDS, the Rusk upgrade, and how this final update prepares the network for the full launch of DuskEVM. Both Ema and Hein walked through the broader architectural strategy, why Dusk shifted toward a modular L1/L2 design, and how Hedger extends Dusk’s privacy guarantees into the EVM world.

Below is a clear breakdown of the key points discussed :backhand_index_pointing_down:

1. The Rusk Upgrade

  • This is the last major update required on DuskDS before DuskEVM mainnet.
  • It introduces BLOB transaction processing, which ensures no further DuskDS upgrades are needed pre-launch.
  • The upgrade brings significant network improvements and aligns the L1 with everything the L2 requires.

2. Why DuskDS & DuskEVM Exist

DuskDS

  • Stands for Data Availability & Settlement.
  • Functions as Dusk’s L1, built with:
    • Full Privacy
    • Compliance baked in
  • DuskDS has been live on mainnet for over a year and performs excellently, but the custom stack made onboarding external developers difficult.

Why an EVM Layer Was Needed

  • Nearly all liquidity, tooling, and developer familiarity exist in the EVM ecosystem.
  • To unlock interoperability and attract the types of builders/partners Dusk works with, the team repurposed the L1 into a modular base for multiple L2s.
  • Result: DuskEVM, an EVM-equivalent execution layer that settles on DuskDS.
  • This design is the first of its kind: an EVM L2 settling on a non-EVM privacy L1.

4. Extending Privacy to the EVM: Hedger

Hedger, Dusk’s confidential transaction system for the EVM:

  • Hedger is an evolution of Zedger but designed for EVM.
  • It operates like a privacy-preserving module with compliance built-in.
  • Supports:
    • Native DUSK
    • ERC-20s
    • Dusk’s RWA token standard
  • Includes swapping and orderbook support
  • This enables:
    • Private trading
    • Private payments
    • Private RWA transfers
  • Dusk is extending industry-standard RWA token formats with privacy + compliance, something no other ecosystem currently provides.

Q1: Will hardware wallets be able to support natively issued securities on Dusk?

Yes. Hardware wallets can already support natively issued assets on Dusk.

Because these assets live on DuskEVM, they automatically inherit full EVM tooling compatibility. This means existing hardware wallets and signing devices work out of the box with tokens, securities, and smart-contract interactions issued on DuskEVM.

Q2: How easy or complex would it be for institutions or builders to spin up their own L2 settling on DuskDS?

Spinning up an additional L2 on Dusk is extremely easy.

Dusk’s architecture is intentionally modular:

  • Any new L2 can reuse the same settlement and data availability layer (DuskDS).
  • The setup is highly configurable, institutions can choose their own relayer or sequencer rules, run permissioned or permissionless environments, and tailor parameters to their operational or regulatory needs.
  • As long as the L2 respects the core requirements (like BLOB transaction formats), it can be adapted freely.

While this isn’t the primary focus of Dusk’s roadmap, the ability to deploy multiple specialized L2s is a natural side effect of the modular design.

Q3: To what extent do we expect other licensed exchanges to support DuskEVM?

Support from other licensed exchanges is expected to grow.

Dusk already has strong partnerships with regulated trading platforms like NPEX and 21X, with more venues set to be announced.

But the strategic horizon goes further:

Dusk’s architecture, regulatory alignment, and settlement design open the door for the network itself to hold licenses in the future. Instead of relying exclusively on external exchanges to support DuskEVM, the long-term trajectory includes the possibility of Dusk becoming a licensed venue in its own right.

Q4: What are Dusk’s biggest advantages after seven years of research and development?

Dusk’s biggest advantages come from building a modular stack specifically designed for RWAs, privacy, and compliance. Instead of bolting these features on afterward, the entire architecture was designed from day one with these requirements in mind.

Key advantages:

  1. A purpose-built modular stack: The infrastructure was engineered explicitly for regulated markets, privacy-preserving payments, and compliant tokenization.

  2. Flexibility without losing structure: The system is extremely flexible, partners can tune execution layers, run permissioned or permissionless environments, or configure their own sequencing rules. But it remains canonical as long as it follows the core settlement format (BLOB transactions), so everything stays interoperable.

  3. Alignment with real regulatory frameworks: Dusk’s architecture reflects real financial regulations, making it one of the few L1/L2 ecosystems ready for legally compliant, high-value asset flows.

Q5: What happens if EVM transactions don’t fit into a single BLOB on the L1?

If a batch of EVM transactions exceeds the size of one BLOB, the system simply creates additional BLOBs. BLOBs are produced on a fixed interval (currently ~7 minutes), and within each interval the batcher takes as much as fits into one BLOB, then rolls the remainder into the next one.

The protocol can generate multiple BLOBs per interval, up to around six with current parameters, and can scale further if needed. This ensures high throughput without congestion.

Listen to the recording: https://x.com/i/spaces/1BdxYZRovvXKX?s=20

Have more questions? Drop them is the Dusk Community

See you next week!

2 Likes