Many discussions treat the fact that Dusk has gone live as a complete conclusion, but that sentence is missing the most important subject. A supplier website snapshot labels Dusk Native L1 as Live, DuskEVM as Testnet, Hedger as Testnet, and Dusk Trade as Building. Those four names refer to different layers: the network itself, the EVM-compatible execution path, privacy-related modules, and the application-layer direction for tokenized financial assets. Compressing them into a single status can cause people to conflate an existing network, testable functionality, and a product that is still under construction.
If the team’s problem is about what can be verified right now, it should first report the module name, and then its public status. A Live snapshot of Native L1 cannot be used to announce that DuskEVM is production-ready; a Testnet status for DuskEVM or Hedger cannot be stretched into claiming full deployment; and Dusk Trade being in Building is not the same as trading already being open. This is not meant to pour cold water—it’s to set clear boundaries for evaluation: when discussing the settlement base layer, test paths, or application-layer plans, the strength of evidence differs, and judgments should differ accordingly.
For the product owner, the most practical questions are not whether Dusk has really gone live, but what this particular layer we intend to use is called, what state it’s in, and what conclusions that state supports. Only after we supply the missing subject can we turn broad statements into verifiable technical judgments.
This also explains why the same project name may simultaneously show Live, Testnet, and Building. These tags are not meant to rank good versus bad; they indicate that readers should use different verification approaches: the underlying components that are live can be used to discuss existing network facts, test modules should be limited to the scope of experimentation, and the application layer under construction should only be discussed in terms of publicly stated directions.
@Dusk $DUSK #dusk
If the team’s problem is about what can be verified right now, it should first report the module name, and then its public status. A Live snapshot of Native L1 cannot be used to announce that DuskEVM is production-ready; a Testnet status for DuskEVM or Hedger cannot be stretched into claiming full deployment; and Dusk Trade being in Building is not the same as trading already being open. This is not meant to pour cold water—it’s to set clear boundaries for evaluation: when discussing the settlement base layer, test paths, or application-layer plans, the strength of evidence differs, and judgments should differ accordingly.
For the product owner, the most practical questions are not whether Dusk has really gone live, but what this particular layer we intend to use is called, what state it’s in, and what conclusions that state supports. Only after we supply the missing subject can we turn broad statements into verifiable technical judgments.
This also explains why the same project name may simultaneously show Live, Testnet, and Building. These tags are not meant to rank good versus bad; they indicate that readers should use different verification approaches: the underlying components that are live can be used to discuss existing network facts, test modules should be limited to the scope of experimentation, and the application layer under construction should only be discussed in terms of publicly stated directions.
@Dusk $DUSK #dusk