Oracle Resolution and On-Chain Settlement

A prediction market resolves when a rule fixed before trading opened is evaluated against a number nobody holding a position can influence. On DeepBook Predict that number is an oracle price published on Sui and read by the contract at a fixed expiry timestamp. The contract compares it to the strike, marks each position won or lost, and the holder redeems. Predict Bay does not sit anywhere in that path — the interface builds a transaction, the chain does the rest. That is true of our Sui integration, which targets the protocol's testnet deployment and is switched off for real funds, and of the practice markets that are what you can actually trade here today; the status section near the end spells out both.

That absence is the point. In a prediction market the settlement rule is the product: every price on the screen is a forecast of what one specific number will be at one specific instant, so ambiguity about which number, published by whom, sampled when, is not a technicality — it is a hole in the instrument. This post covers what Pyth actually publishes and how, why the protocol reads three different kinds of feed while only one of them has anything to do with outcomes, the full lifecycle from oracle creation to redemption, and the real trade-offs between oracle-resolved and human-resolved markets.

Resolution is the only hard part

Everything else about a prediction market is tractable engineering. Matching is a solved problem, custody is a solved problem, charts and order tickets are craft. Resolution is where markets die, because it is the one component whose failure is retroactive: a venue that settles a single market wrongly has told every participant that its prices were never worth what they paid. There is no patch release for that.

What makes it hard is mapping a state of the world onto a binary answer. Price markets are the easy end of that problem. "Will BTC be above $X at 16:00 UTC" leaves almost nothing to interpret — provided you have nailed down which price series, sampled at which instant, and what happens when that series is unavailable. Those three questions are precisely what an oracle design answers, and a design that leaves any of them open has not removed discretion, only hidden where it lives.

• Pre-committed. The resolution source and the sampling instant are bound when the market is created, not chosen afterwards by whoever prefers the answer.
• Non-discretionary. Evaluating the rule takes a comparison, not a judgement. If a human has to decide what the rule meant, the rule was underspecified.
• Adversarially priced. Pushing the reference number across the strike for one instant should cost more than an attacker can win from the positions that instant decides.

What an oracle actually is

An oracle is not a price. It is a pipeline plus a rule for reading it: a set of publishers, an aggregation method, a transport that gets the aggregate on-chain, and contract code deciding which update counts. Each of those is a distinct trust assumption. Being specific about all four is the difference between an oracle-resolved market and a market that merely uses the word.

How Pyth publishes a price

Pyth is a first-party oracle network: the entities submitting prices are the ones that see the order flow — exchanges, market makers, trading firms — rather than third-party nodes scraping public endpoints. Each publisher submits its own price and its own confidence interval, and the network aggregates those submissions into a single price with an aggregate confidence band. That band is a genuinely useful signal, not decoration. It widens when publishers disagree or when a venue goes dark, and it is the cleanest on-chain indication that a print should not be taken at face value.

Delivery is pull-based rather than push-based. Instead of the network paying to write every asset's price to every chain on a fixed heartbeat, signed updates are made available off-chain and whoever needs one posts it on-chain in the transaction that consumes it. This inverts the cost model — the consumer pays for freshness at the moment freshness matters — and it means the on-chain price carries a publish timestamp that contract code can, and should, check before trusting it. Pyth also operates a low-latency channel for consumers that need updates faster than the standard cadence, and DeepBook Predict binds to it explicitly: the event emitted when a round's oracle object is created carries a Pyth Lazer feed identifier alongside the expiry, the minimum strike and the tick size, and the testnet deployment records a Lazer feed id per underlying.

Three feeds, not one

A binary option needs more than a current price. Its fair value is a probability, and a probability requires a distribution: where the market expects the asset to be at expiry, and how wide the uncertainty around that expectation is. So the pricing layer reads three distinct feeds published on Sui — spot, forward and volatility surface — alongside Pyth price feeds for the underlying. Being precise about which does what matters, because only one side of it touches resolution.

The surface is parameterised rather than sampled point by point — the on-chain feed publishes five coefficients plus a risk-free rate, describing total variance as a function of log-moneyness, which the pricing math evaluates for whatever strike you ask about. The practical consequence is easy to state: a change in the volatility surface moves what your position is worth on the way to expiry and moves nothing about whether it wins. At expiry the surface stops mattering entirely. The contract performs a comparison against the settlement price, and the volatility number has no role in the payout. For why a binary's price is readable as a probability at all, see binary options vs prediction markets.

The settlement lifecycle, end to end

Here is the full path for one round, from the moment the market exists to the moment a position pays. If you want the protocol overview rather than the settlement detail, what is DeepBook Predict is the better starting point.

1. Oracle object created

   A shared oracle object is published on-chain for one underlying and one expiry, with the price feed identifier, the minimum strike and the tick size bound into it. These are fixed at creation. Nothing later in the lifecycle can change which feed the round settles against.

2. Round baseline frozen

   For short-duration rounds the strike is not a number an operator types in. It derives from an on-chain reference tick — a feed price captured for the round and snapped to the tick grid — so every participant sees the same strike, taken from the same source the round will eventually settle against. The reference is seeded on-chain shortly before the round rather than at listing time, which is why a market can legitimately show a pending baseline: until the reference tick is set there is no strike to mint against, and an honest interface gates the mint rather than guessing one.

3. Trading window

   Positions are minted against that oracle. A lower tick and a higher tick define the range being bought; sentinel values at the ends of the tick range express the one-sided contracts, with zero as the lower bound meaning "below X" and the maximum tick as the upper bound meaning "above X". Premium is paid in the settlement asset and the position is held in your on-chain account with the protocol.

4. Expiry

   At the expiry timestamp a settlement price is recorded on-chain against that market's oracle — a single fixed-point number, written once, after which the market is settled. How a given deployment derives that number from its feed is a property of the deployment, not something an interface chooses; what the contract sees is one settled price per expiry.

5. Settlement

   The contract compares that price to each position's range. Inside the range, the position is worth its full fixed payout per contract. Outside, it is worth nothing. There is no partial credit and no rounding toward the money; a binary is discontinuous at the strike by construction.

6. Redemption

   The holder redeems the settled position for the payout. The entitlement sits on-chain until a redeem transaction is sent, which is what makes the whole thing auditable after the fact — the position, the settlement price and the payout are all objects and events anyone can read.

Bound at creation

Underlying, expiry timestamp, price feed identifier, minimum strike, tick size

Strike representation

An integer number of ticks, not a floating-point price

One-sided contracts

Sentinel ticks at either end of the range — 0 as the lower bound, (1 << 30) − 1 as the upper

Settlement input

A single settled price recorded against the market's oracle at expiry

Payout

A fixed amount per contract if the settlement price lands inside the range, otherwise zero

Settlement asset

dUSDC on the testnet deployment

One detail that surprises people: an oracle object carries no "hourly" or "daily" field. What it binds is an expiry timestamp, and clients infer the human label from how that timestamp aligns to the clock — top of the hour reads as an hourly round, a fixed UTC hour each day as a daily one. Cadence does exist as protocol configuration, since each cadence carries its own tick size, admission grid and expiry allocation. But the label on a market card is presentation layered over a timestamp, not a string the chain stores.

Oracle-resolved versus committee-resolved

Not every question is a number. "Will this bill pass" has no feed, and the honest answer is that such markets need a different mechanism: a written rule plus a human reporter, backed by an economic dispute game rather than a price series. Both designs are legitimate. They fail differently, and knowing how is most of what a trader needs from this topic.

The strongest version of committee resolution is the optimistic-oracle pattern: someone posts a proposed answer with a bond, a challenge window opens, and if nobody disputes it the answer stands. If someone does, the question escalates to token-holder voting and the losing side forfeits its bond. It handles questions no feed can express, and it does so with real skin in the game. It also imports two properties a price feed does not have — latency that is unbounded in the disputed case, and final outcomes that depend on how an electorate reads a sentence. For the platform-level view, Predict Bay vs Polymarket puts the two models side by side.

Where each model belongs

Short-duration price markets — the hourly and daily rounds on the BTC market page — belong on a feed. A dispute window measured in hours or days would outlast most of these contracts entirely, and a question with a numeric answer does not need an adjudicator. Long-horizon questions about real-world events belong on a dispute game, because there is no feed and someone has to read the news. The mistake is using either mechanism outside its range. A discretionary committee on an hourly BTC contract inserts a discretion nobody asked for; a price feed on "will the merger close" is an oracle for a number that does not exist.

What can still go wrong

Oracle resolution removes discretion. It does not remove risk, and a page claiming otherwise would be worth less than one that names the failure modes.

• Sampling choice. A settlement price can be one print at one timestamp or an average over a closing window. The first is precise and auditable and concentrates the entire risk into one moment; the second is harder to push and blurs the number. Both are defensible designs, and they are not interchangeable — find out which one the contract you are trading uses before sizing a position.
• Stale or degraded feeds. A price that stopped updating is still a price. Publish timestamps and confidence bands exist for exactly this reason, and contract code that reads a feed without checking staleness is trusting a number that may describe a market which no longer exists.
• Publisher-set risk. First-party publishing raises the floor on data quality, because these are the venues where the trade actually happens. The aggregate is still only as independent as the publishers behind it. Aggregation is designed to be robust to a minority of bad submissions, not to a correlated one.
• Manipulation of the underlying. The oracle can be entirely honest and still report a price someone paid to create. The defence is economic rather than cryptographic: the cost of moving spot must exceed the value of the positions that move decides. This is why liquidity in an asset matters to a derivative that never touches it.
• Tick and boundary edges. Strikes are integer ticks, and mints are admitted on a grid coarser than the raw tick size, so not every price is a legal strike — a mint off that grid is rejected by the chain, not rounded. The strike derived from the round's on-chain reference is admitted through an explicit exception to the same grid, which is exactly why that reference has to come from the chain rather than from a client. And a settlement price landing precisely on a strike is decided by the contract's comparison operator, not by intuition about what "above" ought to mean.
• Upgrade and admin authority. Every deployment has some notion of who may publish oracle objects, seed round baselines and set parameters. That authority is part of the trust model whether or not the documentation frames it that way, and it is a fair question to ask of any protocol, this one included.

What this means on Predict Bay

Predict Bay is an interface. On the Sui path — the testnet integration described above — it builds the mint transaction, submits it, and reads your positions and balances back from the chain. The strike comes from an on-chain reference, the pricing comes from feeds published on Sui, and the payout comes from a contract function. There is no step in that sequence where we determine an outcome, and no lever that would let us. The same holds for the practice markets you can trade today: they resolve against an on-chain price feed on a schedule fixed when the round opens, which nobody here can move after the fact. It is a smaller claim than "trust us" and a far more useful one: the trust you extend goes to the feed publishers and to the protocol's code, both of which you can inspect without asking our permission.

That last point is also why practice mode is worth more here than it usually is elsewhere. Because resolution is mechanical and feed-driven, a practice market can mirror it exactly — same strike, same feed, same expiry, same payoff function — and the practice money is the only part that is simulated. Practising against a real settlement rule teaches you the instrument; practising against an invented one teaches you a habit you then have to unlearn. For how the order book, the oracle layer and passwordless sign-in fit together, the Sui prediction market stack walks the whole thing; how it works is the short version, and the FAQ covers the rest.