zkLogin: A Casino Wallet Without a Seed Phrase
Seed phrases are where new players quit and funds get lost. Sui zkLogin kills the seed phrase without giving up self-custody — you sign in with Google and get a real Sui wallet, derived by cryptography rather than held by a casino. Here is exactly how that works, what is stored where, and what you should understand about the security model before you put real SUI behind it.
Sign in and play →The seed phrase problem
Traditional crypto onboarding hands you twelve random words and says: lose these and your money is gone forever, leak these and someone steals it. For gambling — where people want to deposit and play in minutes — that is a massive drop-off point. Custodial casinos 'solve' it by holding your keys, which reintroduces exactly the trust problem crypto was meant to remove: an account balance is just a promise, and the operator can freeze it, lose it or run with it. zkLogin threads the needle. There is no seed phrase to write down, and no custodian either — your Google login becomes the credential that authorises on-chain transactions from an address only you control. It is the single biggest onboarding unlock crypto gambling has had, which is why Llamabet made it the default way in.
The full flow, step by step
Per the Sui documentation, a zkLogin session is built in six moves. First, your browser generates an ephemeral keypair — a temporary signing key valid only until a set Sui epoch. Second, a nonce is derived from that ephemeral public key, the expiry epoch and some randomness. Third, you sign in with Google through standard OAuth, and the nonce rides along; Google returns a signed JWT that embeds it, cryptographically binding your login to your temporary key. Fourth, a per-user salt is fetched — a secret number that keeps your Google identity unlinkable to your address. Fifth, a zero-knowledge proof is generated attesting that you hold a valid Google-signed JWT matching that nonce, without revealing the JWT itself. Sixth, your Sui address is deterministically derived from the JWT issuer, audience and subject plus the salt. From then on, the ephemeral key signs your bets and the proof convinces the chain they are really yours.
What is stored where
Understanding storage is understanding the model. Your browser session holds the working artifacts: the ephemeral keypair, the JWT from Google, and the ZK proof — on Llamabet these live in browser storage under llamabet_-prefixed keys and expire with the session. Your salt is stored server-side, keyed to your account, so that clearing your browser or switching devices does not change the address you derive — the same Google login plus the same salt always reproduces the same wallet. What is never stored anywhere, by anyone, is a master private key. There is no seed phrase in a database, no key file on the casino's servers, nothing for an attacker to exfiltrate that would let them spend your funds. The ephemeral key alone is useless without a fresh proof tied to your live Google authentication.
Self-custody, explained honestly
Is zkLogin really self-custody? Yes, with one honest footnote. Self-custody means the operator cannot move your funds — and it cannot: Llamabet never possesses anything that can sign a transaction from your address. Winnings settle to an address only your Google authentication can unlock, as real on-chain transfers rather than IOUs the house releases later. The footnote is the salt: because your address is derived from your login plus the salt, you need both to reconstruct the wallet. Llamabet persists the salt server-side precisely so it survives cleared caches and new devices, and the salt on its own is worthless to anyone else — it cannot sign anything. But it is fair to say zkLogin is self-custody with a derivation dependency, not the pure sovereignty of a hardware wallet. For the sums most players keep at a casino, that trade is overwhelmingly worth it.
Security model and recovery
zkLogin ties wallet access to your OAuth account, so your Google account is now also the key to your casino funds — treat it that way. Use a strong unique password, turn on two-factor authentication, and prefer a hardware security key or authenticator app over SMS codes. The upside of this model is recovery: forget a seed phrase and the money is gone forever, but a Google account has mature recovery flows — backup codes, recovery email, trusted devices — that billions of people already navigate. You inherit the security engineering of a company that defends logins for a living instead of trusting a piece of paper in a drawer. The flip side is equally real: if an attacker fully takes over your Google account, they can authenticate as you. Account hygiene is not optional advice here; it is the whole perimeter.
zkLogin vs extension wallets — and when to graduate
A browser-extension wallet like Slush gives you a classic seed-phrase wallet: maximum sovereignty, no dependency on any OAuth provider, and full portability across every Sui app. The cost is the onboarding cliff and the responsibility of key management. zkLogin flips the trade: zero setup, zero seed phrase, and security anchored to an account you already protect daily. A sensible pattern is to start with zkLogin — you can be playing a provably-fair hand within a minute of landing on the site — and graduate as your balances grow. Keep a playing balance in the zkLogin wallet, and sweep meaningful winnings to a hardware-backed or extension wallet you control end to end. Llamabet supports both paths natively, so nothing about your history or fairness proofs changes when you connect a traditional wallet instead.
Sessions, expiry and logging back in
The ephemeral key is deliberately short-lived: it is valid only up to the maximum epoch chosen when it was created, and the proof dies with it. When the session expires — or you clear storage or switch devices — you simply sign in with Google again: a new ephemeral key, nonce and proof are minted, the stored salt is fetched, and the exact same address is re-derived. Your funds never move and never depend on the old session artifacts; expiry is a security feature, not a risk to your balance. It means a stolen laptop or a leaked session token has a bounded shelf life, after which the attacker holds nothing but expired bytes. Day to day it feels like any web login: occasionally Google asks you to re-authenticate, and then you are back at the tables.
Frequently asked questions
Is a zkLogin wallet really self-custodial?
Yes. Only you can authorise transactions, via your Google authentication, a temporary ephemeral key and a zero-knowledge proof; Llamabet never holds a key that can spend your funds. The one dependency is the account salt used to derive your address, which is stored server-side so your wallet survives cleared browsers — but the salt alone cannot sign or move anything.
Does zkLogin expose my Google identity on-chain?
No. The zero-knowledge proof lets the chain verify you authenticated with Google without revealing the JWT, and the per-user salt breaks the public link between your email and your Sui address. On-chain observers see a normal address, not an identity.
What happens if I lose access to my Google account?
Your Google login is the access credential, so recovering it through Google's standard recovery flows (backup codes, recovery email, 2FA devices) restores wallet access — the same address is re-derived from your login plus your stored salt. Protect the account accordingly: strong unique password, two-factor authentication, and ideally a hardware security key.