#dusk $DUSK @Dusk Been digging through Dusk’s transaction architecture lately, and the Moonlight vs. Phoenix split is way more interesting than most people give it credit for.
Most retail traders dump it into a simple bucket. Phoenix is private, Moonlight isn't, so why bother with Moonlight? But that completely misses how state trade offs actually work. Moonlight operates on a standard, transparent account model boring, visible, but dirt cheap and trivial to inspect. Phoenix pushes everything into shielded notes and relies on ZK proofs to verify the math under the hood without showing its work.
Same settlement layer underneath, but completely different trade offs along the way. Phoenix buys you privacy, but you pay for it in heavy proof-generation overhead, bulkier state handling, and potential latency. Moonlight gives up privacy to stay fast and cheap.
If Dusk wants this two model setup to actually win, the UX burden can't be brutal. That’s why I'm keeping my eyes on a few specific metrics over the next few months:
Proof-generation latency on Phoenix
Failed/dropped private tx rates
Real world confirmation time differences between the two
Phoenix’s actual share of total daily transactions
Developer adoption are devs actually building dual-state apps, or picking one and sticking to it?
Having two transaction models is a great selling point on paper, but only if regular users can pick privacy without feeling like they're waiting on a clunky, expensive edge case.
Most retail traders dump it into a simple bucket. Phoenix is private, Moonlight isn't, so why bother with Moonlight? But that completely misses how state trade offs actually work. Moonlight operates on a standard, transparent account model boring, visible, but dirt cheap and trivial to inspect. Phoenix pushes everything into shielded notes and relies on ZK proofs to verify the math under the hood without showing its work.
Same settlement layer underneath, but completely different trade offs along the way. Phoenix buys you privacy, but you pay for it in heavy proof-generation overhead, bulkier state handling, and potential latency. Moonlight gives up privacy to stay fast and cheap.
If Dusk wants this two model setup to actually win, the UX burden can't be brutal. That’s why I'm keeping my eyes on a few specific metrics over the next few months:
Proof-generation latency on Phoenix
Failed/dropped private tx rates
Real world confirmation time differences between the two
Phoenix’s actual share of total daily transactions
Developer adoption are devs actually building dual-state apps, or picking one and sticking to it?
Having two transaction models is a great selling point on paper, but only if regular users can pick privacy without feeling like they're waiting on a clunky, expensive edge case.
