I kept seeing Moonlight and Phoenix mentioned separately.
So I started with one question:
Why does @Dusk_Foundation need two transaction models?
Moonlight uses public, account-based transfers.
Phoenix uses shielded, note-based transfers with zero-knowledge proofs.
Both settle on DuskDS.
The difference is what information becomes visible.
Moonlight exposes balances and transfer details.
Phoenix keeps transaction information shielded while still proving the transaction follows the required rules.
That distinction makes more sense when you think about financial activity.
Some flows need public records.
Others involve information that should not be visible to every network observer.
Dusk does not force both situations into the same transaction model.
I find that design more interesting than simply calling $DUSK a privacy coin. #dusk
There is also a practical question.
Different transaction models mean different development and integration requirements.
So I want to see how naturally applications choose between them.
The technical separation makes sense to me.
The developer experience is the part I still want to understand.
@Dusk_Foundation $DUSK #dusk
So I started with one question:
Why does @Dusk_Foundation need two transaction models?
Moonlight uses public, account-based transfers.
Phoenix uses shielded, note-based transfers with zero-knowledge proofs.
Both settle on DuskDS.
The difference is what information becomes visible.
Moonlight exposes balances and transfer details.
Phoenix keeps transaction information shielded while still proving the transaction follows the required rules.
That distinction makes more sense when you think about financial activity.
Some flows need public records.
Others involve information that should not be visible to every network observer.
Dusk does not force both situations into the same transaction model.
I find that design more interesting than simply calling $DUSK a privacy coin. #dusk
There is also a practical question.
Different transaction models mean different development and integration requirements.
So I want to see how naturally applications choose between them.
The technical separation makes sense to me.
The developer experience is the part I still want to understand.
@Dusk_Foundation $DUSK #dusk