Dusk has been emphasizing that it’s different from other chains. Different in what way? Its self-developed Rusk virtual machine, the Phoenix privacy transaction model, and selective disclosure—these are all things built from scratch, with no compatibility with any existing standards. Eight years and tens of millions of funding poured in—what’s at stake is differentiation. @Dusk
But what is Dusk currently most urgently pushing? It’s DuskEVM—so it can run Solidity contracts, enabling EVM developers to migrate directly. In the July progress update, it said it’s in the final integration stage—clearly the highest priority task.
I’m not saying compatibility with the EVM is wrong. The reality is simple: developers out there won’t spend time learning a whole new set of things just for $DUSK . If you want people to come, you have to speak their language. That’s pragmatic.
But what is the cost of pragmatism? You spent eight years building differentiation, and now you’re bypassing it with a compatibility layer. Developers come in to write Solidity and run it on DuskEVM—what is the fundamental difference compared to running on any other EVM chain? Can Dusk’s self-developed privacy and compliance capabilities be fully preserved within the EVM compatibility layer, or will they be compromised? If they’re compromised, then after eight years of work, what you end up with is only a story. #dusk
Even more awkward is the timing. DuskEVM is still in final integration and hasn’t launched officially yet. Meanwhile, Dusk’s native system has already been running for a year and a half—on-chain, there are only a couple hundred transactions per day, and no one is using it. So the logic becomes: since nobody is using your own thing, you have to conform to someone else’s standard, hoping their developers will come.
This isn’t called an upgrade. It’s changing course after accepting defeat. Accepting defeat isn’t shameful—many projects have taken this step. But you have to admit a fact: the proprietary system built over eight years hasn’t won market validation. Whether Dusk EVM can actually draw people over is the next bet, not the payoff for the last one.
But what is Dusk currently most urgently pushing? It’s DuskEVM—so it can run Solidity contracts, enabling EVM developers to migrate directly. In the July progress update, it said it’s in the final integration stage—clearly the highest priority task.
I’m not saying compatibility with the EVM is wrong. The reality is simple: developers out there won’t spend time learning a whole new set of things just for $DUSK . If you want people to come, you have to speak their language. That’s pragmatic.
But what is the cost of pragmatism? You spent eight years building differentiation, and now you’re bypassing it with a compatibility layer. Developers come in to write Solidity and run it on DuskEVM—what is the fundamental difference compared to running on any other EVM chain? Can Dusk’s self-developed privacy and compliance capabilities be fully preserved within the EVM compatibility layer, or will they be compromised? If they’re compromised, then after eight years of work, what you end up with is only a story. #dusk
Even more awkward is the timing. DuskEVM is still in final integration and hasn’t launched officially yet. Meanwhile, Dusk’s native system has already been running for a year and a half—on-chain, there are only a couple hundred transactions per day, and no one is using it. So the logic becomes: since nobody is using your own thing, you have to conform to someone else’s standard, hoping their developers will come.
This isn’t called an upgrade. It’s changing course after accepting defeat. Accepting defeat isn’t shameful—many projects have taken this step. But you have to admit a fact: the proprietary system built over eight years hasn’t won market validation. Whether Dusk EVM can actually draw people over is the next bet, not the payoff for the last one.