System overview

The problem

A prediction market lets people trade on a question such as “Will the fictional Aurora spacecraft launch before 31 December 2030?” Its shares are worth something only after someone decides what actually happened. That decision is the weak point: whoever controls it controls the money.

Zoltar and Statoblast make the decision expensive to corrupt in two ways. First, anyone who reports an outcome must stake REP, the protocol's reputation token, behind it, and the contracts settle in favour of the outcome with the most REP staked. Reporters whose outcome loses forfeit their stake, so backing an answer the rest of the market will not support is costly. Whether that pressure keeps reports honest depends on the participation assumptions in the security model.

Second, when reporters cannot agree, the system does not pick a side. Its ledger, called a universe, splits into child universes, one per possible answer, and the market decides which child stays valuable. A dishonest majority of REP cannot stop honest participants from moving their REP into the child that records the honest answer; what that does and does not guarantee is covered with Zoltar.

Four words you will see everywhere

REP

The Reputation token. Holding REP lets you report outcomes and underwrite markets. It is also what you risk: a reporter loses REP when the outcome they supported loses.

Universe

A ledger that can branch. Markets and REP balances belong to a particular universe. Questions are registered globally, so the same question can have markets in multiple universes. When reporters split irreconcilably, the universe forks into children, one per possible answer, each with its own REP.

Portfolio

A shared capital and settlement system that backs admitted questions. Each owner keeps an individual REP account and commitment; each question keeps separate outcome shares and accounting. A portfolio can hold one fixed question or many.

SecurityPool

The question contract inside a portfolio. It exposes outcome shares, reporting and redemption; portfolio modules hold REP and ETH.

Four components

Zoltar

The ledger. It records questions, universes, REP, and forks. It never judges which answer is true.

Statoblast core

The market. It deploys a SecurityPool for a question, universe, and pool configuration, mints and redeems shares, settles ordinary disputes locally, and moves markets into child universes after a fork.

Trading

An exchange for Statoblast shares. It is one of possibly many; it neither creates nor resolves markets.

OpenOracle

A price feed. It supplies a contestable REP/ETH exchange rate whenever the protocol must check that REP still covers ETH obligations. It has no say in market outcomes.

One market, start to finish

Someone registers the Aurora question in Zoltar and admits it to a portfolio under that portfolio’s admission policy. Owners deposit REP and authorize shared commitments. Traders purchase complete sets through the portfolio: one Yes, one No and one Invalid share at the question’s current backing rate. ETH goes to central settlement custody, with a separate balance for the question. Traders can exchange those shares; reporting begins after the question ends.

Reporters stake REP behind an answer in the pool's Escalation Game, a dispute round whose deadline moves later as the contested amount grows. When the deadline finally passes, the market resolves if exactly one answer holds more REP than every other, and winning shares redeem the question’s backing from central settlement custody. Usually that is the end of the story.

If two answers reach the non-decision threshold, the universe can split into Invalid, Yes and No children. Owners record their branch choices before the portfolio’s cutoff. Shared branch accounting migrates their capital without requiring a separate owner claim for every question. Shareholders can materialize claims in multiple children, but ETH is not duplicated. Each portfolio branch repairs its shortfall through a shared Collateral Repair Auction; winning bidders become capital owners. Forks and migration explains the process, and what a fork does and does not promise describes its limits.