Phoenix and Moonlight coexist: one privacy chain leaves a not-so-private loophole. I think that’s quite clear-headed.
People who work on privacy projects tend to go to extremes. Either they hide everything, claiming absolute privacy, or they get lazy and give up privacy in exchange for efficiency. Over the past couple of years, I’ve seen quite a few projects that advertise “privacy” ultimately die on this either-or choice: either audits and regulation can’t touch it at all, or the privacy features are basically a formality. When I was reading the documentation for $DUSK , I found it didn’t go to extremes.
Phoenix uses the UTXO model and does shielded transfers—covering both balances and the relationship between transactions.
Moonlight uses the account model, taking the public path, with balances and transfers fully visible.
These two channels coexist. Both can transfer DUSK, both can pay gas, and both can serve as the entry point for contract execution. Users choose whichever channel they prefer.
At first, I thought this was a compromise. Later I realized it’s actually leaving yourself a way out. Institutions need to be compliant and auditable—so it’s impossible for all fund flows to be fully black-boxed. In a regulatory sandbox, the very first thing they do is see where the money goes. Ordinary users want privacy and don’t want every single transfer to be exposed down to the last detail.
Forcing one model to satisfy two different demands usually means neither side is fully satisfied. It’s just like building a house with both a front door and a back door: the front door is for the people checking your paperwork, and the back door is for people who don’t want their neighbors watching them. It’s still the same house—no one thinks either door is unnecessary.
My take on designs like @Dusk is that they admit they can’t solve everyone’s needs—and that’s more honest than trying to cram together a one-size-fits-all solution. In this industry, what matters most in the end is often not whose ideals are purer, but who’s willing to chew through the real-world bones first. #dusk
People who work on privacy projects tend to go to extremes. Either they hide everything, claiming absolute privacy, or they get lazy and give up privacy in exchange for efficiency. Over the past couple of years, I’ve seen quite a few projects that advertise “privacy” ultimately die on this either-or choice: either audits and regulation can’t touch it at all, or the privacy features are basically a formality. When I was reading the documentation for $DUSK , I found it didn’t go to extremes.
Phoenix uses the UTXO model and does shielded transfers—covering both balances and the relationship between transactions.
Moonlight uses the account model, taking the public path, with balances and transfers fully visible.
These two channels coexist. Both can transfer DUSK, both can pay gas, and both can serve as the entry point for contract execution. Users choose whichever channel they prefer.
At first, I thought this was a compromise. Later I realized it’s actually leaving yourself a way out. Institutions need to be compliant and auditable—so it’s impossible for all fund flows to be fully black-boxed. In a regulatory sandbox, the very first thing they do is see where the money goes. Ordinary users want privacy and don’t want every single transfer to be exposed down to the last detail.
Forcing one model to satisfy two different demands usually means neither side is fully satisfied. It’s just like building a house with both a front door and a back door: the front door is for the people checking your paperwork, and the back door is for people who don’t want their neighbors watching them. It’s still the same house—no one thinks either door is unnecessary.
My take on designs like @Dusk is that they admit they can’t solve everyone’s needs—and that’s more honest than trying to cram together a one-size-fits-all solution. In this industry, what matters most in the end is often not whose ideals are purer, but who’s willing to chew through the real-world bones first. #dusk