Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
SUI How Sui Network zkLogin works
Sui Network's zkLogin feature allows users to access Sui addresses through familiar OAuth login methods (such as Google accounts) without generating mnemonic words. According to official documentation, the address is derived from four input parameters: user identifier (sub), identity provider (iss), application client ID (aud), and per-user unique salt value (salt). As long as the same four values are provided, the generated addresses are always consistent.
The core of this mechanism is the Groth16 zero-knowledge proof, which ensures security and does not expose any credentials to the chain. The Sui document explains: "The attestation service receives the JWT, temporary public key, salt value per user, and maximum validity period, and generates a zero-knowledge attestation." The purpose of this certificate is to confirm that the user has a valid OAuth certificate for the address without requiring the JWT to be disclosed online. The reason for choosing Groth16 is that, as noted in the related research paper, it provides mature tool support and a compact proof size.
Sessions are time-sensitive by design. Each login generates a temporary key pair that is valid for a short period of time. When the session expires, the user simply logs in again to generate a new key pair and certificate, while the underlying Sui address remains unchanged.
Trade-off of salt values
The per-user-specific salt value is a key variable that distinguishes OAuth identity from on-chain addresses. It provides a layer of privacy protection, making it impossible for anyone to reverse associate a Sui address to a Google account simply by checking on-chain data. However, salt values also introduce important custody decisions: It must be stored in places beyond the control of the OAuth provider.
The Sui document describes the wallet as "essentially a 2-of-2 multi-signature wallet, where two certificates are your OAuth certificate and salt value." This statement clearly reveals where the risks lie. Lost Google accounts can be recovered through Google's own account recovery process; however, lost salt values are not. If the salt value is lost, the address will be permanently inaccessible regardless of whether the Google account is intact.
As a result, developers developing based on zkLogin face real design decisions: how and where to store salt values need to be balanced against the risk of permanent loss of convenience. Options include dedicated salt services or autonomous management storage, each with its own security assumptions.
For users who are new to on-chain applications, zkLogin eliminates the most common friction point: mnemonics. But instead of eliminating it, it shifts the responsibility of custody, replacing one key secret with another.
