The privacy detail I didn’t expect: a Phoenix transfer can hide the participants and transferred value, while the transaction itself can still be visible to a node’s mempool.
Dusk’s own docs draw that boundary clearly. Phoenix shields values and participants, but exposes the cryptographic data needed to prove note spends.
Separately, anyone with GraphQL access to a node can query that node’s real mempool, and explorer metadata may include transaction type, fee, and gas usage depending on the model and contract.
Factually, that is not a privacy failure. It is a different privacy promise: confidential economic data, not invisible network activity.
What caught my attention is the design trade-off. For financial applications, public verifiability can coexist with hidden counterparties and amounts, while timing and fee-related metadata still remain part of the observable surface.
That makes DUSK privacy more precise than the usual “everything is hidden” shorthand. I’m still watching whether application design explicitly treats metadata exposure as part of its privacy model.
@Dusk $DUSK #dusk
Dusk’s own docs draw that boundary clearly. Phoenix shields values and participants, but exposes the cryptographic data needed to prove note spends.
Separately, anyone with GraphQL access to a node can query that node’s real mempool, and explorer metadata may include transaction type, fee, and gas usage depending on the model and contract.
Factually, that is not a privacy failure. It is a different privacy promise: confidential economic data, not invisible network activity.
What caught my attention is the design trade-off. For financial applications, public verifiability can coexist with hidden counterparties and amounts, while timing and fee-related metadata still remain part of the observable surface.
That makes DUSK privacy more precise than the usual “everything is hidden” shorthand. I’m still watching whether application design explicitly treats metadata exposure as part of its privacy model.
@Dusk $DUSK #dusk
