Today I directly checked the mainnet statistics API for @Dusk . I wasn’t focused on the “supporting private transactions” line in the feature description; I was focused on whether users actually keep using this route. As of August 19, the cumulative finalized transactions returned by the official nodes are about 68,300, of which roughly 63,600 are public transactions and about 4,700 are shielded transactions. The public account count is 891. This snapshot doesn’t equal active users, and it can’t be used to infer revenue, but it’s enough to remind me: having privacy in the protocol and having a real need for privacy are two completely different questions.
Dusk’s Phoenix hides amounts and the specific transfer relationships using encrypted notes and zero-knowledge proofs, while Moonlight keeps public accounts. It’s clear why the dual-track design makes sense: exchange crediting and financial reconciliation can go through the public path, while sensitive fund flows can go through the private path. But how users ultimately choose depends not only on how strong the cryptography is—it also depends on whether the wallet is convenient, whether proof generation and waiting are stable, whether the recipient can scan correctly, and whether the application is willing to support a shielded state.
When things are stable, one successful private transfer is easy to be viewed as the product “working.” The real pressure comes when note counts increase, when wallets come back online after being offline for a long time and need to resync, when multiple people generate proofs simultaneously, or when users need to move shielded balances back to a public account to pay gas. If the recovery cost is too high at any step, the privacy feature will remain in the hands of only a small number of skilled users.
So when I look at the privacy adoption of #dusk , I won’t just look at cumulative transactions. What’s more useful afterward is whether the share of shielded transactions continues to increase, the number of unique addresses and repeat users, the proof failure rate, wallet sync time, and which real applications default to supporting Phoenix. For the privacy narrative of $DUSK to truly close the loop, the key isn’t whether it can hide a transaction—it’s whether ordinary users can reliably hide, retrieve, recover, and reconcile balances.
$ETH $USELESS
Dusk’s Phoenix hides amounts and the specific transfer relationships using encrypted notes and zero-knowledge proofs, while Moonlight keeps public accounts. It’s clear why the dual-track design makes sense: exchange crediting and financial reconciliation can go through the public path, while sensitive fund flows can go through the private path. But how users ultimately choose depends not only on how strong the cryptography is—it also depends on whether the wallet is convenient, whether proof generation and waiting are stable, whether the recipient can scan correctly, and whether the application is willing to support a shielded state.
When things are stable, one successful private transfer is easy to be viewed as the product “working.” The real pressure comes when note counts increase, when wallets come back online after being offline for a long time and need to resync, when multiple people generate proofs simultaneously, or when users need to move shielded balances back to a public account to pay gas. If the recovery cost is too high at any step, the privacy feature will remain in the hands of only a small number of skilled users.
So when I look at the privacy adoption of #dusk , I won’t just look at cumulative transactions. What’s more useful afterward is whether the share of shielded transactions continues to increase, the number of unique addresses and repeat users, the proof failure rate, wallet sync time, and which real applications default to supporting Phoenix. For the privacy narrative of $DUSK to truly close the loop, the key isn’t whether it can hide a transaction—it’s whether ordinary users can reliably hide, retrieve, recover, and reconcile balances.
$ETH $USELESS
