#dusk $DUSK @Dusk
Phoenix keeps double spend proofs in a Merkle tree of notes instead of an account ledger nO visible balances yet nobody can spend the same output twice. I wanted to see how that actually holds together.
Phoenix treats every unit of @Dusk_Foundation as a UTXO called a note. Each note lives as a hash inside a Merkle tree. Spending a note doesn't erase it that's not how these trees work. Instead spending it produces a nullifier: a value derived from the note's secret key that appears publicly once it's used. The network never learns which note the nullifier came from, only that it's now invalid. Try to reuse the same note, and the duplicate nullifier gives it away instantly.
That design is why Phoenix can stay shielded and still be enforceable. Regulated finance can't tolerate ambiguous settlement, and nullifiers give deterministic finality without exposing sender receiver or amount. A view key lets an owner selectively prove what a note contained so auditability is not traded away entirely it's deferred to the key holder.
What I couldn't fully resolve from docs: how nullifier set growth is managed long term and what the proving overhead looks like as the note tree scales under sustained institutional volume rather than test Conditions.
Genuinely curious has anyone seen throughput numbers for Phoenix proof generation under real settlement load not testnet benchmarks?
$DUSK #dusk
Phoenix keeps double spend proofs in a Merkle tree of notes instead of an account ledger nO visible balances yet nobody can spend the same output twice. I wanted to see how that actually holds together.
Phoenix treats every unit of @Dusk_Foundation as a UTXO called a note. Each note lives as a hash inside a Merkle tree. Spending a note doesn't erase it that's not how these trees work. Instead spending it produces a nullifier: a value derived from the note's secret key that appears publicly once it's used. The network never learns which note the nullifier came from, only that it's now invalid. Try to reuse the same note, and the duplicate nullifier gives it away instantly.
That design is why Phoenix can stay shielded and still be enforceable. Regulated finance can't tolerate ambiguous settlement, and nullifiers give deterministic finality without exposing sender receiver or amount. A view key lets an owner selectively prove what a note contained so auditability is not traded away entirely it's deferred to the key holder.
What I couldn't fully resolve from docs: how nullifier set growth is managed long term and what the proving overhead looks like as the note tree scales under sustained institutional volume rather than test Conditions.
Genuinely curious has anyone seen throughput numbers for Phoenix proof generation under real settlement load not testnet benchmarks?
$DUSK #dusk