A chain of keys being regenerated doesn’t mean the wallet is fully restored. In the Dusk W3sper documentation, I saw a very hard warning: don’t directly use the newly generated Profile to construct a transfer, because it lacks the synchronized Bookkeeper records—you won’t be able to get the required balance and nonce. W3sper lays out the boundaries clearly: besides a recoverable key store, the client that signs for itself must also maintain the already-synchronized asset state, including the public account nonce and shielded notes. This detail splits “I have the private key” from “I can safely spend this money.”
Pressure usually shows up after recovery. Suppose an application clears local data and regenerates an identity; the page still displays the original account, so users naturally assume everything is back to normal. But if synchronization hasn’t finished yet, the transfer can’t be constructed correctly. The assets haven’t disappeared, yet the user gets stuck first on what looks like a balance or network issue. If developers only implement key recovery and don’t show state recovery, they shift the debugging cost onto users and customer support. This isn’t a protocol defect in $DUSK ; rather, it shows that the spendable state of shielded assets can’t be replaced by an address string.@Dusk The ecosystem needs to display “identity has been found back” and “funds state has been synchronized” separately, and explicitly block transfers until the latter is complete.#dusk