skhyb

I went back through the documentation last night on the @Dusk transaction models and spent a few hours just trying to map how Moonlight and Phoenix actually fit together.

At first the distinction looked clean. Moonlight is the transparent, account-based side where each account keeps a public state that records its balance and nonce. Phoenix is the note-based shielded side: a note is structured around a recipient public key, a value v, and additional random scalars, with notes indexed inside a Merkle tree so a spender can prove inclusion without revealing the note itself. Spending requires a zero-knowledge proof and the publication of a nullifier so the network can reject double-spends. The docs also state that note values are bounded by 2^{64}-1.

Conversion paths between the two models (deposit into Phoenix notes, withdraw back to Moonlight accounts) are described, but I kept getting stuck on the exact security assumptions that hold during those hand-offs. The circuits are said to guarantee validity, yet I couldn’t find a clear statement on whether a single malformed conversion could affect the global nullifier set or the transparent balances that smart contracts rely on.

That raised a broader question for me about decentralization: if most value ends up living in Phoenix notes, how much practical governance power remains with the transparent account layer that contracts and oracles actually see?

Is the current circuit design and the 2^{64}-1 value bound considered final, or are there still open parameters around note generation, Merkle-tree depth, and nullifier uniqueness that the community is still iterating on?

Would appreciate any pointers from people who have gone deeper into the proofs.

#dusk $DUSK