Team Hangout w/ Emanuele Francioni (July 15th)

This week’s team hangout focused on how Dusk’s relationship with NPEX gives it a regulatory edge, the launch readiness of Hedger and DuskEVM, and how Dusk plans to support builders through targeted grants and future hackathons.

You can find a breakdown of the key questions and answers below:

Q1: How independent is Dusk of NPEX? Might the close ties with NPEX hinder the adoption of assets from other exchanges onto Dusk?

Dusk and NPEX are fully independent, but they have a deeply aligned, symbiotic relationship. NPEX uses Dusk’s technology to reduce costs and reach new market segments, while Dusk gains credibility and regulatory access through NPEX.

Without this partnership, Dusk would be seen as just another tech vendor, and would need to spend heavily to gain adoption. Instead, working with NPEX positions Dusk as part of the financial market infrastructure, which opens doors to regulators, asset issuers, and stablecoin providers.

In traditional finance, institutions prefer working with other institutions, not standalone tech platforms. Through NPEX, Dusk can access deals that wouldn’t otherwise be possible. For example, stablecoin issuers like Quantoz or Circle don’t want to deal with retail users directly. They rely on regulated entities like NPEX for redemptions and secondary markets, something Dusk can now help facilitate.

So rather than being a blocker, the NPEX relationship is what gives Dusk its edge.

Q2: Is Hedger finished at this moment or is it still in development? Will it be released alongside DuskEVM?

Hedger is finished and currently under review. The core protocol is complete, and test applications are being developed on top of it to explore its use cases, such as building an obfuscated trading book.

The launch timing is still being finalized. It may be released together with DuskEVM, or slightly afterward to create a second wave of news and momentum. Either way, the gap between the two launches won’t be long.

Q3: Can external developers implement things on DuskEVM which can’t be implemented on any other conventional EVMs?

Yes, DuskEVM offers unique capabilities that set it apart from other EVMs.

The biggest differentiator is regulatory integration. Applications built on DuskEVM can inherit the licenses of regulated partners like NPEX. That means developers can build regulated apps, like those handling securities, without needing to acquire licenses themselves, as long as their users are onboarded through a licensed entity.

This isn’t possible on Ethereum or other EVMs, where developers must either operate without licenses or rely on external institutions to bridge the gap. DuskEVM removes that friction.

In addition, developers can still deploy any standard smart contract or DApp just like they would on any other EVM, so it offers both compliance-focused and general-purpose use.

So while DuskEVM is fully compatible with the broader EVM ecosystem, it uniquely enables regulated, compliant applications, which no other EVM currently offers.

Q4: At this stage, is there anything that could delay or change the DuskEVM launch?

No, there are no remaining blockers. The team is confident that DuskEVM is on track and nothing stands in the way of the upcoming launch.

Q5: With DuskEVM coming, will there be more of a focus on grants going forward?

Yes, but with a more targeted approach.

The team plans to allocate resources toward external development, but not through open-ended grants. Instead, the focus will be on specific applications that align with Dusk’s roadmap and needs. The preference is to fund projects that already show product-market fit, rather than early-stage ideas.

That said, exceptional grant proposals could still be supported, but they’re rare.

More importantly, hackathons are seen as a better way to discover and fund promising projects. With DuskEVM enabling easier development and integration, the team is looking forward to hosting some of the first hackathons focused on regulated assets, something that hasn’t been done before.

Q6: Will Dusk eventually have a burn mechanism?

There are mixed views within the team. Some members are in favor, especially in scenarios like Dusk running its own sequencer for DuskEVM. In that case, burning gas fees could make sense. Another option being explored is burning a portion of trading fees on decentralized exchanges built on Dusk, similar to what BNB does on Binance.

That said, the team wants to fully understand the economic impact before committing to any burn model.

Interestingly, Dusk already has an implicit burn mechanism: currently, only 75% of block certificates are collected before a block is posted, meaning part of the coinbase reward is not distributed, effectively being burned. This was initially done to prioritize block speed over completeness.

Q7: What happened to the light bulb moment? Is that still something the team plans to implement in the future?

The “light bulb moment” refers to the economic protocol, an idea introduced by Matteo and Emanuele that would allow smart contracts to pay for gas themselves, enabling automated on-chain logic without user interaction.

This concept opens up powerful use cases, like auto-executing trades when price thresholds are hit, without requiring a user to sign a transaction.

There are two parts to this:

  1. Full smart contract–driven automation (the original economic protocol)
  • This is currently deprioritized. It’s still valuable, but it’s not the focus right now due to other priorities like DuskEVM launch.
  1. Account abstraction (included in DuskEVM)
  • While different in implementation, it enables similar outcomes: users can interact with apps without holding DUSK or signing every transaction manually. This significantly improves UX, especially for mainstream users unfamiliar with blockchain.

So while the original “light bulb” protocol is on pause, DuskEVM already delivers some of its intended benefits through account abstraction, with a strong focus on seamless UX for both crypto-native and traditional users.

Q8: Is DuskPay still part of the plans for this year?

Yes, but it’s currently deprioritized.

DuskPay was originally designed to meet upcoming legislation, but since that regulation has now been pushed to October, the team has shifted focus to launching DuskEVM and its initial applications.

The DuskPay MVP was previously built on Dusk Native, but it will instead be migrated to DuskEVM, which will make it easier to roll out and maintain.


Watch the full recording here: https://youtu.be/9lSAjCgprKw

Have more questions? Drop them below and we’ll include them in a future session.

Join us live every Tuesday at 4:00 PM CEST in the Dusk Community

See you next week!

2 Likes

Paying NPEX and giving away resources doesn’t align with product-market fit. If DUSK’s offerings had strong market demand, NPEX would be investing in us—not the other way around. What real commitment are they making? Right now, this looks more like subsidizing, not validating.

We’re learning from NPEX, yes—but that’s idea validation, not market validation. To truly test the protocol and our horizontal strategy, we need a broader set of lightweight, diverse proofs of concept—not polished, full-featured apps.

  • Can we really call this product-market validation if we are the ones subsidizing the effort?
  • Are we mistaking learning opportunities or idea exploration for actual validation of market demand?

Hackathons could be a great way to position Dusk—especially if we can demonstrate that startups using Dusk can launch compliant applications right out of the box. If that’s the case, it would be valuable to create an overview of common and costly regulatory requirements, paired with Dusk’s built-in solutions for each. This would clearly show how Dusk lowers the barrier to entry for new fintechs, making it easier and more affordable for them to bring compliant products to market. Granting startups is far more inspiring for the builder community than supporting established companies. It’s often young, agile companies that kickstart truly innovative solutions—unlike established businesses, which are typically held back by legacy systems and slow integration or migration processes. Supporting early-stage teams not only fuels innovation but also signals that Dusk is committed to empowering fresh ideas. This inspirational effect should definitely be taken into consideration.

I think there’s a misunderstanding here. Dusk isn’t paying NPEX, there’s no subsidy happening. The partnership is strategic, not transactional. NPEX gains operational efficiency, new tech capabilities, and access to untapped markets via Dusk. In return, Dusk gains regulatory access and institutional credibility, which unlocks easier market entry and connections that would otherwise be closed to a standalone protocol.

More info in our latest article here: NPEX: Dusk’s Regulatory Edge • Dusk

I was under the impression that Dusk is allocating resources to NPEX—for example, by building applications for them or supporting IT architecture and infrastructure migration projects. If that’s the case, I would expect Dusk to receive some form of compensation in return. That would show that NPEX genuinely values Dusk’s technology and contribution, rather than seeing it as a free or assumed resource.
I’ve seen vacacies on Dusk website for roles that were related to product delivery or application development for partners (It was for .NET programming language if I remember correct which is not used in Dusks stack) – assuming NPEX? So who is paying their payroll ? Dusk or the partner ?

It’s very exciting to see the DUSK EVM launch approaching. Everyone is worried that DUSK will be late with RWA, as on-chain domestic issuance will make a huge difference, but of course, not too late. I hope it launches within a few weeks. The launch of EURQ on the DUSK network is also crucial, and the DUSK EVM is essential for all of this. I hope the team doesn’t miss out on the altcoin bull run. That would be a complete disappointment. We have confidence in the team. I hope the DUSK EVM goes live smoothly and puts the negative commenters to shame.