What I find most interesting about Dusk isn’t whether the transfer amount stays shielded. That part can work exactly as intended.
The real problem appears one step later.
A user can have a valid session, a properly bound receiving wallet, and a correctly constructed transfer. The Phoenix proof verifies, and the transaction details remain private.
But that still doesn’t guarantee the transfer actually completes.
The controlled-transfer layer can perform another check: is the receiving wallet permitted to become a holder of this asset?
That distinction matters.
Phoenix can prove that the shielded spending path is valid without proving that the recipient is authorized to enter the asset’s holder state.
So you can end up with:
Phoenix proof: PASS
Privacy: PASS
Holder-state transition: REJECTED

That creates an important infrastructure question: if the proof succeeds but ownership never changes, what exactly should the sender consider “successful”?
This is the split I think is easy to overlook on Dusk:
Phoenix protects the transfer details.
Controlled-transfer logic determines whether the recipient can actually become the resulting holder.
That final state check can still stop the move after the private transfer proof has already passed.

@Dusk_Foundation
#dusk
$DUSK
$AKE
$ACE