This week’s team hangout featured both Emanuele and Hein, diving into DuskEVM’s technical foundation, integration with DuskDS, and the unique architecture behind it.
They also answered questions around bridge audits, quantum resistance, throughput specs, testnet readiness, and regulatory conversations beyond the EU.
You can find a breakdown of the key questions and answers below 
Q1: When multisig and web wallet for staking?
This feature is currently not a top priority. The team has a packed roadmap and limited capacity, so multisig and web wallet support for staking isn’t on the immediate list.
That said, the community is encouraged to open an issue on GitHub outlining the desired functionality. The team will add it to the backlog, and others in the community are welcome to contribute or build it themselves.
Anyone can raise an issue here: GitHub · Where software is built
Q2: Are you guys in talk with non-EU institutions, specifically from Switzerland?
Yes. The team is in touch with various institutions in Switzerland, including private banks, startups, and venues like SIX. Switzerland, while outside the EU, is part of the broader EEA and has tech-neutral, forward-looking regulation, especially around tokenization.
There’s significant interest from private banking sectors looking to serve high-net-worth individuals via crypto, and some startups are exploring real estate and commodity tokenization (e.g. gold). While nothing short-term is planned, these are viewed as strategic relationships for future distribution and asset access.
Q3: What is the DuskEVM layer under the hood? Is it a modified OP Geth?
DuskEVM is Optimism derived, but with a unique integration into the Dusk architecture. The node itself is based on OP Geth, and is currently not modified.
Key components built on top include:
- Contract porting from Solidity to Dusk-compatible formats
- A translation layer for communication between Dusk DS (settlement layer) and DuskEVM
- Introduction of BLOB transactions into Dusk DS (similar to Ethereum but with slight differences)
These elements enable the DuskEVM to interact seamlessly with Dusk DS, while maintaining modular design principles.
Q4: Did the team have prior Ethereum experience, or was external help brought in to build DuskEVM?
Yes, some team members had prior Ethereum and L2 experience, especially with heavily modified Optimism forks.
An external party was brought in early to review the project plan and handle parts where they had more experience, such as analysis and contract work. Meanwhile, internal developers, especially those familiar with Dusk DS and contract development, ported contracts and worked on components like BLOB transactions.
The setup blends in-house protocol expertise with external EVM knowledge to build and validate the system effectively.
Q5: Will there be a separate node for Dusk DS and DuskEVM, or are they combined into one?
Initially, there will be two separate nodes, one for Dusk DS (data availability and settlement) and one for DuskEVM (application layer). This mirrors the structure of setups like Ethereum + Optimism.
However, Dusk’s architecture is evolving toward a tightly integrated system, not a traditional L1/L2 split. The long-term plan is to converge into a single executable with modular components, similar to how current Dusk nodes already allow users to run only the prover, full node, or other pieces.
Because Dusk DS and DuskEVM are part of the same protocol, they can understand and validate each other’s transactions. This enables the speed of optimistic rollups with finality guarantees closer to ZK rollups, without long challenge periods.
Q6: Will there be a bridge audit for DuskEVM?
A full external audit is not required because DuskEVM reuses audited Optimism components. The parts that have been modified or ported, such as the bridge logic, are undergoing internal validation and external review by the team at Lumos (a spin-off of auditing firm Blaze).
Lumos is deeply involved in the development and organically auditing the system as part of the build process. While a formal report may not be published, the depth of analysis and internal diagrams ensures a high level of security without delaying the launch.
Q7: Is Dusk quantum resistant, or just DuskEVM?
Only DuskEVM includes quantum-resistant components. The broader Dusk stack has some elements that are quantum resistant, but not all.
Q8: What is done and what is being worked on from a tech standpoint before DuskVM is ready for release?
Done / In Devnet:
- BLOB transactions are live and being tested
- Data availability contract is deployed and under validation
- Sidecar for BLOBs is in progress
- Message passing service is running, with some alignment work pending
Still in progress:
- Standard L1 bridge contract (to move DUSK between networks)
- UI support for BLOBs in the Explorer
- Bridge support in the web wallet
- Final validation and integration work
The development is being rolled out in phases. The data availability layer and BLOB-based state posting are already functioning, meaning DuskDS is validating the application layer.
The priority now is launching the application layer (DuskEVM) as soon as possible, even if some UI tools arrive slightly later.
A public testnet is also coming soon, allowing the community and partners to start deploying and experimenting.
Q9: What would be the technical limitation for a bank like Bunq to fully switch to something like Dusk?
It’s nearly impossible for a bank to fully migrate its infrastructure to a blockchain, Dusk or otherwise. The main reason isn’t tech, but regulation and institutional design.
Banks rely on strict, centralized policies that demand clear responsibility. Decentralized systems, by design, distribute responsibility, making them incompatible with how banks operate under current rules.
Dusk isn’t trying to replace banking infrastructure. Instead, it aims to offer regulated settlement, clearance, and security trading tools, the foundation for RegFi. While elements like custody and payments are possible on-chain, full banking replacement doesn’t align with regulatory reality or Dusk’s focus.
Q10: What are the specifications of DuskEVM in terms of throughput, block times, and gas limits? How does it compare to other L2s?
For now, DuskEVM uses default parameters. Theoretical throughput is similar to Optimism, around 1,000 transactions per second, with plenty of room for future tuning.
Because DuskEVM will host only a limited number of application layers, blob usage will be more efficient. This could allow for higher performance compared to Ethereum, which supports many L2s posting blobs simultaneously.
The system is flexible and can scale further if needed, even supporting parallel app-layer instances for institutions. But the team emphasized that quality matters more than raw TPS, high-value, meaningful transactions are prioritized over high-volume, low-impact ones.
Watch the full recording here: https://youtu.be/rf8l0Z-B3bk
Got more questions? Drop them below and we’ll queue them up for the next session.
Join us live every Tuesday at 4:00 PM CEST in the Dusk Community
See you next week!