zkLogin salt service: are salts stored or derived from a master secret?

zkLogin
1

I’m evaluating zkLogin for a protocol where users hold assets long term, and I’d like to understand the durability model before designing around it.

The address derives from the user’s OAuth sub and a salt. I’ve confirmed by running the SDK’s own derivation that a salt differing by one digit produces a completely different address, so the salt is not recoverable from anything else.

My question is about the salt service itself. Does Mysten’s service store per-user salts, or derive them deterministically from a master secret?

The distinction matters a lot. If salts are stored, then losing the service means every wallet it served is unrecoverable. If they’re derived from a master secret, salts are reproducible as long as that secret survives, which is a very different thing to plan around.

Related, for a self-hosted salt service: is the operator expected to back up and be able to restore the salt store or master secret, and is there a documented pattern for doing that safely?

One smaller question while I’m here. Since the address also depends on aud, the integrator’s OAuth client id, re-registering an OAuth application would appear to make every existing user’s wallet unreachable. Is there a recommended operational practice for integrators here, or is the client id simply permanent once users exist?

Thanks
Session

1 Like
2

so mysten’s service doesn’t keep a salt per user, it generates each one from a single master secret. same user always gets the same salt back. so the service itself isn’t the failure point, as long as that master secret exists the salts can always be regenerated.

if you run your own, backups are on you. either store each user’s salt in a db and back that up, or generate them from a master secret and just back up that secret. one catch with the master-secret route, you can’t ever change it later. docs don’t say much past keep backups and have a recovery plan.

and yeah, the client id is baked into the address. re-register the oauth app, get a new client id, and everyone’s address changes with no way to migrate them. tested it in code to be sure. so once people have funds in there, don’t touch that client id, treat it as permanent.

1 Like
3

The answer above is correct, and the current Sui docs now document this explicitly.

Enoki’s managed salt service uses derived salts rather than storing an independent salt per user. For self-hosting, Sui documents both DB-backed salts and deterministic derivation from a master seed as valid approaches.

One important operational point: if you use deterministic derivation, the master seed effectively becomes permanent infrastructure, and changing the OAuth aud / client ID will derive a different zkLogin address. Losing the salt or the ability to reproduce it means losing access to the original address.

So for long-lived assets, salt recovery and OAuth client-ID continuity should definitely be treated as part of the application’s key-management strategy.