Will changing my social account password alter my zkLogin address?

Changing a password does not itself change the inputs used to derive a zkLogin address. Continuity requires the same provider, user identifier, application client ID, salt, and derivation mode. Recovery into a different account can change the user identifier, even when its displayed name looks familiar.

Can blockchain records restore a missing zkLogin user salt?

Normal zkLogin transaction records do not provide a backup of the user salt. Recorded addresses and transaction digests cannot replace the original value. Recovery requires a retained salt or the original backend material capable of reproducing it; the proof does not publish that secret.

Does logging out invalidate a copied zkLogin session key and proof?

Logging out does not itself change a proof’s encoded expiry epoch. Someone retaining the matching private key and complete valid proof inputs may still authorize transactions within that session’s permitted lifetime. Deleting local session files removes those local copies, not copies held elsewhere.

Why can a recovery provider work on a development network and fail on Mainnet?

Sui enables identity providers separately for its different networks. Successful testing in a development environment does not establish Mainnet compatibility. A recovery setup needs provider support on the network holding the assets, together with an application capable of using that provider and the configured signer.

What numerical value must a zkLogin salt backup preserve?

A salt backup must preserve the exact original integer value, which must fit within 128 bits. Its displayed encoding is useful only if the wallet can reconstruct that same value. An account label, email address, or derived wallet address does not substitute for the salt.

Is a recovery phrase available for a standalone zkLogin address?

A standalone zkLogin address does not have an inherent recovery phrase encoding a permanent signing key. A wallet may provide a separate phrase-based account or a conventional multisig signer. That phrase restores the corresponding key; its authority over assets depends on the address and signing arrangement.

How does a prover outage affect recovery when the salt remains intact?

A prover outage can prevent fresh authentication proofs without destroying the salt or changing the account’s address. A valid cached session may remain usable if the wallet retains the necessary key and proof inputs. New sessions require a functioning compatible prover, even when salt recovery succeeds.

Sui zkLogin uses account sign-in to authorize transactions and needs the original salt for fresh proofs

Sui zkLogin lets an account with a supported sign-in provider authorize Sui transactions using zero-knowledge proofs and a short-lived signing key. The original user salt is also necessary to create fresh proofs for the same address. If that salt is lost beyond recovery, another successful sign-in cannot restore the address’s spending authority through zkLogin.

Last updated - October 8, 2026

Wallets differ in how they keep the salt, recover access, and protect session material. Those choices determine whether losing a device allows straightforward restoration or leaves the original address inaccessible after its existing session expires.

An independent multisig signer offers recovery only when the configured threshold permits authorization without the unavailable zkLogin signer.

Recovery control before committing assets

A zkLogin wallet fits account-based access when its salt remains recoverable and the chosen identity provider continues to support the application’s registered sign-in client. The recovery arrangements deserve attention before assets enter the account. Application-managed salts reduce the need to retain a separate secret personally. User-held salts place that responsibility directly with their holder. A multisig arrangement can add another authorization route. These choices affect who must preserve recovery material and which service failures the account can survive.

Protocol support for a recovery method does not establish that a particular wallet has configured it.

Salt persistence and recovery responsibilities

Salt management must preserve the exact value associated with the original address, whether a device stores it or a backend reproduces it. An unrecoverable original salt prevents generation of fresh zkLogin proofs for that address. A temporarily unreachable service does not establish that its salt data has disappeared.

Salt returned by a backend

Stored user mappings

A database-backed service keeps the association between an identity and its salt. Its recovery plan must preserve those records and the ability to retrieve them for the correct account. Restoring an empty database and issuing new salts creates new address inputs.

Deterministic salt derivation

A deterministic service regenerates salts from a protected master seed and identity-related inputs. It can avoid storing a separate record for every user. Losing the only usable seed removes that regeneration path. Replacing the seed or changing the derivation inputs produces different salts. Server recovery must retain the original seed and derivation configuration.

Salt retained by the user

A user-held salt can live in device storage or a recoverable personal backup. Clearing its only storage location removes the value needed for future proofs. Browser storage alone does not provide continuity across devices. A backup must remain usable by the wallet; an account name or remembered address does not contain the salt.

Address continuity across applications and derivation modes

Address derivation includes the identity provider, its user identifier, the application’s client ID, and the salt. The token names these identity fields iss, sub, and aud. Signing into a separate wallet application may change the client ID even when the person uses the same social account. Connecting an existing wallet to another Move application does not itself change these derivation inputs. The registered client identity matters more than an application’s displayed name.

Address derivation also has a legacy compatibility mode for earlier integrations. The SDK supports both address forms. A wallet must use the mode matching the existing address when restoring access. A mode mismatch can resemble a salt problem, so an unexpected address does not identify salt loss by itself.

Proof generation and transaction authorization

The application first generates an ephemeral key pair, then requests an OpenID Connect ID token carrying a nonce bound to its public key. The nonce also incorporates randomness and an expiry epoch. The ID token is a JSON Web Token (JWT) signed by the identity provider. A proving service uses it with the salt and session inputs to generate a zero-knowledge proof. The ephemeral private key signs the transaction, and Sui validators check the combined authorization. Move application permissions still govern the requested actions. Valid authentication alone does not establish successful transaction execution.

Session expiry and retained signing material

Proof caching lets an application reuse an existing proof across transactions without another proving request each time. A zkLogin session stops authorizing transactions when the current epoch exceeds its maxEpoch. Session expiry does not delete the address or its assets.

Reusing a proof with a different ephemeral signing key fails authentication.

Graphic: Sui zkLogin - Session expiry and retained signing material

View image file

A replacement ephemeral key requires a fresh login and a proof bound to that new key. Address continuity still requires the original derivation inputs. If a wallet retains the matching private key and complete cached proof inputs, an existing session may remain usable without retrieving the salt again. The cached proof cannot supply the missing salt for later sessions.

Privacy exposure and account compromise

Proving and salt services can learn the relationship between an identity and its wallet address when they handle the relevant token and salt. The proof keeps sensitive identity fields out of normal onchain authentication data. That protection does not prevent a backend from learning what the user supplies to it.

A salt service releasing its value solely after JWT authentication can also release it to someone controlling that account. The salt’s presence therefore does not automatically provide an independent security factor. Strong account authentication and any additional salt-service access controls affect this threat. A copied session private key and its complete valid proof inputs can authorize transactions during the remaining session.

An exposed salt can also let someone with the relevant identity fields reconstruct the associated address.

Gas payment and proof-service costs

Proof-service capacity depends on fresh session requests and how effectively the application reuses valid proofs. Generating a proof consumes computing resources, whether the application runs its own prover or uses a hosted service. Hosting arrangements determine any service charges. There is no universal price implied by the sign-in method. Repeatedly requesting proofs with incorrect address inputs adds work without restoring the intended account.

Onchain transactions also require gas payment. A supported sponsorship arrangement lets another party provide that payment, subject to its transaction approval and funding rules. Sponsorship changes the gas payer; it cannot replace the user’s missing authorization. Authentication recovery and the ability to fund an intended transaction remain separate requirements.

A salt mismatch before another proof request

Replacing the original salt produces a different address, so the mismatch should be resolved before requesting another proof. This hypothetical case assumes a recorded funded address, unchanged provider and user identifiers, the original application client ID, and the same derivation mode. A restored backend returns a replacement salt, and no usable session proof remains cached.

The wallet computes an address from the returned salt and compares it with the recorded address. They differ. Keeping the other inputs unchanged isolates the changed salt in this case. Generating a proof for the replacement value would bind the ephemeral public key to the newly derived address. That proof would not unlock the assets held at the original address.

The backend then restores the original salt from its preserved recovery material. Repeating the address calculation now matches the recorded address exactly, resolving the mismatch before another proving request. This avoids spending prover capacity on the wrong address. A fresh proof still needs a valid token and consistent session inputs. Any subsequent asset transfer requires gas payment and successful onchain execution.

Independent recovery signers and conventional key custody

A multisig recovery arrangement survives loss of the zkLogin route only when its remaining signers can meet the account’s configured authorization threshold. Sui supports combining zkLogin with conventional key-based signers. Merely listing another signer does not ensure recovery if the threshold still requires the unavailable signer. The arrangement must already govern the address holding the assets. A separately created wallet does not automatically gain authority over an existing standalone zkLogin address.

A conventional key-based wallet places recovery responsibility on preserving its signing key, commonly through a recovery phrase or protected key backup. It reduces dependence on a social account while introducing persistent key management. A zkLogin-based multisig can distribute that dependence across different signers, with the threshold defining their powers. The usable alternative depends on which recovery material remains available and what the existing account actually permits.

Illustration: Independent recovery signers and conventional key custody (Sui zkLogin)

View image file

Sui zkLogin: reader questions

Will changing my social account password alter my zkLogin address?: Changing a password does not itself change the inputs used to derive a zkLogin address. Continuity requires the same provider, user identifier, application client ID, salt, and derivation mode. Recovery into a different account can change the user identifier, even when its displayed name looks familiar.
Can blockchain records restore a missing zkLogin user salt?: Normal zkLogin transaction records do not provide a backup of the user salt. Recorded addresses and transaction digests cannot replace the original value. Recovery requires a retained salt or the original backend material capable of reproducing it; the proof does not publish that secret.
Does logging out invalidate a copied zkLogin session key and proof?: Logging out does not itself change a proof’s encoded expiry epoch. Someone retaining the matching private key and complete valid proof inputs may still authorize transactions within that session’s permitted lifetime. Deleting local session files removes those local copies, not copies held elsewhere.
Why can a recovery provider work on a development network and fail on Mainnet?: Sui enables identity providers separately for its different networks. Successful testing in a development environment does not establish Mainnet compatibility. A recovery setup needs provider support on the network holding the assets, together with an application capable of using that provider and the configured signer.
What numerical value must a zkLogin salt backup preserve?: A salt backup must preserve the exact original integer value, which must fit within 128 bits. Its displayed encoding is useful only if the wallet can reconstruct that same value. An account label, email address, or derived wallet address does not substitute for the salt.
Is a recovery phrase available for a standalone zkLogin address?: A standalone zkLogin address does not have an inherent recovery phrase encoding a permanent signing key. A wallet may provide a separate phrase-based account or a conventional multisig signer. That phrase restores the corresponding key; its authority over assets depends on the address and signing arrangement.
How does a prover outage affect recovery when the salt remains intact?: A prover outage can prevent fresh authentication proofs without destroying the salt or changing the account’s address. A valid cached session may remain usable if the wallet retains the necessary key and proof inputs. New sessions require a functioning compatible prover, even when salt recovery succeeds.