Sui zkLogin turns a Google sign-in into a real on-chain address, and sponsored transactions remove the need to hold SUI for gas. How the mechanism works, what the zero-knowledge proof hides, what it does not solve, and what is live on Predict Bay today.
Predict Bay ·
Signing in with Google on Predict Bay produces a real Sui address, and there is no seed phrase anywhere in that flow. That is zkLogin, a signature scheme built into Sui itself: your address is derived from your Google account plus a private salt, and every transaction you send carries a zero-knowledge proof that you hold a valid Google credential for that address. The proof, together with that salt, is what makes it work in both directions — the chain verifies you without learning your Google identity, and Google sees an ordinary OAuth login without learning which Sui address it unlocked.
ROUND CLOSES IN
--:--
LAST PRICE
—
STRIKE
—
NO POSITIONS YET THIS ROUND — BE THE FIRST
Practice mode · no wallet, no deposit, free to start
The other half of the friction is gas. A brand-new address holds no SUI, so a wallet that works perfectly still cannot send its first transaction. Sui supports sponsored transactions natively — the account that pays for gas can be different from the account that sends the transaction — and Predict Bay's Sui integration is built on that, so a first on-chain trade does not require acquiring SUI first. This post covers the mechanism, what the proof actually hides, what trust assumptions remain, what is and is not live on Predict Bay today, and where it all sits in our DeepBook Predict integration.
Prediction markets ask something unusual of a new user. The interesting participants are people with a strong view on a specific question — whether BTC closes above a level in the next hour, where ETH lands by the end of the day. That view has a shelf life measured in hours, sometimes minutes, and any onboarding step that outlasts the conviction destroys the trade.
Count the steps a conventional on-chain market asks for before the first position: install a browser extension, generate a wallet, write twelve words onto paper, confirm them, acquire the chain's gas token from somewhere, bridge or buy the settlement stablecoin, approve a spending allowance, then sign. Each of those is a place to abandon, and several of them are irreversible mistakes rather than mere delays. A seed phrase written down badly is a loss that surfaces months later.
None of that is a question about the market itself. It is an account-creation problem that happens to be denominated in cryptography. zkLogin attacks it at the protocol layer rather than papering over it with a custodial account — the address is a genuine Sui address, on-chain, and transactions from it are signed on your device rather than by Predict Bay on your behalf.
A zkLogin address is not stored somewhere and handed to you. It is derived, deterministically, from four inputs. Given the same four, the same address comes back every time; change any one and you get a different, unrelated address. Two further session-scoped artifacts carry it on-chain.
The sequence below runs once per session. Everything before the last step happens in your browser or against Enoki, Mysten Labs' zkLogin service, which Predict Bay uses for nonce generation, salt custody and proving; nothing in it requires you to hold a long-lived private key.
Generate an ephemeral keypair
The browser creates a fresh Ed25519 keypair. This is the key that will actually sign transactions, and it is deliberately short-lived — Predict Bay keeps it in sessionStorage, not localStorage, so it does not outlive the tab.
Commit to it in a nonce
The ephemeral public key, a maximum Sui epoch and a random value are hashed into a single nonce — Predict Bay obtains it by sending the ephemeral public key to Enoki, which returns the nonce along with the randomness and the epoch bound it committed to. That nonce is the commitment: it binds the OAuth login you are about to perform to this specific key and this specific expiry.
Do a normal OAuth round trip
The nonce is passed to Google as the standard OpenID Connect nonce parameter. You see the ordinary Google consent screen. Google returns a signed JWT (id_token) containing iss, aud, sub and — echoed back verbatim — your nonce.
Derive the address
An address seed is computed from sub, aud and the user salt; the address itself is a hash over that seed and the issuer. This is pure computation over values that already exist. No transaction is needed, and an address that has never transacted costs nothing to hold.
Prove it in zero knowledge
A proving service takes the JWT and the salt and emits a Groth16 proof asserting: this JWT was signed by the named provider, its claims derive to this address, and its nonce commits to this ephemeral public key. The JWT itself is never published on-chain.
Sign and submit
Each transaction is signed by the ephemeral key. The proof is attached alongside. Sui validators verify the proof against the provider's public keys, which the network maintains on-chain and refreshes through consensus, then check the ephemeral signature and the epoch bound.
The privacy property is easy to state imprecisely. Two parties see two different halves of the picture, and neither sees enough to join them.
Google sees an OAuth login. It sees that you authenticated to a particular client ID and it sees the nonce it was handed. The nonce is a hash commitment over an ephemeral public key — it is not your Sui address, it is not derivable into your Sui address, and it is different on every login. Google cannot look at your account and enumerate the transactions it authorised.
The chain sees an address and a proof. Validators verify that some valid credential from the named provider derives to the address that sent the transaction. They learn which provider was used, but not sub, not your email, and they cannot run the derivation backwards, because the salt is missing. On-chain, a zkLogin address looks like any other Sui address.
The salt is the hinge. It is the input that stops anyone who knows your Google account from computing your address, and it is the input that stops anyone holding your address from computing your Google account. Without it, sub and aud are guessable enough that the mapping would be computable in both directions.
Since the salt determines the address, whoever can produce your salt alongside a fresh Google credential can produce your address — and a proof for it. That is the real custody question in any zkLogin deployment, and it deserves a straight answer rather than a diagram.
Predict Bay uses Enoki, Mysten Labs' zkLogin infrastructure, as the salt service. The salt is held there and resolved server-side; Predict Bay's own sponsor route re-derives the address by calling Enoki with the user's verified id_token rather than trusting an address the browser claims, and rejects the request if the sender field does not match the address that derivation returns. That detail matters more than it sounds: the route verifies the JWT signature against Google's published JWKS before it does anything else, so a client cannot hand it a forged payload carrying someone else's subject and have it sponsor a transaction.
The honest framing is that zkLogin moves the recovery problem rather than deleting it. A seed phrase makes you the single point of failure; zkLogin makes your OAuth account plus a salt service the point of failure. For many people that is a trade worth taking knowingly, because account recovery with an OAuth provider is a supported, familiar process and recovering lost twelve words is not. If you would rather not make that trade, Predict Bay also supports connecting a Sui wallet directly, and the same markets are available either way.
An address with a perfect signature scheme and no gas token cannot transact. This is the second wall, and on most chains the answer is "go buy the native token first" — which means an exchange account, a verification queue and a withdrawal, all before a trade whose thesis expires this afternoon.
Sui's transaction format separates the sender from the gas payer. A sponsored transaction is paid for with gas objects owned by a sponsor, and it carries two signatures: the sender's and the sponsor's, over the same complete transaction data. Because both parties sign the same bytes, the sponsor cannot alter what you agreed to and you cannot redirect the sponsor's gas to a different transaction. You remain the sender and the effects are attributed to your address.
Build the transaction kind
The client builds the Move calls only — the transaction body with no gas data attached, serialised as kind bytes.
Ask for sponsorship
Those bytes go to a Predict Bay server route, which verifies your Google credential against Google's JWKS, resolves your address through Enoki, and forwards the request. The sponsor's private key stays server-side and never reaches the browser.
Get back a complete transaction
The sponsor attaches its own gas coins and returns full transaction bytes plus a sponsorship digest.
Sign as yourself
The ephemeral key signs those bytes and the zkLogin proof is attached, producing a valid zkLogin signature over exactly the transaction the sponsor assembled.
Execute
The signature and digest go back to a second Predict Bay route, which submits them for execution. Gas is paid by the sponsor; the position is minted to you.
A sponsor key that will pay for any transaction anyone hands it is a faucet for attackers. Predict Bay's sponsor route decodes the submitted kind bytes and checks every MoveCall target against an allowlist generated from the same module that builds the transactions — so the allowlist cannot drift from what the client actually sends — and rejects anything outside it, including bytes it cannot decode at all. The same allowlist is passed to Enoki, so the constraint is enforced twice. Requests are rate-limited per verified user, cross-origin posts are refused, and the sender address is derived server-side from the verified JWT rather than accepted from the request body. Sponsorship pays for the protocol calls the app makes and nothing else.
| Stage | Browser-extension wallet | zkLogin on Predict Bay |
|---|---|---|
| Account creation | Install extension, generate wallet, record and confirm a recovery phrase | Google sign-in; address derived from the credential |
| Secret you must store | 12 or 24 words, permanently, offline | None. An ephemeral key lives in the tab and expires by epoch |
| Gas for the first transaction | Acquire the native token before anything can be sent | Sponsored for the allowlisted protocol calls — no SUI needed |
| What the identity provider learns | Nothing (there is none) | That you logged in, plus an opaque nonce. Not your address |
| What the chain learns | A public key | An address, the provider name, and a proof. Not your account |
| Recovery path | The phrase, or nothing | Your OAuth account plus the salt service |
| Signing | Extension popup per transaction | Ephemeral key signs; re-authentication when the epoch bound lapses |
Four limits worth stating plainly, because a page that only lists advantages is not describing a real system.
maxEpoch committed in the nonce. Sui epochs run roughly a day, and Predict Bay's production configuration requests two beyond the current one, so a long-idle session eventually needs a fresh Google round trip. This is a feature — an unbounded session key would be a permanent bearer credential sitting in a browser — but it is a real interruption.The live markets are short-duration price markets on BTC, ETH, SOL, SUI, DOGE and XRP, on hourly and daily rounds. A strike is set at the open, you pick whether the asset finishes above or below it, and the round resolves against an on-chain price feed. Every market page carries a mode switch; with EVM paused it renders two options, Practice and Sui.
Practice mode mirrors the real markets exactly — same assets, same rounds, same strikes, same resolution source — which makes it a rehearsal rather than a toy, and it is what you can trade today. Combined with a Google sign-in, the distance between reading about a market and having a practice position in one is a single click and a strike direction. Start on the BTC market or the SUI market.
For the layer underneath — the on-chain binary options protocol, its tick-encoded strikes and its oracle inputs — see the Sui prediction market stack. How it works covers the trading mechanics end to end, and the FAQ answers the shorter questions. The account layer described here is deliberately the least interesting part of using Predict Bay, which is the point: the best onboarding is the kind you finish without noticing you were onboarded.