A W3sper wallet can derive a real Dusk profile, show me an address, and still be unable to build the first transfer.
The hidden work is Bookkeeper state. W3sper gives me transaction builders, but it does not turn a fresh Profile into a complete headless wallet. If I generate keys and jump straight to sending, that Profile has no synchronized Bookkeeper entry, so the builder cannot pull the balance and nonce state it needs.
Phoenix makes this harder to fake. A signing service also has to keep synchronized shielded notes, not just the secret key. So key custody can be correct while spendable state is stale.
The bad part is the wallet can look finished. I can create the account, fund it, protect the key, then hit Send and discover my backend never rebuilt the state that makes that DUSK spendable.
If I were running a headless Dusk treasury, I would test recovery by restoring the keys into an empty database and making the wallet resynchronize before it signs anything.
On Dusk, backing up the key is not the same as backing up the wallet workflow.
#dusk $DUSK @Dusk
The hidden work is Bookkeeper state. W3sper gives me transaction builders, but it does not turn a fresh Profile into a complete headless wallet. If I generate keys and jump straight to sending, that Profile has no synchronized Bookkeeper entry, so the builder cannot pull the balance and nonce state it needs.
Phoenix makes this harder to fake. A signing service also has to keep synchronized shielded notes, not just the secret key. So key custody can be correct while spendable state is stale.
The bad part is the wallet can look finished. I can create the account, fund it, protect the key, then hit Send and discover my backend never rebuilt the state that makes that DUSK spendable.
If I were running a headless Dusk treasury, I would test recovery by restoring the keys into an empty database and making the wallet resynchronize before it signs anything.
On Dusk, backing up the key is not the same as backing up the wallet workflow.
#dusk $DUSK @Dusk