zkLogin via Slush - address stability and signature reproducibility across sessions?
Building a paid single-session web app on Sui. A person pays, and may stop mid-way and come back days later to finish. Payment is USDC, the wallet is Slush, and many buyers will be using zkLogin rather than a self-custodied key. Two things I need to be sure of before I design the resume path, and I would rather have this confirmed than assume it.
- Address stability. For a zkLogin wallet in Slush, is the derived Sui address stable across sessions and devices for the same Google account, over weeks? My understanding is the address is a function of the provider, the subject identifier and a salt, so it should be stable as long as the salt is - but the salt is managed by the wallet, not by me. Is there any normal situation where a returning user gets a different address? Clearing browser storage, a new device, re-authenticating, a wallet update, a change on the provider side?
- Signature reproducibility. If the same user signs the same fixed message on two different occasions, do they get the same signature bytes? My understanding is no for zkLogin, because the signature is over an ephemeral key with a ZK proof attached, so it varies per session even for identical input. If that is right, deriving a stable encryption key from a signature is not viable for zkLogin users, and I need a different mechanism. Please correct me if that is wrong, because a lot rests on it.
- If 2 is indeed no: what is the accepted pattern for client-side encryption keyed to a zkLogin identity, where the operator must not be able to read the data? Seal is the obvious answer and I am aware of it. I am asking whether there is a lighter path for a case where the data lives for at most 30 days and is deleted on completion.