Branching universes

Zoltar and branching universes

Zoltar records global questions and lets an eligible parent universe branch into outcome-specific child universes. It provides ledgers and migration rules, not an on-chain judge that chooses the true branch.

A parent becomes separate child ledgers

For a binary market question, one forking parent universe creates separate Invalid, Yes, and No child ledgers. An unrelated fork instead follows its own fork question's valid answers. Zoltar does not select or delete a branch.

Forking parentInvalid branchValid outcome branches

Branch set. A binary launch question produces Invalid, Yes, and No children.

Alice converts 100 parent REP into a migration balance and uses it to mint 100 child REP in the Yes universe and 100 child REP in the No universe.

These are separate branch-specific ledgers. They are not 200 globally interchangeable REP, they do not copy ETH, and Zoltar does not guarantee equal economic value across branches. Applications and users later determine where economic activity continues. Zoltar never selects or deletes a canonical child.

Global questions and fork eligibility

Questions are global Zoltar objects. An eligible ended question can be supplied when forking an eligible universe. Zoltar checks that the question exists and has ended and that the universe satisfies its fork conditions. It does not prove that a real disagreement exists or bind that question to that universe. Applications such as Statoblast can enforce stricter relationships.

A question defines the possible child keys. Categorical questions use Invalid plus their configured outcome indices. Scalar questions use Invalid or a well-formed packed scalar answer.

What Zoltar guarantees

Universe and child identities derive deterministically from their parent and outcome.
Only valid outcomes for the fork question can create child universes or receive child REP.
Each account cannot mint more REP into one child than its recorded migration balance permits.
Child REP is controlled by Zoltar and remains tied to its universe identity.
Fork threshold and haircut accounting reduce parent theoretical supply according to the configured integer rules.

What Zoltar does not guarantee

It does not choose a truthful or canonical child.
It does not copy ETH or application state into every child. Each child receives only the collateral that migrates to it, so a Statoblast child pool can remain impaired if too little ETH follows and its Truth Auction cannot raise the difference.
It does not guarantee equal REP value, liquidity, or redemption across branches.
It does not prove a supplied global question is relevant to the universe being forked.
It does not guarantee that applications continue in every branch.

Deterministic identities and migration accounting

A child universe ID is derived from its parent universe ID and selected outcome. Child REP uses a predictable deployment address derived from the Zoltar address and universe ID; its display sequence does not affect that address. Adding parent REP to a migration balance burns or transfers it from the parent ledger. That balance can then materialize the same branch-specific amount in multiple valid children, with per-child accounting preventing replay beyond the source amount.

Starting a fork removes the fork threshold from parent supply. The threshold is the live universe theoretical REP supply divided by the configured divisor, rounded up, so every universe with nonzero supply has a positive fork cost. The configured haircut is not credited to migration; the remainder becomes the initiator's migration balance.

The full fork threshold leaves parent supply. Most becomes migration credit and the configured haircut is not credited.

Fork deposit. With the default burn divisor, about 80% becomes migration credit and about 20% is the admission haircut, subject to integer rounding.

fork threshold = ⌈live theoretical REP supply ÷ threshold divisor⌉

uncredited haircut = ⌊fork threshold ÷ burn divisor⌋

Each fork reduces theoretical supply by its haircut, so later thresholds decline along that lineage.

Repeated forks. Integer-rounded haircuts reduce theoretical supply and therefore later fork thresholds.

Question and outcome encodings

Question IDs hash the stored question data and, for categorical questions, the ordered labels. A categorical outcome must be Invalid or an in-range label index. Scalar questions store a range and tick count; a valid packed answer allocates all ticks between its two payout fields. The all-zero word is canonical Invalid, while reserved-bit or payout-sum violations are malformed and rejected.

A scalar answer contains reserved bits, a namespace bit, and first and second payout numerators. Valid payout fields sum to the question's tick count.

Namespace bitFirst payoutSecond payout

Packed scalar answer. Encoding validation keeps Invalid distinct from malformed input.

Exact storage fields, permissions, and entrypoints are listed in the contract reference. Security assumptions are listed in the security model.