I reviewed more than a dozen hands-on test posts on the DuskEVM testnet, and saw someone say: “Choose-and-disclose cards ‘in the caching layer’.”
On August 10, the DuskEVM testnet went live, and more and more hands-on posts appeared in the plaza. Some people used Solidity and Hardhat to deploy contracts, and said getting started was smoother than they’d imagined. The Hedger module runs confidential transactions using homomorphic encryption and zero-knowledge proofs; developers don’t need to learn new languages, and it really breaks a lot of people’s stereotypical impression that privacy chains are “anti-human.”
But when I came across one post, I stopped. The author said they’d done a selective disclosure test: private transfer → request authorization → show data to a specific party. The earlier steps all worked; payments and verification also passed. But it got stuck at the final “disclosure layer.” They assumed it was just testnet latency at first. Later they found that the routes had cleared and the Hedger status was also green—only the selective disclosure step was slower than expected. In the end, they pointed to something that hardly anyone talks about: the caching layer determines when the “privacy state” becomes usable for the next authorization call. @Dusk
This detail is actually more worth pondering than “how many TPS.” Selective disclosure is Dusk’s core selling point to institutions—transactions remain confidential, but audits are still possible. If this part already has latency on the testnet, then when the mainnet sees transaction volume pick up and multiple authorization requests pour in at the same time, can the caching layer hold up? The author even asked the question themselves: when multiple authorization reviews arrive at once, and the economic commitments must remain continuous, what exactly is making it work?
The DuskEVM testnet is open, and Hedger can run through successfully. The technical foundation is definitely moving forward. But between “it runs” and “institutions dare to use it,” there’s still a lot of pressure testing missing. Selective disclosure isn’t something you just need to “have”—it needs to be “steady” under real load. I’ll only say this chain is truly ready when I see someone share disclosure-latency data under high concurrency on the testnet.
#dusk $DUSK
On August 10, the DuskEVM testnet went live, and more and more hands-on posts appeared in the plaza. Some people used Solidity and Hardhat to deploy contracts, and said getting started was smoother than they’d imagined. The Hedger module runs confidential transactions using homomorphic encryption and zero-knowledge proofs; developers don’t need to learn new languages, and it really breaks a lot of people’s stereotypical impression that privacy chains are “anti-human.”
But when I came across one post, I stopped. The author said they’d done a selective disclosure test: private transfer → request authorization → show data to a specific party. The earlier steps all worked; payments and verification also passed. But it got stuck at the final “disclosure layer.” They assumed it was just testnet latency at first. Later they found that the routes had cleared and the Hedger status was also green—only the selective disclosure step was slower than expected. In the end, they pointed to something that hardly anyone talks about: the caching layer determines when the “privacy state” becomes usable for the next authorization call. @Dusk
This detail is actually more worth pondering than “how many TPS.” Selective disclosure is Dusk’s core selling point to institutions—transactions remain confidential, but audits are still possible. If this part already has latency on the testnet, then when the mainnet sees transaction volume pick up and multiple authorization requests pour in at the same time, can the caching layer hold up? The author even asked the question themselves: when multiple authorization reviews arrive at once, and the economic commitments must remain continuous, what exactly is making it work?
The DuskEVM testnet is open, and Hedger can run through successfully. The technical foundation is definitely moving forward. But between “it runs” and “institutions dare to use it,” there’s still a lot of pressure testing missing. Selective disclosure isn’t something you just need to “have”—it needs to be “steady” under real load. I’ll only say this chain is truly ready when I see someone share disclosure-latency data under high concurrency on the testnet.
#dusk $DUSK
