Bottom-up through the layers an on-chain prediction market actually runs on — the object model, parallel execution, the order book, the options protocol, the oracle and the login — and the mechanism-level case for why they fit.
Predict Bay ·
A prediction market needs four things it must not itself control: somewhere to hold positions nobody can quietly rewrite, a venue where entering and exiting is not itself the trade, a settlement price the venue does not choose, and an account a person can obtain without becoming a key-management expert. Sui supplies those as four separable layers — Move's object model, DeepBook's native central limit order book, Pyth's price feeds, and zkLogin — and DeepBook Predict is the binary-options protocol assembled on top of them. Predict Bay is an interface over that stack rather than a re-implementation of any part of it.
ROUND CLOSES IN
--:--
LAST PRICE
—
STRIKE
—
NO POSITIONS YET THIS ROUND — BE THE FIRST
Practice mode · no wallet, no deposit, free to start
This post walks the stack bottom-up: how Move represents a position, why parallel execution changes what an on-chain order book costs to run, what DeepBook contributes as shared infrastructure, what the Predict layer adds, how Pyth turns an expiry into a number, and how zkLogin removes the seed phrase from the path. The argument is mechanical throughout — each layer removes a specific failure mode that prediction markets on other stacks have to engineer around. Where a layer removes less than the marketing for it suggests, this post says so; that is the more useful half of the document.
Read the third column first. It is the only one that justifies the other two.
| Layer | What it is | What it removes |
|---|---|---|
| Move + object model | Positions and coins are typed objects with owners, not rows in a contract-owned mapping | A single contract-owned ledger that every holder's balance lives inside |
| Sui execution | Transactions touching disjoint objects run in parallel; owned-object transactions skip consensus ordering | Unrelated chain activity pricing a maker out of a cancel |
| DeepBook | Sui's native on-chain CLOB — resting limit orders, price-time priority, pools as shared objects | Every venue bootstrapping its own private book |
| DeepBook Predict | Binary and range options defined by an expiry and a strike expressed as a price tick | Payout logic living inside an off-chain risk engine |
| Pyth | Signed price updates posted on-chain on demand, carrying a confidence interval and a publish time | The venue being the source of its own settlement price |
| zkLogin | A native Sui address derived from an OAuth identity plus a salt, authorised by a zero-knowledge proof | A seed phrase standing between a new user and a first trade |
| Predict Bay | Interface: builds the transaction, submits it, reads positions back from chain, renders odds | Nothing. It is deliberately the thinnest layer here |
Sui does not keep a global key-value map that contracts index by user address. State is a set of objects, each with a unique ID, a version and an owner — an address, another object, shared, or immutable. A Move struct becomes an object by carrying the key ability, and Move's type system is linear: a value with neither copy nor drop cannot be duplicated and cannot be silently discarded. It has to be consumed, stored inside another object, or transferred. Asset conservation is enforced by the type checker rather than by a convention every function has to remember to follow.
For a prediction market the consequence is concrete. Your position is an object you own, carrying its own market, strike and expiry, sitting at an address in your account. It is not a number in a mapping(address => uint256) inside a contract that also holds everybody else's. Nothing can move or dilute it without a transaction you sign, and redemption is a function that consumes your object rather than a request to debit a ledger somebody else maintains.
Be precise about what that buys and what it does not, because this is where writing about Sui usually overreaches. It is custody, not immunity from protocol rules. Ownership means no contract can reassign your position, and it means a protocol does not automatically hold a list of everyone exposed to an instrument — there is no such list unless the authors deliberately build one. It does not mean a protocol has no administrative controls: a redemption still touches shared protocol state, and if that state carries a pause capability, owning your position object does not override it. What the object model removes is the failure class where a balance you thought you held turns out to be an entry in a table someone else can rewrite. What you still have to read is the Move source.
The owner field decides how a transaction gets ordered. A transaction touching only objects owned by the sender has a single writer by construction, so there is no ordering question to resolve and Sui can execute it on a fast path without full consensus sequencing. A transaction touching a shared object — an order book pool, a market — needs consensus to agree the order of writers. Protocol authors therefore choose shared state deliberately: what must be shared is shared, and what does not need to be (your position, your coins) stays owned. That distinction is not an implementation detail on Sui; it is the main design lever you have.
Sui's scheduler reads each transaction's object inputs up front and executes transactions with disjoint input sets concurrently. Contention is scoped to objects, not to the chain as a whole. An order book is a contention point by construction — every order touches the book — but that is the only thing it contends with. Two effects follow, and both matter more for prediction markets than for spot trading.
The first is cross-market isolation. Prediction market flow is bursty and clock-aligned: hourly rounds mean everyone acts in the last seconds before an expiry, then again in the first seconds of the next round. When the BTC hourly market and the SUI daily market are separate objects, the BTC expiry crush does not sit in front of an unrelated SUI order. On a runtime with a single global execution lane it does — and so does an unrelated mint elsewhere on the chain that has nothing to do with either.
The second is the price of cancelling. A maker quoting a two-sided spread around a probability re-quotes constantly, and every re-quote is a cancel plus a place. If cancels are priced by a per-block auction that unrelated demand can win, the maker's inventory risk silently includes the risk of not being able to afford to get out of the way when the feed moves. On Sui the cost of a transaction is dominated by a reference gas price set per epoch — validators survey and publish a price rather than users bidding each other up for the next block — which turns staying at the top of the book into a largely budgeted cost rather than a variable one.
State the caveat, because it is the honest version of the argument: Sui applies congestion control per object, so a single sustained-hot shared object can have transactions deferred to a later commit rather than executed immediately. That is a queue, not an auction, and it is bounded by traffic on that one object — which for a maker is the book they are already quoting on, not the rest of the chain. Predictable cancels are what a quoted book is made of; DeepBook, CLOB liquidity and prediction markets works through the liquidity side in detail.
DeepBook is a central limit order book implemented in Move and deployed as a package on Sui: limit and market orders, price-time priority, tick and lot sizes, orders resting in a pool that is itself a shared object. It matters less as an application than as infrastructure. Anything on Sui that needs a book can route into the same pools instead of bootstrapping private liquidity and hoping market makers turn up a second time for a second venue.
For binary instruments a book is the right shape and an automated market maker is the wrong one. A binary contract's price is a probability bounded in [0, 1] that converges to exactly 0 or 1 at expiry. A constant-function curve spreads inventory across a price range the instrument will never revisit, and it cannot express the view a prediction-market maker actually holds — not "more or less of this asset" but "this outcome is worth 38 cents, I will show 36 at 40 and pull the quote if the feed gaps". Price-time priority also gives an informed taker a clean way to act on information, which is the mechanism by which a market price moves toward the truth instead of leaking to whoever arbitrages a stale curve.
Because the pools are shared objects rather than a venue's private database, a second interface quoting the same instrument adds depth to the same book instead of fragmenting it into a competing one. That is what makes "shared liquidity infrastructure" a mechanical statement here rather than a marketing one: the book is addressable state on a public chain, and no interface owns it. Whether depth actually shows up is a separate question that no amount of architecture answers — an open book with nobody quoting is still an empty book.
DeepBook Predict is the options protocol on that stack. Instead of exchanging one asset for another, you mint a position that resolves to a fixed payout depending on where an underlying price lands at a stated expiry. A position is defined by an expiry and a strike expressed as a price tick. Sentinel tick values express one-sided contracts — above X, below X — while a bounded pair of ticks expresses a range contract. One representation covers both "BTC above the strike at 15:00" and "BTC between two strikes at 15:00", which is why the same mint path serves a simple up/down market and a range market without a second instrument type.
A binary is not priced by opinion; it is priced off the same surface that prices vanillas. The value of a digital paying one unit above strike K is the negative derivative of the vanilla call price with respect to K, which — undiscounted — is the risk-neutral probability of finishing above K. Two things fall out of that identity. First, a quote is a function of the forward, the time to expiry and the implied volatility at that strike, so any protocol quoting binaries continuously needs all three available on-chain.
Second, and less often stated: because implied volatility itself varies with strike, differentiating the call price with respect to K picks up a skew term. A digital is not simply the textbook probability factor computed off one volatility number — it is that factor adjusted by the slope of the smile at K. A protocol that stored a single at-the-money volatility per expiry would misprice precisely the out-of-the-money contracts prediction-market users are most drawn to, and it would misprice them asymmetrically between the up side and the down side. That is why the Predict layer reads a forward curve and a volatility surface rather than a spot price alone: spot cannot tell you what a one-hour, two-percent-out-of-the-money contract is worth.
On the deployment Predict Bay integrates against, the trading fee is charged per unit of position rather than as a percentage of notional, and the per-unit rate scales with the square root of p(1-p), subject to a floor. In absolute terms that is largest near even odds — where a contract carries the most variance — and it bottoms out at the floor as a contract approaches certainty.
The consequence is worth spelling out, because it is the opposite of how a percentage fee behaves. Since the premium per unit is roughly p, the fee as a fraction of what you actually stake is roughly the square root of (1-p)/p in the region where the variance term binds, and roughly floor/p once the floor takes over. Both diverge as p goes to zero: long-shot contracts cost proportionally far more to trade than coin-flips. Sizing therefore has to be fee-aware — the quantity a given stake buys is governed by 1/(p + fee_rate), not 1/p — and that is a real cost of carrying deep out-of-the-money exposure. Here it is a parameter you can read off the market object on-chain rather than something buried in a spread quoted at you.
Round opens
The market's reference price for the round is fixed on-chain and snapped to the tick grid. Until that baseline exists there is no strike to mint against, so a market can legitimately be open and not yet mintable.
Side selected
You choose above or below the strike, or a bounded range. Either way the choice is expressed as the tick bounds of the position you are about to mint.
Mint
The transaction pays premium plus fee in the settlement asset and produces a position object owned by your account. Size is constrained on-chain by a lot size and a minimum net premium, so dust positions are rejected by the contract rather than by the interface.
Hold
The position is an on-chain object in your account until expiry. Nothing about it depends on the interface that minted it staying online.
Expiry
The protocol settles against its on-chain oracle price for that expiry. No party to the trade supplies the settlement value.
Redeem
A redemption transaction consumes the position object and returns the payout — the full fixed amount if it settled in range, nothing if it did not.
Pyth is a pull oracle. Publishers — exchanges and trading firms — sign price updates off-chain; those are aggregated into a feed carrying an aggregate price, a confidence interval and a publish timestamp; and a consumer that needs the price posts the latest signed update on-chain as part of its own transaction, then reads the freshly updated feed. The chain pays for freshness only when someone actually needs it, which is how a feed can update far faster than it could if every tick had to be pushed on-chain and paid for by the oracle.
Two properties of that payload matter for settlement. The confidence interval travels with the price, so a contract can decline to settle on a number it does not trust instead of settling on a figure with no error bar attached. And the publish timestamp lets a contract enforce a staleness bound — a settlement that reads a feed can assert the feed is recent enough for the expiry it is settling, rather than silently using whatever was last written. Both are checks the consuming contract has to actually perform; the feed makes them possible, it does not make them automatic.
The result is that resolution becomes an assertion about a public artifact. "Was the BTC/USD feed above the strike at 15:00" has an answer anyone can reproduce from data the venue did not produce and cannot revise. That is a categorically different dispute surface from a market on an event whose truth requires human judgement, which is why those markets need committees, dispute windows and bonded challengers instead. It narrows the trust question rather than deleting it: you are now trusting the publisher set and the aggregation, which is a smaller and much more legible thing to check. Oracle resolution and on-chain settlement compares the two models properly.
zkLogin decides who gets to be a user, which for a prediction market is as much a design decision as the matching engine. It lets an OAuth identity — a Google sign-in, in Predict Bay's case — authorise a native Sui address, with no seed phrase and without publishing the identity on-chain.
The mechanism, briefly. The client generates an ephemeral keypair valid only up to a stated epoch. It begins the OAuth flow with a nonce that commits to that ephemeral public key, the maximum epoch and some randomness. The provider returns a signed JWT containing that nonce. The client then produces a zero-knowledge proof that it holds a valid, provider-signed JWT whose nonce commits to this ephemeral key — without revealing the JWT itself. The Sui address is derived from the identity claim together with a user salt that the provider does not hold, so the OAuth provider alone cannot compute the on-chain address or link it back to the identity it issued. Transactions are signed by the ephemeral key and carry the proof; validators verify both.
Three consequences are worth stating plainly, and one of them cuts against the pitch. The resulting address is an ordinary Sui address rather than a smart-contract wallet emulating one, so it owns objects and pays gas like any other account. And because the ephemeral key expires by epoch, a stolen session key has a bounded blast radius rather than an indefinite one.
The third: the salt is not a second factor that you hold. In a managed deployment — which is what Predict Bay runs — the salt sits with a salt service that will return it on presentation of a valid, provider-signed JWT. So the accurate statement is that the salt stops the identity provider from linking your Google identity to your Sui address; it does not stop someone who has fully compromised your Google account from reaching your Sui account. Sign-in security reduces to your OAuth account security plus the salt service's. That is a genuine trade against a seed phrase — different failure modes, not strictly fewer — and anyone telling you otherwise is selling the convenience without the cost. Pair it with sponsored transactions, where a separate sponsor supplies and signs the gas payment for a transaction the user signs, and a brand-new account can place its first trade while holding zero SUI. Prediction markets without a seed phrase covers what you are trusting in exchange.
Predict Bay is the interface layer, and deliberately the thinnest thing in this document. In Sui mode the DeepBook Predict integration builds the mint transaction, submits it, and reads positions and balances back from the chain. It does not custody positions, does not operate a matching engine on that path, and does not decide outcomes. When that path is switched on, a position minted through it stays an on-chain object settling against the same oracle at the same expiry even if Predict Bay went dark. Today it is not switched on: the integration points at the protocol's Sui testnet deployment, and the Sui tab renders a coming-soon panel where the trading controls would be.
Every market page carries a mode switch. With EVM real-money trading paused, that switch renders two options: Practice and Sui. The markets themselves are short-duration price markets on BTC, ETH, SOL, SUI, DOGE and XRP, in hourly and daily rounds — a strike is set at the open, you pick whether the asset finishes above or below it, and the market resolves against an on-chain price feed. Practice mode mirrors those markets exactly: same assets, same rounds, same feed, no money at risk. The SUI market page is a reasonable place to start, and how it works walks the mechanics end to end.
Signing in is Google via zkLogin, transactions can be sponsored so no SUI is needed for gas, and connecting a Sui wallet directly is also supported.
$PBAY is the token concept for the platform, and it is pre-launch. Anything described on the token page is intended utility rather than shipped utility, and there is no price, supply figure, exchange listing or date to report. If you see one quoted somewhere, it did not come from us.
The case for this stack, restated as mechanism rather than adjectives:
None of that makes a prediction market good on its own. A stack with no liquidity is still a stack with no liquidity, and the honest position today is that Predict Bay's Sui path is a testnet integration with real-money trading switched off. What the stack does buy is a small, named set of things a user has to trust: the Move package, the oracle feed, the salt service, and their own key material. We keep a plain-language status of what is and is not live on the DeepBook Predict page, which is the only claim on this page that is about us rather than about the chain.