Privacy-Preserving Account Recovery with Zero-Knowledge Proofs

ZKsync SSO (Smart Sign-On) is Matter Labs' modular smart account implementation for ZKsync. At the time it offered ERC-7579 modular accounts, passkey authentication with no seed phrases, configurable sessions, paymaster support, a TypeScript SDK, and an open-source auth server.

Passkeys solved onboarding, but users still needed a way back in after losing a device. We had already shipped social recovery with guardians, which works well but needs several people to coordinate. Mainstream users expect Web2-style recovery: sign in with Google and regain access.

Google sign-in had to work as a recovery method without weakening the security and privacy properties that make smart accounts valuable:

• Privacy without custody: Google shouldn't be able to link an on-chain address to a user's identity, or use its signing authority to take over accounts and drain funds.
• On-chain verification limits: Verifying a zero-knowledge proof costs a lot of gas, and account abstraction restricts what a transaction's validation step can do.
• Provider key rotation: Google rotates its signing keys several times a month. The contracts had to track the current keys securely, without a manual update step.
• Security first: Recovery is the most sensitive flow in a wallet: whoever controls it controls the account. Every step had to hold up against replayed tokens and front-run transactions.
• Familiar UX: All of this had to stay invisible. To the user, recovery should feel like a normal Google sign-in.

We started with research: the recovery designs available on the market, weighed against the SSO architecture. We scoped and estimated the candidate solutions and walked Matter Labs through the trade-offs before committing to one.

The core insight was to use OAuth's nonce parameter as a commitment. The nonce accepts arbitrary data, and Google returns it signed inside the ID token (a JWT). Put a hash of the recovery transaction there, and Google's signature ties that token to one specific recovery. Salting and blinding keep the link private. The design builds on Sui's zkLogin.

The architecture is extensible. The implementation targets Google, but the circuit works on standard JWT structures, so any OIDC-compliant provider could plug in with minor contract changes for its key format and rotation schedule.

Two components carry the design:

• OidcRecoveryValidator: a new validator module that stores each SSO account's recovery data and validates the transactions that use it.
• The recovery circuit: a Circom circuit, proven with Groth16, that shows the user holds a Google-signed JWT for the registered account and that the JWT commits to this exact recovery, without revealing which account it is.

Setup

To the user, setup is the familiar Sign in with Google pop-up. Behind it, the account registers a digest with OidcRecoveryValidator: a hash of the user's Google ID, the app's client ID, the issuer, and a salt. The digest pins one Google account without revealing which.

Recovery

The user creates a new passkey and signs in with Google. The nonce sent to Google commits to the account, the new passkey, the wallet submitting the transaction, a per-account counter, and a deadline, all blinded with a random factor. Google signs it without learning anything about the account.

The browser then generates a zero-knowledge proof that the JWT is valid, matches the registered digest, and carries that nonce. Proof generation runs entirely in the browser, in about 30 seconds on consumer hardware, with no proving service involved.

Because proof verification is gas-heavy, recovery takes 2 transactions. The first verifies the proof and marks the account ready to recover. The second registers the new passkey, and the validator only allows it for the passkey committed in the proof, within 10 minutes.

Key rotation and account management

• Key rotation: OidcKeyRegistry keeps Google's recent signing keys on-chain (the last 8 per provider), and a monitoring system updates it as Google rotates them, so proofs verify against current keys without manual updates.
• Account management: Users can view their linked Google account in the SSO settings dashboard and remove it with passkey authentication.

The engagement delivered OIDC account recovery for ZKsync SSO: Web2-style recovery that keeps the self-custody and privacy properties separating smart accounts from custodial solutions.

OpenZeppelin audited the Circom circuit and the Solidity contracts independently, covering the cryptographic implementation, the contract logic, and how the two interact. Neither audit found a critical or high-severity issue in the recovery code, and every medium-severity finding was resolved. Few ZK circuits get an independent audit; this one did, alongside the contracts that verify it.

• Circuit audit: OpenZeppelin, March to April 2025. 9 findings, none critical or high, all resolved.
• Contract audit: OpenZeppelin, April 2025. No critical or high-severity issues in the recovery contracts, and all 3 medium-severity issues resolved. The report's one high was in an account signature handler, not the recovery modules.
• Circuit source: the Circom circuit and browser proving tools, on GitHub.
• zkLogin: the Sui research this design builds on (Baldimtsi et al., 2024).

The broader lesson: an on-chain verifier can confirm a fact about off-chain data, here a token signed by Google, without that data ever reaching the chain.