How Statoblast works

Statoblast is the market layer. Each SecurityPool ledger serves one question in one universe. Separate portfolios keep separate ledgers even when their question and configuration match. Every ledger belongs to a portfolio and uses its shared capital and settlement accounting. A fixed portfolio containing one question uses the same contracts and rules as a portfolio containing many questions. Zoltar owns the questions, universes, REP, and forks underneath it; Trading and OpenOracle sit beside it. The system overview introduces all four.

1. Register the example question in Zoltar and add it to a portfolio whose admission policy permits it.
2. Vault owners deposit REP; traders deposit ETH to mint complete sets.
3. Traders may exchange shares through an exchange such as Trading.
4. After the question ends, the first REP deposit on an outcome opens the Escalation Game.
5. An unchallenged report wins three days later; a contested game runs until one outcome is the strict leader at its deadline. Holders then redeem winning shares from the pool's settlement collateral.

Traders and liquidity providers

Mint complete sets, hold or trade outcome shares, redeem claims, and optionally provide Yes/No liquidity.

Vault owners

Deposit REP, set a separate underwriting commitment in ETH, keep it backed, earn 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 funded receiver accepts an underbacked commitment and receives a REP award from that owner’s deposit. Execution is worthwhile only when the award covers its cost.

Collateral Repair Auction bidders

Supply ETH in exchange for child-pool REP-backed accounting positions when a child needs collateral repair.

The game opens with the first REP deposit after the question ends. 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. Anyone can then fork the universe on the market question through Statoblast, which pays the fork threshold from the triggering question’s REP escrow in the portfolio reporter ledger. See the Escalation Game explanation for the required-support curve, deadlines, payouts, and how games continue across forks.

5. Forks and migration

A question's non-decision or a fork on another question enters the same shared branch process. Owners choose once per portfolio and universe. Questions, outcome tokens and reporter claims are prepared lazily when used. See the choice windows and recovery rules below.

6. Fees, underwriting, and liquidations

Each owner's REP backs their authorized ETH commitment. Purchases require sufficient healthy aggregate commitment and a fresh funded oracle price. Returning complete sets releases demand; it does not require owners to recover REP question by question. Fees accrue separately from principal. Liquidation transfers only the affected owner's commitment and REP.

A SecurityPoolPortfolio lets traders buy outcomes for many questions against one aggregate backing pool. REP stays in a central capital ledger. Each owner retains an exact claim to their own principal and chooses how much standing commitment to authorize. There is no common REP share price and no purchase from individual vaults. Questions retain separate outcome tokens and reporting games.

All REP deposited for an owner in a portfolio universe backs that owner's single commitment, including any surplus above its required backing. Depositing more REP immediately strengthens that backing; there is no separate pledge or top-up step. Each owner chooses a health target for authorizing commitment. A larger buffer supports less commitment with the same REP but gives more protection against price changes. Admission and surplus withdrawals use the conservative edge of the oracle’s configured error band. Paid liquidation uses the opposite edge and compares the entire deposit with required backing, so a small price error alone cannot create an execution reward. Falling below the owner's chosen buffer alone does not trigger it. New purchases require enough healthy commitment at a fresh shared REP/ETH price. New commitments must fit a finalized report’s funded exposure. Independent report candidates prevent one pending report from blocking another sponsor. An owner can authorize growth using an independently finalized, sufficiently funded report; its conservative collateral requirement stays attached to that owner until a new shared report covers the enlarged pool.

The creator fixes an admission-policy contract, the annual time-fee rate, the question horizon and economic minimums. The interface offers either open admission or a permanently fixed question list. Other policies work onchain. Registration moves no REP and creates no claim obligation for owners. Every purchase checks admission, pays the configurable backing-based fee and prepaid resolution premium, and delivers its three outcomes atomically. Unused payment budget returns to the buyer.

Income is separate from principal. Continuously earned question fees belong to the healthy commitments that served during that interval. Purchase fees and REP income vest over a configured duration. A new deposit cannot collect an earlier owner's earned fees, and borrowing REP for one transaction cannot capture a whole prepaid reward. Owners collect aggregate earnings without visiting questions. See portfolio fees for the earning rules.

Reporter REP has its own custody and cannot be taken from a vault's backing. Irrevocably released dispute surplus enters the separate REP income stream. It does not raise an entry or exit exchange rate. Final reporter claims and their required burns remain separately funded.

The chosen health target protects voluntary changes: authorizing more commitment, receiving a takeover, or withdrawing backing requires enough REP at that target and a fresh conservative price. Raising the target on a live position also requires sufficient backing; an owner can deposit REP and raise it in one transaction. Lowering the target never increases commitment automatically. A price move that leaves the position below its health target does not itself cause liquidation, and deposits and earned-fee claims remain available.

An owner can withdraw surplus REP while keeping the remaining backing sufficient to meet the chosen target. This does not require other owners to be healthy. Principal with no remaining commitment is freely withdrawable. To reduce commitment, the owner sets a lower amount, including zero for a full exit, and the reduction is queued for retirement. Returning complete sets reduces aggregate demand, letting queued commitments retire before new purchases consume the spare capacity.

Each owner has at most one live position, either active or in a retirement cohort. Partial retirement keeps the whole deposit behind the smaller commitment and stops at the requested amount, then returns that position to active status. The request fixes a commitment amount; it does not automatically adjust to later prices. Full retirement releases the entire deposit. The pool serves a closed current cohort before the next cohort. The owner cannot change or cancel a pending request: until it is served, setting a commitment accepts only the requested amount, which leaves the request in place and, at a fresh price, cures an underwater position.

Full exits settle in groups, while each service call updates at most one partial-retirement boundary. While a partial request waits, its intended remaining commitment stays available to purchases if the whole position is healthy; only the queued reduction is reserved for exit. An owner can complete their own request without processing earlier owners when spare capacity also covers those earlier requests. Otherwise retirement waits for more capacity or progresses through the queue. Purchases do not have to clear the whole queue, and withdrawal does not add a question-by-question recovery task.

Liquidation affects the undercollateralized vault. Apart from a takeover, only the owner can cure. Lowering the commitment, or repeating a pending request, at a fresh price cures an underwater vault at once, down to no less than the requested value: the unbacked commitment is removed, subject to the minimum useful action size and the spare commitment above demand, and only the rest of the reduction waits in the retirement queue. The cure can skip the queue because unbacked commitment never counts as healthy capacity, so removing it takes no spare from earlier requests. When the new value is at or below the backed amount and spare capacity covers the deficit, the remaining commitment is fully backed. If the owner does not act, or spare capacity is insufficient, the position remains eligible for takeover by a funded buyer. The buyer's REP reward comes only from the target position. The takeover clock begins automatically at the first accepted adverse price after the position's latest recovery, so no keeper must pay to start it. Cures pay nobody; takeovers transfer the quoted REP with the underwriting obligation and cure the target first. Neither requires an ETH reserve. Other owners' principal is unchanged. Keepers pay transaction gas and act when a takeover award justifies the cost. The contract reference specifies cure sizing and partial cleanup.

Health and fee accounting use indexed aggregates. Work follows tree paths and the owner's single position, rather than all questions, owners or expired streams. The healthy-commitment index is balanced. Purchase-fee and REP-income rewards use a fixed vesting duration, so searches exclude already released history and are bounded by that duration. Question resolution premiums use an expiry index that releases only earned fees and burns unused terminal funding, without scanning questions. Finality checkpoints read the newly matured prefix and append one immutable record; they do not copy historical tree paths. Storage still grows with activity. Creating a question, using it for the first time in a branch and processing one's tokens still require transactions, but they do not impose a migration batch on every backing owner.

A native universe fork fixes an eight-week choice window. Each owner may make one irreversible branch choice for their commitment and its entire deposit in that universe, including the surplus buffer. Principal with no remaining commitment and old earnings stay separately claimable in the parent. After choices close, one shared migration prepares each requested branch. Each branch inherits the outstanding outcome claims, including tokens not yet materialized there. Parent ETH follows the fraction of total ETH commitment that chose the branch, so choosing excess REP cannot capture extra cash.

Chosen providers retain their own REP, commitment and health target. REP in branches they did not choose backs those branches’ inherited outcome claims. A shared collateral repair auction can sell freshly unchosen REP to repair the branch’s ETH shortfall. Bidders, including former owners, supply only their bid ETH; the purchased REP backs their accepted ETH commitment. A positive fill below the auction’s ETH target sells all fresh inventory. With no feasible lot, none is sold; a sale reaching the target can leave unsold REP with the claims. Old recovery REP is excluded from the sale. At week nine, a prepared branch can activate even if no sale succeeds. Returning complete sets or redeeming winning shares then pays the claim’s proportional ETH and remaining recovery REP together. Full repayment in ETH is not guaranteed. A branch with recovery REP or a cash shortfall cannot mint new complete sets or charge ordinary holding fees; later buyers cannot capture its inherited recovery assets.

Missing the choice cutoff does not select a default branch: the owner’s committed REP backs inherited claims in every child. For questions still live at the fork, holders recover unassigned parent ETH by combining separate Invalid, Yes and No recovery rights. These rights transfer independently of child-token migration rights. Questions already final retain their ETH and REP claims in the source pool. A later fork migrates only the remaining live recovery REP, once per branch. Child forks cannot begin before week ten; late preparation does not restart these deadlines. Questions and reporter claims are prepared lazily when used, and traders still migrate shares through each intervening universe. The portfolio fork reference specifies the interfaces.

• 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).
• ETH pushed into a pool outside its accounting is not counted as collateral. Steps that anyone may trigger, such as forking or starting an auction, still need someone to send the transaction.
• Spot prices from trading pools are manipulable and are never protocol oracles.

Normative assumptions and guarantees are listed in the security model and invariant catalog.