When researching Dusk, I’ve been pursuing one question for a long time: who actually controls Phoenix’s viewing key?
Back when I looked at privacy-oriented public chains, I usually started by checking TPS and ecosystem. After revisiting Dusk, I began focusing on something else: who holds the selective disclosure permissions determines who this chain is more friendly to.
Phoenix’s design made me stop and think for quite a while.
Shielded transactions use ZK proofs to verify validity, while hiding the amounts and participants. Viewing keys allow users to selectively authorize third parties to view transaction details.
This design direction is right.
But when I went through the viewing key control logic, I got stuck on a question that no one seems to ask directly.
Once a viewing key is given out, can it be revoked?
If it can’t be revoked, what should a user do when they authorized the regulator to view transactions today, but want to undo that authorization tomorrow?
If it can be revoked, what happens to the historical records that have already been viewed? Once viewed, that privacy no longer exists.
Moonlight maps to an account-based model, while Phoenix maps to a privacy model. Both models share DuskDS’s settlement layer, but I couldn’t find clear documentation on how the viewing key lifecycle is managed.
DuskVM is still in forthcoming status, and DuskEVM has only just gone live. NPEX has completed the tokenization of 300 million euros in securities, and the mainnet has been running for over a year. DUSK’s market cap is about $26.63 million, down more than 90% from its all-time high.
This architecture needs time to be validated—but the viewing key revocation mechanism is the answer to a question I wanted before validation.
Because privacy isn’t only about whether it can be disclosed; it’s also about whether it can truly be taken back.
I’m watching for one signal: does Dusk publish a complete viewing key lifecycle management mechanism, including authorization, revocation, and how it handles viewing historical permissions?
There is: Phoenix’s selective disclosure is real privacy tooling controlled by users.
There isn’t: what happens after a viewing key is handed over—users don’t know.
A: Viewing keys are generated and held by the user, so the right to revoke naturally belongs to the user
B: There’s no publicly documented revocation mechanism; the controllability of viewing keys relies on assumptions rather than a verified process
Which side are you on?
Not investment advice—trading involves risk. DYOR. $BTC
@Dusk $DUSK #dusk #BinanceSquare $ETH
Back when I looked at privacy-oriented public chains, I usually started by checking TPS and ecosystem. After revisiting Dusk, I began focusing on something else: who holds the selective disclosure permissions determines who this chain is more friendly to.
Phoenix’s design made me stop and think for quite a while.
Shielded transactions use ZK proofs to verify validity, while hiding the amounts and participants. Viewing keys allow users to selectively authorize third parties to view transaction details.
This design direction is right.
But when I went through the viewing key control logic, I got stuck on a question that no one seems to ask directly.
Once a viewing key is given out, can it be revoked?
If it can’t be revoked, what should a user do when they authorized the regulator to view transactions today, but want to undo that authorization tomorrow?
If it can be revoked, what happens to the historical records that have already been viewed? Once viewed, that privacy no longer exists.
Moonlight maps to an account-based model, while Phoenix maps to a privacy model. Both models share DuskDS’s settlement layer, but I couldn’t find clear documentation on how the viewing key lifecycle is managed.
DuskVM is still in forthcoming status, and DuskEVM has only just gone live. NPEX has completed the tokenization of 300 million euros in securities, and the mainnet has been running for over a year. DUSK’s market cap is about $26.63 million, down more than 90% from its all-time high.
This architecture needs time to be validated—but the viewing key revocation mechanism is the answer to a question I wanted before validation.
Because privacy isn’t only about whether it can be disclosed; it’s also about whether it can truly be taken back.
I’m watching for one signal: does Dusk publish a complete viewing key lifecycle management mechanism, including authorization, revocation, and how it handles viewing historical permissions?
There is: Phoenix’s selective disclosure is real privacy tooling controlled by users.
There isn’t: what happens after a viewing key is handed over—users don’t know.
A: Viewing keys are generated and held by the user, so the right to revoke naturally belongs to the user
B: There’s no publicly documented revocation mechanism; the controllability of viewing keys relies on assumptions rather than a verified process
Which side are you on?
Not investment advice—trading involves risk. DYOR. $BTC
@Dusk $DUSK #dusk #BinanceSquare $ETH
