Prediction markets
How Statoblast works
Follow one question: “Will the fictional Aurora spacecraft launch before 31 December 2030?” Statoblast creates a collateralized market with Yes, No, and Invalid shares, resolves ordinary disagreement locally, and uses Zoltar branches only when local resolution cannot produce a decision or another fork interrupts the pool.
1. Mental model
#Statoblast is the market layer: one SecurityPool per question and universe that holds ETH settlement collateral, manages vault security capacity, and mints, migrates, and settles shares. Zoltar owns the questions, universes, REP, and forks underneath it; Statoblast Trading and OpenOracle sit beside it. The system overview introduces all four.
Market lifecycle. Local resolution is the ordinary route. An own-question non-decision or an independent universe fork while the pool remains unresolved and operational enters the migration and collateral-repair route.
2. Normal market lifecycle
#- Register the example question in Zoltar and deploy its SecurityPool in one universe.
- Vault owners deposit REP; traders deposit ETH to mint complete sets.
- Traders may exchange shares through an exchange such as Statoblast Trading.
- After the question ends, an initial report opens the Escalation Game.
- A strict local winner finalizes the pool; holders redeem winning shares from its settlement collateral.
Share lifecycle. One unit of ETH mints matching Invalid, Yes, and No claims; the complete set can be burned while the pool is operational or the winning share redeemed after finalization.
3. Participants and assets
#- Traders and liquidity providers
- Mint complete sets, hold or trade outcome shares, redeem claims, and optionally provide Yes/No liquidity.
- Vault owners
- Deposit REP, receive capacity ownership, maintain vault health, earn eligible fees, and may report or migrate.
- Reporters
- Place REP-backed positions on Invalid, Yes, or No in the Escalation Game.
- Liquidation receivers and operators
- A receiver vault accepts moved debt, backing, and capacity ownership. An operator submits the operation but receives no automatic protocol payment.
- Truth Auction bidders
- Supply ETH in exchange for child-pool REP-backed accounting positions when a child needs collateral repair.
A complete set is backed by ETH in its SecurityPool. REP is security and reporting capital, not settlement collateral. Capacity ownership is a pool accounting claim, and LP tokens claim only one Trading pair's Yes and No reserves.
| Asset or claim | What it represents | Where it is held or recorded |
|---|---|---|
| ETH settlement collateral | Backing for outstanding complete sets | The SecurityPool; it is allocated, not copied, during migration |
| REP | Universe-specific reporting and security capital | Wallets, SecurityPool vault accounting, Escalation Games, or migration contracts |
| Outcome shares | Yes, No, or Invalid claims for one pool and universe | The shared ERC-1155 ShareToken ledger |
| Capacity ownership | A vault's proportional claim on fee-eligible security capacity | SecurityPool vault accounting |
| Escalation claims | REP-backed positions on reported outcomes | The Escalation Game until claimed or migrated |
| Trading LP tokens | A claim on one pair's Yes and No reserves | The Trading pair's ERC-20 ledger |
4. Local resolution
#The normal path begins with an initial report. REP-backed balances then accumulate behind Invalid, Yes, and No. Their median is binding capital and determines the moving deadline. After that deadline, exactly one strict balance leader produces the local winner. Winning shares redeem from that pool.
If two outcomes reach the non-decision threshold, the game does not choose between them. Statoblast instead initiates a Zoltar fork when the fork conditions are met. See the Escalation Game explanation for the cost curve, deadlines, continuation proofs, and claims.
5. Forks and migration
#An unresolved operational pool can enter the fork path in two ways. Its own Escalation Game can reach non-decision and fork Zoltar on the market question; in this example, that creates Invalid, Yes, and No children. A fork of the pool's universe on another question can also interrupt it, in which case the children represent that categorical or scalar question's valid answers. A finalized pool remains settled and rejects later fork migration. Zoltar never chooses a canonical child.
Fork timeline. The parent halts permanently; each child becomes operational only after migration and any required repair.
A vault's parent backing claim, capacity ownership, and proportional pool collateral are routed into one selected child pool. The same parent vault migration cannot be reused across siblings. Eligible outcome-share balances work differently: users can materialize branch-specific ledger claims in multiple selected child pools. That reproduces claims, not ETH; see what Zoltar does not guarantee.
Share migration. Branch-specific token claims may appear in more than one child; settlement collateral follows vault migration and remains finite.
If a child receives too little ETH, it can sell child REP through a Truth Auction. Full demand can repair the shortfall; weak demand can leave redemption below face value.
Collateral repair. The auction raises what demand supports and never selects truth.
Repair progress. Migrated collateral plus accepted auction ETH determines the child's funded amount.
6. Fees, capacity, and liquidations
#Vault deposits create REP-denominated capacity ownership. The current accepted REP/ETH price and pool security multiplier convert aggregate ownership into live ETH minting capacity. Outstanding complete-set collateral accrues time-based fees for fee-eligible capacity owners.
A vault must remain healthy against its proportional obligations. Liquidation moves part of an unhealthy target vault's debt, backing, and capacity ownership to an authorized receiver vault. The receiver receives the funded REP award, subject to caps and rounding; the submitting operator receives no automatic reward. See protocol fees and vault liquidation for the precise accounting.
Price-guarded operations. The price coordinator supplies a fresh input; the SecurityPool still enforces live safety.
7. Security assumptions and non-guarantees
#- REP-backed incentives do not prove objective truth; users and applications decide which branches retain activity.
- OpenOracle depends on timely, profitable correction of inaccurate REP/ETH reports.
- A fork gives each child only the ETH that migrates to it (Zoltar's non-guarantees).
- Forced balances do not replace protocol-accounted collateral, and permissionless progress still depends on executable transactions.
- Spot prices from Trading pairs are manipulable and are never protocol oracles.
Normative assumptions and guarantees are listed in the security model and invariant catalog.