This week’s team hangout featured Marta stepping into her new role as Project Lead for DuskEVM. The conversation covered updates on DuskEVM’s progress and how it stacks up against other chains, the role of Hedger and Zedger in bringing privacy to the EVM, and Dusk’s long-term approach to security and quantum-proof algorithms.
You can find a breakdown of the key questions and answers below 
Q1: Why did you become the project lead for DuskEVM, and what are your main activities in this role?
- Marta has been with Dusk for several years, leading the research team and working on the privacy aspects of Dusk’s L1.
- Over time, she moved from working on specific cryptographic primitives to gaining a broader view of the protocol and how all components connect.
- Her experience managing the research team prepared her for a larger project management role, coordinating across multiple teams and technologies.
- As project lead for DuskEVM, her main activities are:
- Tracking progress of all components and how they fit together
- Planning next steps and anticipating challenges
- Making sure each part of DuskEVM aligns with the bigger picture
- Marta’s structured approach, project board management skills, and ability to balance technical detail with big-picture planning made her the best fit for this role.
Q2: Beyond RWAs, what unique and exciting use cases do DuskEVM’s special features enable compared to ordinary EVM chains?
- DuskEVM uses standard Ethereum tooling, so most EVM apps can run here with minimal changes.
- Inherits Dusk L1’s native privacy features, enabling confidential transactions and use cases not possible on ordinary EVM chains.
- Compliance-first framework: privacy and regulatory requirements are built in, instead of being bolted on by projects individually.
- Enables confidential versions of DeFi flows (trading, settlement, payments) with selective disclosure and privacy-preserving state.
- Hein highlighted upcoming fast finality features, improving compliance and giving DuskEVM a unique path vs other L2s.
- Regulatory changes shaped development (e.g., Phoenix on L1), but new exemptions like the DLT Pilot are reducing friction, creating room for compliant EVM apps.
- The most exciting near-term outcome: live tokenization on DuskEVM, extended with privacy layers like Hedger.
Q3: What novel applications could realistically be built on DuskEVM that would not be feasible on a standard EVM?
- Most EVM apps can technically run elsewhere, but on DuskEVM they gain additional support in compliance, privacy, and regulatory alignment.
- The key differentiator is bridging to Dusk L1, which enables privacy features for confidential transactions, not possible on standard EVM chains.
- This creates the ability to combine familiar EVM functionality with native privacy.
- L1 and L2 improvements work synergetically:
- Privacy research on L1 informs extensions on DuskEVM.
- L1 has been adapted to integrate smoothly with DuskEVM.
- Developers benefit from easier composability and full API/tooling equivalence.
- The value isn’t only in enabling something entirely new, but in allowing existing EVM projects to run seamlessly while gaining privacy and compliance from Dusk.
Q4: How will the launch marketing for DuskEVM be different from the past, and what is the plan for attracting third-party developers?
- Lessons were learned from the mainnet launch and there is a structured, fully rounded plan.
- Marketing agreements are included in partner deals, ensuring joint promotion such as co-hosted spaces and shared exposure.
- Focus is not only on “pay-to-play” but also on building strong products that users genuinely want and promote themselves.
- Product-market fit is seen as more important than short-term hype, marketing alone cannot sustain adoption without real usage.
- Partnerships with larger players are being structured to leverage both their marketing resources and their user bases.
- Dusk’s long track record and work with regulated entities create trust and make conversations with serious partners easier.
- Interest from bigger parties in deploying on DuskEVM has been stronger than expected, with promising discussions.
- STOX will be a key application for visibility and adoption, serving as the first major showcase of what DuskEVM enables under the DLT Pilot framework.
Q5: How many days or weeks ahead of launch will the launch date be announced?
- The development side will hand over once the stack is complete, stable, and working as expected.
- External partners also influence the timeline if they want to be launch partners.
- Integration testing is critical: all components may work individually, but need extra time to ensure they run smoothly together.
- Proper testing is prioritized so that when launch happens, everything works as expected.
- The announcement will be made once those boxes are ticked, the priority is delivering as soon as possible with full stability.
Q6: What has been the biggest challenge in building DuskEVM?
- Integration has been the biggest challenge, making sure all components fit together smoothly.
- During integration, new missing pieces often appear, requiring additional software to connect components properly.
- Differences between Dusk and Ethereum concepts (APIs, behavior, finality) introduced subtle but complex issues that were difficult to debug and resolve.
- The learning curve of adapting Dusk’s own stack to Ethereum’s ecosystem required deep contextual awareness of both systems.
- At a high level the design may look straightforward, but implementation revealed many hidden details that consumed the most time and effort.
- Small nuances in translating functions and specifications had major downstream effects, showing how much of the work lies in the details.
Q7: What are the remaining tasks before the official launch of DuskEVM?
- Complete the final testing phase, moving from Devnet to full mainnet tests.
- Run internal security reviews on contracts.
- Finalize binaries and integration across components.
- Wrap up debugging and frontend polish (e.g., bridging interface in the web wallet, already well underway).
- Update and finalize documentation.
- Recent team reviews showed everything well-aligned and progressing smoothly, with confidence building towards launch.
Q8: Will all components that enable L2 DuskEVM and Hedger be open source before launch, or will some parts remain private?
- Some components will remain closed source initially, especially on the Hedger side, which is considered core IP.
- The current DuskEVM implementation is mostly a translation layer; parts of it will become open source over time, especially as it evolves (e.g., moving to Rust, adding fast finality).
- The translation layer itself is closed source for now, but this will change once the roadmap progresses beyond the MVP stage.
- Hedger is also closed source at the moment, not for secrecy but because the MVP needs further cleanup, documentation, and refinements before release.
- The long-term plan is for everything to be open source, this has been the policy from the beginning.
- Closed source at this stage reflects work-in-progress status, not an intent to keep things private permanently.
- Once open sourced, anyone could run their own DuskEVM instances if they wanted.
Q9: We saw the GitHub commit that could lead to a testnet push for DuskEVM, can you explain what this means?
- The commit relates to the DuskEVM Genesis repo, which contains the configuration details for launching the chain.
- Previously this was managed through Lumos (a third party), but it has now been fully moved under Dusk’s own repositories.
- The repo is used to start new instances or reset existing states.
- Updates will follow, including separate configurations for testnet and mainnet.
- These files may eventually be hosted on IPFS or another location, but they are essentially configuration data, not core code changes.
- These configurations are essential building blocks for setting up and running the network.
Q10: How would Dusk handle a critical circuit-level bug (governance/safeguards beyond a hard fork, and ways to audit/detect past exploits in Phoenix)?
- Detection depends on the issue: some classes are detectable, others may not be.
- Phoenix has been heavily reviewed, audited, formally analyzed, and live for a long time, so the likelihood is low, but risk can never be fully eliminated.
- Components are designed to be modular, so circuits can be swapped or replaced if needed.
- A circuit change would require an update in Rusk and a coordinated network upgrade.
- Worst-case financial exploits like infinite minting or stolen notes would be detectable and could be mitigated by rolling back to a safe point and reapplying blocks with a fix.
- Privacy-related failures (e.g., data exposure) cannot be rolled back once information is revealed.
- The team has prepared for known risk classes (e.g., elliptic curve or protocol-level bugs) with paths to switch primitives if needed.
- Post-quantum security has been considered: if quantum computers break current assumptions, both Dusk and the wider crypto ecosystem would need to migrate to quantum-resistant primitives.
- Because DuskEVM is Optimism-based, improvements in quantum safety adopted upstream can also be inherited by Dusk.
Q11: What is the state of quantum-proof algorithms in general, and what is planned to be implemented in Dusk?
- Cryptographic security depends on assumptions about which problems are hard to solve. Classical cryptography often relies on the discrete log problem, which can be broken by powerful quantum computers.
- Post-quantum protocols are built on different assumptions, such as lattices, hash functions, or code theory. These are not known to be vulnerable to quantum attacks.
- NIST is in the process of standardizing post-quantum protocols, and they are slowly gaining adoption. Current limitations include larger proof sizes and slower computation compared to today’s SNARKs.
- Some projects only implement post-quantum elements partially (e.g., in proofs but not in keys), which doesn’t make the whole stack quantum secure.
- A full post-quantum stack is complex and not yet competitive for large-scale applications. Most big projects, including Dusk, still rely on classical cryptography for scalability and performance.
- For Dusk, the focus is on running a secure, stable system now that is safe for the next 5–10 years, while monitoring the progress of post-quantum research.
- The plan is to transition gradually as the technology matures and becomes properly tested, adopting post-quantum protocols step by step.
- This applies not only to zero-knowledge proofs, but also to signatures, keys, and other cryptographic primitives.
- Because DuskEVM is Optimism-based, improvements in quantum safety adopted upstream can also be inherited by Dusk.
Q12: How much work is needed for Zedger to be implemented?
- The specification for most functionalities is already complete.
- A minimum viable product exists, though it hasn’t been fully tested yet.
- Development priorities shifted, but the implementation is solid and can be resumed when needed.
- Hedger and the industry’s move toward ERC-20 compliance changed the landscape, so Zedger’s role may depend on partner needs.
- Zedger could still be used for partners who don’t require ERC-20 compliance.
- The work already done can be published for others to build on, even if priorities move elsewhere.
Q13: Do you see any benefits in adding MPC (multi-party computation) into the privacy stack?
- MPC has already been used in Dusk for generating the toxic waste in Phoenix’s trusted setup.
- It can be valuable when distributing trust, such as for key generation or ownership management of contracts.
- However, this would more likely be applied at the application layer (e.g., smart contracts) rather than built directly into Dusk’s core protocols.
- Current demand for MPC is limited, and the existing tech stack already addresses most of the target market’s needs.
Q14: How does the cryptography used in Dusk compare to other projects?
- Dusk makes extensive use of cryptography across its stack, likely more than most projects.
- Core primitives include elliptic curve cryptography (private/public keys, signatures), hash functions (blocks, commitments, data compression), and zero-knowledge proofs (validating computations privately).
- Hedger adds homomorphic encryption, enabling proofs that balances are updated correctly in encrypted form without revealing plaintext values.
- This use is tailored: homomorphic encryption is applied specifically for transaction correctness, not as a general-purpose system.
- The big shift with SNARKs (and why Dusk uses Plonk) is the ability to write generic circuits representing any computation, not just narrow proofs.
- Plonk’s universal setup is especially valuable: circuits can be updated without redoing trusted setups.
- Every protocol has trade-offs, some are more efficient for specific use cases, others more general. Dusk’s approach is to choose the cryptographic tools best suited to its architecture and goals.
Watch the full recording here: https://youtu.be/D7igDOEUhlg
Have more questions? Drop them below and we’ll include them in a future session.
Join us live every week in the Dusk Community
See you next week!