The Dusk detail that made me look twice isn’t the ZK stack — it’s what the wallet does when it doesn’t know whether a shielded transaction succeeded.

In Dusk Wallet v0.1.0, Phoenix transactions gained “pending-nullifier reservation” tracking. Its changelog says those reservations are not automatically released after a watcher timeout, an unknown status, a removed status, or a single missing mempool poll.

Why deliberately keep funds tied up after uncertainty?

Because Phoenix spends notes. If the wallet immediately reused the same spendable note set while the first transaction might still land, it could build conflicting shielded spends. Dusk also added a spend mutex to stop concurrent Phoenix sends from being constructed against the same notes.

Fact: this is wallet-side safety logic, not a new consensus rule. My interpretation: Dusk is choosing conservative UX over optimistic balance availability when transaction state is ambiguous.

That trade-off matters. Privacy systems need more than strong cryptography; wallet state handling must stay safe when network visibility is incomplete.

For DUSK, I’m watching whether future wallet releases can shorten that “uncertain” period without weakening protection. How aggressively should a privacy wallet unlock funds when chain state is unclear?

@Dusk $DUSK #dusk