Branching universes

Zoltar and branching universes

Zoltar records global questions and lets an eligible parent universe branch into outcome-specific child universes. Each child universe has its own REP ledger, and REP holders move into children under fixed migration rules.

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.

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, a parent-universe credit that can mint the same amount in each valid child, 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.

Global questions and fork eligibility

Questions are global Zoltar objects and are not bound to a universe. Any account can fork a universe by naming a question when four conditions hold: the universe has not forked before, so each universe forks at most once; the question exists and its end time has passed; the caller supplies the full fork threshold in that universe's REP; and, for a child universe, ten weeks have passed since its parent fork. Zoltar does not check that the question concerns the universe, so applications such as Statoblast enforce any stricter relationship they need.

The child cooldown reserves eight weeks for portfolio branch choices, one week before shared branch activation and one week for responses. All deadlines derive from the native fork timestamp; preparing a child late does not restart them. Portfolio branches distribute recovery assets to outcome claims and may auction freshly unchosen REP to repair their ETH shortfall. The fixed response interval gives reporting a chance to proceed before another fork can interrupt the child.

The fork question decides which child universes can exist: one for each of its valid answers. A categorical question allows Invalid and each of its labels. A scalar question allows Invalid or a well-formed packed scalar answer. Zoltar sets no migration deadline; REP holders can add to their migration balance at any time after the fork.

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.
Every child starts with the parent's pre-fork theoretical REP supply, the per-universe supply figure from which fork thresholds are derived, less exactly the fork haircut.

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 Collateral Repair 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. 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 threshold divisor, rounded up, so every universe with nonzero supply has a positive fork cost. The fork haircut, the threshold divided by the burn divisor and rounded down, is not credited to migration; the remainder becomes the initiator's migration balance. Both divisors are fixed when Zoltar is deployed. The configured defaults are a threshold divisor of 20 and a burn divisor of 5: the threshold is 5% of supply and the haircut is 20% of the threshold, about 1% of supply. Zoltar rejects a burn divisor below 5, so the haircut never exceeds 20% of the threshold.

The full fork threshold leaves parent supply. Most becomes the initiator's migration balance and the fork haircut is not credited.

Fork deposit. The default split, subject to integer rounding.

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

fork haircut = ⌊fork threshold ÷ burn divisor⌋

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

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

Question and outcome encodings

Question IDs hash the stored question data together with the outcome labels, which a categorical question must supply in strictly descending order of their hashes. A categorical answer is 0 for Invalid or a number from 1 to n that selects one of the n labels in that order. 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.