I went back through the Dusk documentation last night, and I came away more interested in the design questions than technical claims.

The first thing that clicked was the split between Moonlight and Phoenix. Moonlight is account-based, with a public key, nonce and balance, while Phoenix uses UTXOs as “notes” inside a Merkle tree. Moonlight transaction fields include from, to, value, nonce, deposit, data, gas_limit, gas_price and signature, with maximum gas calculated as gas_limit × gas_price.

Phoenix gets interesting. It uses the Jubjub curve, with public keys (A,B), secret keys (a,b), and a view key (a,B). The note structure includes type, com, enc, npk, R and encsender. The one-time note key is derived as npk = H(rA)G + B, while the spending key is nsk = H(aR) + b.

I’m still trying to understand the trust boundary around ZK proof generation and delegated scanning. The documentation says third parties can generate proofs or scan using view keys without getting spending authority, but where are the failure points?

And with nullifiers, recent Merkle roots, and gas handled inside the proof, how does this behave under adversarial network conditions? Which parts are decentralized, and which assumptions should users scrutinize?

#dusk $DUSK @Dusk