Augur Statoblast White Paper

Augur Statoblast is a binary prediction market built on top of Zoltar. It creates security pools scoped to individual questions, lets traders mint and redeem ETH-backed shares, lets REP vaults provide underwriting, and tries to settle disputes locally before forcing Zoltar to fork. Statoblast assumes Protocol Security Model.

The Zoltar universe fork and Statoblast pool-fork activation are distinct transitions. On the pool's own local non-decision path, Statoblast activates pool fork mode immediately before forking Zoltar in the same transaction. After an unrelated external Zoltar fork, anyone must separately initiate the affected pool's fork handling. Child pools are then created lazily. Vault holders choose a child by migrating their vault positions, and the forker materializes the corresponding child REP.

Proportional open-interest collateral moves with each vault migration; it is not duplicated across universes. As a result, some child universes may not receive enough collateral to fully back their inherited open interest.

After the migration window ends, each undercollateralized child pool may run its own truth auction, selling that child universe's REP to raise as much repair ETH as demand supports.

The stack has two protocol identities. Zoltar is the base truth/forking oracle layer for universes, questions, scalar math, and REP branching. Augur Statoblast is the application layer that adds market collateral, underwriting, local disputes, migration, and collateral repair. For the base oracle layer, see zoltar-whitepaper.html.

Statoblast's lifecycle starts by creating a pool scoped to one question and universe, letting traders and REP vaults use it, trying to resolve disputes locally, and only then turning to fork and collateral-repair machinery.

1. A question is registered in Zoltar and a Statoblast security pool is deployed for that question in one universe.
2. REP vaults fund underwriting capacity and users mint ETH-backed complete sets.
3. After question end, disputes first try to resolve locally through the escalation game.
4. If local resolution reaches non-decision, Statoblast can trigger a Zoltar fork. An unrelated external Zoltar fork can also interrupt the pool before local resolution. In either case, a separate pool-fork activation snapshots the parent before child-pool migration begins.
5. If a child pool is missing ETH collateral after migration, it can sell child-universe REP through a truth auction to repair that collateral gap.
6. The child pool in the branch users choose to keep using resumes operation and users settle or redeem positions there.

Happy Path vs Recovery Path

Statoblast is not an exchange venue. It issues transferable ERC-1155 outcome shares and manages redemption, migration, and collateral accounting; secondary market trading sits outside this protocol.

A Statoblast lineage begins with one origin SecurityPool and includes the descendant child pools created after forks. It sits between two independent oracle boundaries: Zoltar supplies question and universe identity, while OpenOracle supplies contestable REP/ETH prices through a pool-specific coordinator. Each contract owns only its part of the lineage's state.

Security assumptions: A01 risk-adjusted incentives, A03 independent participants, A13 REP liquidity, and A06 lifecycle executors.

• Question creators register questions in Zoltar question data, creating the objects around which Statoblast markets can be built.
• REP vault operators deposit REP into a security pool and provide REP-backed underwriting capacity. Their deposits back open interest and earn fees extracted from collateral over time.
• Traders mint complete sets with ETH and hold transferable outcome shares; secondary-market execution is external to Statoblast.
• REP vault operators can escrow vault-backed REP behind Invalid, Yes, or No after a question ends so the local escalation process can settle locally or force a non-decision.
• Anyone can create child pools, while vault owners and share holders move vault state and shares across child universes after a Zoltar fork. Child creation reproduces unresolved escalation state and aggregate backing once; winning proofs can be relayed permissionlessly and always pay their recorded depositors.
• Truth-auction bidders buy REP with ETH when a child pool in a child universe needs to restore missing collateral.
• Liquidators move undercollateralized bond allowance away from unsafe vaults.
• Price reporters and settlers in the OpenOracle flow supply a REP/ETH solvency price for bond accounting, not a truth outcome for the question itself.

Security assumptions: A08 REP valuation, A14 REP economic backing, A21 genesis REP and WETH behavior, A23 canonical deployment, A15 intended question selection, A25 safe immutable parameters, A22 asset-recipient compatibility, A24 client and wallet integrity, and A28 account authority.

A SecurityPool is a lineage-specific Statoblast contract for a question in a universe. Vault operators deposit REP, choose bond allowance, and underwrite ETH-backed complete sets in that pool's local accounting ledger.

Origin pools are narrower than the general Zoltar question model. The factory requires the question to exist, the universe to be unforked, the universe REP token to be present, and the question to have exactly two categorical labels in this order: Yes, then No. Invalid is added by Statoblast as the third trading and resolution outcome; it is not one of the two origin-pool labels checked by the factory. The factory also records each deployment and exposes paged deployment-history reads for indexers and UIs.

Pool-related addresses are deterministic and their lineage identity commits to the origin's immutable initialReportPriorityFeeWeiPerGas. Origins configured with different priority fees therefore cannot share a pool or share-token namespace, while children inherit their origin's configuration. The Operator Reference owns the exact address and registry-key derivations.

An inherited child and a newly created origin may coexist for the same question, multiplier, initial-report priority fee, and universe. This is intentional: their origin IDs, pool addresses, share tokens, collateral ledgers, and migration paths are distinct. A caller selecting a pool therefore selects an origin lineage, not merely a question and universe. Because a fresh origin cannot occupy an inherited lineage’s registry entry, origin deployment does not scan universe ancestors.

Statoblast uses OpenOracle to estimate the value of REP compared to ETH. OpenOracle settles WETH/REP amounts, and the coordinator stores the result as scaled REP per ETH because solvency checks compare REP backing against ETH obligations.

Statoblast uses the REP/ETH price to compare REP backing with ETH-denominated obligations. Vault operators choose their security bond allowance. A new allowance must leave the affected vault non-liquidatable, while aggregate pool REP must independently satisfy the same multiplier-adjusted inequality. Only vaults are liquidation targets. BPS_DENOMINATOR = 10_000 converts the stored Statoblast multiplier from basis points.

Equality at allowance admission is permitted because liquidation uses the strict inverse inequality. Later REP withdrawals and escalation deposits cannot move either the vault or aggregate pool below that multiplier-adjusted boundary while the allowance remains active. All operands are atomic integers: the contract compares the products exactly, while a derived maximum allowance rounds the quotient down. The pool-wide maximum uses that floored aggregate ceiling minus the allowances already assigned to other vaults. Liquidation requires the target to be liquidatable, bounds the transfer, and verifies that the caller remains safe while aggregate allowance is preserved.

Complete Sets

Traders and liquidity providers can mint complete sets by calling createCompleteSet with ETH. For each complete-set unit, the pool mints one Invalid, one Yes, and one No ERC-1155 share through ShareToken. The deposited ETH increases completeSetCollateralAmount.

• While the pool is operational, a full complete set can be burned with redeemCompleteSet to recover its pro rata share of collateral. A child uses its remaining economic claim supply as the denominator, including fork-time claims whose ERC-1155 balances have not materialized there yet.
• After the fork route finalizes an outcome, users can redeem winning outcome shares through redeemShares.
• The pool rejects a mint when the resulting collateral would exceed vault-assigned, fee-eligible security bond allowance. Allowance reserved for an unclaimed truth-auction winner cannot secure new open interest until settlement attaches it to that winner's vault. A positive deposit must also convert to at least one complete-set unit.

Fee Extraction and Retention Rate

Complete-set collateral gradually decays into an unallocated fee reserve. Fee-eligible vaults accrue fees in proportion to their assigned security bond allowance. Vault checkpoints turn whole-wei entitlements from that reserve into redeemable vault debt.

The retention rate falls as utilization rises, so security becomes more expensive as open interest consumes underwriting slack.

• completeSetCollateralAmount starts higher and decays gradually.
• totalFeesOwedToVaults grows only when a vault checkpoints whole-wei fees that it can redeem; accrued but not yet checkpointed fees remain in a separate pool reserve.
• feeIndex tracks vault fee accounting.
• currentRetentionRate changes as utilization changes.

Retention follows a piecewise heuristic in SecurityPoolUtils.calculateRetentionRate. It starts high, declines linearly until 80% utilization, and then stays at the minimum retention rate. The intent is to charge more aggressively for security as utilization rises and underwriting slack falls.

Read as a user-facing metric, that retention curve becomes the annualized open-interest fee shown in the UI. At zero utilization, the constants imply roughly a 10% yearly fee. Once utilization reaches the 80% dip, the annualized fee is roughly 50% and then stays flat because the on-chain retention rate is already pinned to its minimum. The UI annualizes the rate as annualFee = 1 - (retentionRate / PRICE_PRECISION)^SECONDS_PER_YEAR.

When feeEligibleSecurityBondAllowance == 0, the pool sets feeIndexDelta and reserveCredit to zero, clears feeIndexRemainder, leaves collateral unchanged, and advances the accumulator to the clamped current time. This prevents unclaimed auction allowance from earning retroactive fees. The remaining fee-index equations apply only when fee-eligible allowance is positive.

Fee accrual is lazy: state-changing pool operations checkpoint the global fee index, and vault operations checkpoint each vault against that index. Fractional amounts remain in explicit remainders until they accumulate into whole wei, so callers do not need to iterate over every vault when time advances.

Fee accrual is time-clamped. The pool extracts collateral into fees only until the question end time while the universe remains unforked; after the universe forks, the fee accumulator is instead clamped to the fork time. Retention-rate updates no-op outside Operational mode or when the recalculated rate is unchanged. While operational, utilization uses vault-assigned, fee-eligible allowance; zero eligible allowance selects the maximum retention rate. Unclaimed auction allowance therefore cannot change the live fee curve.

A child pool begins a new fee epoch when migration and any truth auction finalize. Only allowance already assigned to a vault enters the fee denominator. Auctioned allowance becomes fee-eligible when the winning bid is claimed, after that vault first checkpoints at the current index. Each delayed claim adds only its newly assigned amount to the live eligible total; it does not reconstruct that total from fork-time migration counters, so intervening allowance changes and liquidations remain intact. Per-vault fractional remainders survive public checkpoints, while whole fees move from the pool reserve into totalFeesOwedToVaults; this keeps aggregate debt equal to redeemable vault balances. The totalAccruedFees() view adds that assigned debt to the unallocated reserve when callers need to reconcile all fee-adjusted collateral.

A fork permanently closes the parent's fee epoch. The pool tracks how much eligible allowance still has not checkpointed the final index. After every eligible vault syncs, any whole reserve wei left solely from aggregating individually sub-wei vault remainders cannot become redeemable, so it returns to complete-set collateral. Until the last checkpoint, that reserve remains protected by totalAccruedFees().

Solvency Operations and Liquidation

Withdrawals, allowance changes, and liquidation depend on a fresh REP/ETH price. Liquidation transfers unsafe allowance to a non-liquidatable caller vault and seizes unlocked target REP, so it redistributes backing rather than creating it.

Read how the liquidation works from Liquidation Design.

ShareToken is an ERC-1155 contract. Each complete set mints one Invalid, one Yes, and one No share. The token id encodes the universe id and outcome, making positions fork-aware.

A positive ETH deposit must convert through cashToShares to at least one complete-set unit. If rounding would mint zero shares, createCompleteSet reverts with Exchange rate undefined instead of accepting collateral.

Shares can materialize across forks. ShareToken.migrate preserves a parent-universe token id as a persistent entitlement and mints child-universe token ids for selected valid, non-malformed fork outcomes.

If none of the selected children has received a source entitlement, the first call materializes the full current source balance in each selected child. On a later call, each child receives only current source balance - amount already materialized. If every selected delta is zero, the call reverts. The canonical guarantees are FORK-10, SHARE-04, and FORK-11.

At the implementation level, redeemShares burns the holder’s full materialized balance of the winning token id and pays the burned amount’s pro-rata share of current collateral, using the pool’s remaining economic claim supply as the denominator. That shareTokenSupply includes materialized ERC-1155 balances and fork-time entitlements that can materialize later. In the healthy case this corresponds to a clean 1:1 redemption outcome against the economic meaning of a complete-set claim, subject to collateral accounting remaining intact through migration and any required auction repair.

The important edge case is fork recovery. If a child pool emerges from migration with incomplete collateral, the truth auction sells REP for ETH so the child pool can restore the collateral base needed for clean redemption. If multiple target outcomes are selected during share migration, the holder’s source entitlement remains and its unmaterialized balance is minted into each selected child.

When a market ends, Statoblast attempts to resolve its outcome by running an Escalation Game based on The Isonzo Front. Participants escrow vault-backed REP behind Invalid, Yes, or No. Each deposit adds to that outcome's cumulative balance; it does not have to outbid the previous deposit or the current leader. The accepted deposit must normally meet the game's starting bond, unless it fills the selected outcome to the non-decision threshold.

The running escalation cost increases with elapsed time, and the median outcome balance determines the scheduled end. After that deadline, a strict balance leader resolves the question. If two outcomes instead reach the non-decision threshold, the game enters local non-decision and Statoblast proceeds to its fork-resolution path. The sections below derive those rules and their economic consequences.

Security assumptions: A01 risk-adjusted incentives, A02 viable operating costs, A10 timely outcome evidence, A03 independent participants, A04 early alarm capital, A13 REP liquidity, A16 timely inclusion, and A06 lifecycle executors.

SecurityPoolFactory requires its configured initialEscalationGameDeposit to be at least 1 REP, copies that value into every deployed SecurityPool, and admits a new origin pool only while its live non-decision threshold exceeds the configured bond. An existing pool can outlive that relationship because REP burns reduce the tracked theoretical supply. On the first post-end deposit, the SecurityPool passes its stored bond and the current threshold to EscalationGameFactory. That game factory preserves the bond when possible and otherwise substitutes nonDecisionThreshold - 1. Positive atomic-unit bonds below one whole REP remain valid; a threshold of one atomic unit or less has no positive smaller bond and cannot initialize a game.

• requiredEscalationCost(0) = startingBondAmount.
• requiredEscalationCost(fullEscalationInterval) = nonDecisionThresholdAmount.
• The cost rises monotonically between those endpoints.

The plot below is an illustrative normalized instance with ln(nonDecisionThreshold / startingBond) = 2.4. It uses the parameterized curve implemented by totalCost() and computeIterativeAttritionCost: early deposits face the starting bond, while sustained late disagreement approaches the non-decision threshold. The plotted curve is the continuous model; Solidity computes it with fixed-point integer approximation using SCALE = 1e6 and clamps the endpoints. Ratio normalization extracts whole powers of two before approximating the residual logarithm, including exact power-of-two ratios whose residual is zero.

Escalation deposits enter through SecurityPool.depositToEscalationGame. The first valid deposit after question end deploys the game, sets activationTime = block.timestamp + 3 days, and records the game’s starting parameters. Later deposits can continue only while the pool is operational, the game has resumed if it came from a fork continuation, and the child pool is not still waiting for continuation processing.

The security pool wrapper first previews the accepted amount, then removes the corresponding vault REP ownership with round-up accounting, checks the vault and pool remain solvent, enforces the minimum remaining REP rule, and transfers REP into the escalation game from the caller's existing vault position rather than from free-floating wallet REP. If the pool has any active security-bond allowance, the call also requires a fresh REP/ETH oracle price before the deposit can proceed. Inside the game, the proposed amount must be at least startBond. The recorded amount must be positive and either at least startBond or exactly fill the selected outcome to nonDecisionThreshold.

The game rejects invalid targets, full outcomes, and post-non-decision deposits. Accepted deposits are clipped to the selected outcome's remaining room, and the game applies a small tie-avoidance adjustment when a below-threshold deposit would otherwise make two outcomes share the maximum balance.

Escalation Deposit Trace

The contract exposes both directions of this curve: it can compute the required cost from elapsed time, and it can derive the effective end time from the final binding capital. Before activation, totalCost() is zero. In fork-continuation games, elapsed time can be inherited from a parent game and then resume later instead of restarting from zero.

Payouts depend on final binding capital, the median of the three outcome balances. Winning capital inside the reward-eligible window shares a fixed reward pool; excess winning capital receives principal only.

If time expires without non-decision, the resolution ordering in the interactive example above applies. A local deposit that brings a second outcome to nonDecisionThreshold records nonDecisionState = Local and nonDecisionTimestamp, then makes the game-local canTriggerOwnFork() predicate true. That predicate does not override pool finality: a pool with an inherited fixed outcome rejects new depositToEscalationGame calls before they can create a local non-decision and still rejects activateForkMode(). A fork continuation instead records nonDecisionState = InheritedThresholdTie when its preserved balances already meet that condition, without rebasing balances or fabricating a local timestamp. Both explicit states close further deposits. A continuation with a fixed child outcome follows its remaining clock and settles to that outcome; one without a fixed outcome can open its own fork directly.

For the exact resolution ordering, empty-game fallback, deposit clipping, carry batching, and residual sweep rules, see Escalation Resolution and Deposits.

The median matters because the game is trying to detect whether disagreement remains live across multiple sides, not merely whether one side has accumulated the most stake. binding capital measures the level at which the contest is still jointly sustained by competing outcomes, which is why it drives timeout and payout logic.

• The binding-capital region defines a fixed reward pool.
• 40% of that binding-capital region is the winner haircut, so the remaining 60% becomes the reward pool.
• The reward-eligible cap is bindingCapitalAmount + ⌊bindingCapitalAmount / EXCESS_REWARD_WINDOW_DIVISOR⌋.
• The region between binding capital and that cap is the safety boundary.
• Winning capital above the reward-eligible cap is excess and receives principal only.

Settlement uses different calls for local withdrawal, own-fork direct claims, optional parent-lock cleanup, and child proof claims. The distinction matters because local withdrawal settles deposit indexes, while continuation games settle inherited winners by proof and retire inherited losers without a call.

Escalation Settlement Call Matrix

The pool removes ownership and escrows REP when the user deposits into the local game. Settlement does not re-mint that ownership: a winner receives the ordinary winning payout as wallet REP, while a losing settlement clears escrow without a payout. An own-fork direct claim uses the same winning reward math and releases pre-funded child REP from the selected child's aggregate backing to the vault owner's wallet. It is not a claim-time conversion and does not mint child-pool ownership. Own-fork direct claims must still be submitted before the parent migration window closes.

Caller permissions are intentionally mixed. withdrawFromEscalationGame and withdrawForkedEscalationDeposits are liveness helpers that any caller can submit so long as every proof or deposit index in the batch belongs to the same beneficiary vault. By contrast, claimForkedEscalationDeposits and the optional migrateVaultWithUnresolvedEscalation cleanup require msg.sender to be the affected vault.

External Zoltar forks interrupt the escalation game. This is called continuation. The canonical continuation lifecycle lives in Forks and Migration. This section only distinguishes the settlement entry points and their caller permissions.

Continuation claims use Merkle Mountain Range proofs and nullifier roots. The canonical leaf fields, peak ordering, proof lengths, and replay rules are documented in Merkle Mountain Range carry proofs.

Fork handling spans both layers. Zoltar creates child universes and handles REP splitting. Statoblast separately moves vault state, proportional collateral, and share positions into child pools, while child creation reproduces unresolved escalation state from one canonical snapshot and aggregate backing transfer.

The child-pool selector comes from the universe’s fork question, not from Statoblast’s binary market shape. A binary Statoblast pool can therefore spawn child pools keyed to scalar encodings or multi-way categorical outcomes when the universe fork used a different Zoltar question.

As described by Zoltar's global-question rules, the consequence is universe-wide: an eligible Zoltar fork stops or redirects parent flows for every pool using that universe, even when the fork question is unrelated to a pool.

Security assumptions: A07 fork value preservation, A09 truthful-branch preference, A10 timely outcome evidence, A11 practical migration, A05 lineage access value, A16 timely inclusion, A06 lifecycle executors, and A20 chain-data availability.

SystemState is primarily a fork-and-migration state machine, not a generic question-resolution state machine. A pool finalized before a late, unrelated universe fork can retain SystemState.Operational. Its isOperational-guarded activity still freezes because that modifier separately checks the universe fork time, while finalized share, REP, and eligible escalation-deposit redemption paths that check only the stored state remain callable.

• The parent pool enters fork mode.
• Anyone can call createChildUniverse to deploy a child pool for a valid fork outcome.
• Vault owners can call migrateVault to move their own unlocked pool ownership, allowance, fees, and collateral whether or not unresolved external-fork escalation locks exist. Parent-lock cleanup remains a separate optional concern.
• A forked unresolved game initializes each selected child with one canonical carry snapshot and one aggregate backing transfer. Unrelated forks carry the game REP 1:1; the escalation's own fork carries it after the single winner haircut. No vault migration call is required to fund or authorize claims.
• After final resolution, anyone may relay winning inherited proofs; the authenticated depositor is paid. Inherited losers need no proof calls, while local losing deposits retain ordinary settlement.
• Parent-lock cleanup is optional and vault-scoped; the operator cleanup reference owns wrapper ordering and constant-size export details.
• Vault owners claim winning own-fork escalation deposits through claimForkedEscalationDeposits; the own-fork path is open only during the parent migration window. A successful direct claim invalidates that stable deposit identity in every current and future child continuation.
• Parent collateral is partially transferred into child pools in proportion to migrated REP.
• Shares migrate independently through ShareToken.migrate.

REP migration and share migration intentionally reproduce a source position into every selected child branch. A share source remains as a transfer-locked entitlement after first use, and each child balance is colored by a distinct universe, so this is not a same-universe double claim. Integrations must nevertheless keep branch balance sheets separate: summing child REP or shares as though all branches were simultaneously redeemable in one economic universe overstates capital.

The migration API is not a single generic “fork migrator” role. Child creation is permissionless, migrateVault always acts on the caller’s own vault, and the unresolved-escalation and own-fork-claim entry points require the affected vault as caller. This matters for off-chain automation because a keeper can help with liveness, but it cannot migrate or claim another vault’s locked REP.

Fork Migration Contract Trace

Migration Proxy Identity

Statoblast does not send every pool migration call to Zoltar directly from the forker. Instead, SecurityPoolForker lazily deploys one deterministic SecurityPoolMigrationProxy per parent pool. That proxy is the stable msg.sender for Zoltar's migration ledger, so one parent pool has one predictable migration identity across lockRep, forkUniverse, splitToChild, and child REP sweeping.

The address is predictable, but prefunding it does not create pool migration credit. Fork accounting measures REP newly routed through the proxy and Zoltar’s migration ledger; any ERC-20 balance already at the address remains isolated surplus and is not swept into a child on the pool’s behalf.

During vault migration, the forker also ensures the child pool is backed by enough child-universe REP for the cumulative migrated REP credited to that child. It tracks how much REP has already been split for each parent-pool/outcome pair and only splits the shortfall before sweeping child REP into the child pool. The migration-proxy and child-backing guardrails are collected in Fork Migration .

The equation above gives the provisional ownership proportion. The forker also tracks cumulative migrated parent ownership independently for every child. When that cumulative value reaches the complete parent denominator, the final migration receives every REP unit left in the fork bucket. Both external and own-fork transfers use one fixed, fee-exclusive fork snapshot plus cumulative ceiling accounting, so complete ownership migration transfers the complete REP and collateral snapshots without manufacturing an auction shortfall from individual REP rounding. An external fork is already known when activateForkMode checkpoints and records that snapshot. The own-fork snapshot uses this order: activateForkMode changes the pool state and checkpoints through the pre-fork fee horizon; the proxy creates the universe fork; a fork-time checkpoint covers the newly exposed question-end-to-fork interval at the retained operational rate; then collateralAtFork records the resulting fee-exclusive collateral in the fork-neutral snapshot shared by both paths. Truth-auction repair subtracts the child's actual cumulative routed collateral from that snapshot to set the missing collateral as its ETH raise target; actual repair still depends on auction demand, clearing, and tick-level integer rounding. Before either migration path clears the parent allowance, it also checkpoints the vault's earned fees. Each ETH transfer subtracts from parent complete-set collateral and is limited to the pool balance above totalAccruedFees(), keeping both the unallocated reserve and assigned vault debt funded in the parent.

Own-fork migration has one extra accounting split. The pool and its active escalation game both contribute REP to the fork, but the child-universe REP returning from Zoltar is a single auctionable migration balance. Statoblast splits that balance into a vault bucket and an escalation bucket before child migration resumes.

When a pool forks while its escalation game is unresolved, the parent forker snapshots the unresolved game’s startBond, nonDecisionThreshold, elapsed escalation time, actual per-outcome balances, carry totals, peaks, leaf counts, and nullifier roots. External unrelated forks reserve the drained game's complete REP at 1:1. The escalation's own fork reserves it after the winner haircut has been paid through Zoltar. Each selected child pool can initialize its own paused fork-continuation escalation game from that canonical snapshot and receives the complete aggregate game backing once. The continuation preserves the parent live Invalid, Yes, and No balances, each unresolved deposit’s original outcome, stable parent deposit index, and payout ordering. The authenticated winning proof is the claim authorization; it pays the recorded depositor directly from aggregate backing without a preceding vault migration.

The continuation game remains paused during the migration window so child deployment and vault migration do not silently consume escalation time. While the child pool is waiting for continuation processing, SecurityPool.depositToEscalationGame rejects new live child deposits through the awaitingForkContinuation guard. Operational activation clears that guard without waiting for parent-vault transactions. Before the remaining clock can start, resumeFromFork verifies aggregate REP funding. An unrelated fork must cover effective unresolved principal one-to-one. When the escalation's own fork already paid the winner haircut through Zoltar, its recorded initial backing must cover at least sourcePrincipalAtFork - ⌊sourcePrincipalAtFork / 5⌋. The game's live balance must cover that initial backing minus child REP already exported by valid direct claims before resume. An underfunded child therefore remains paused instead of reaching a resolution it cannot pay. An inactive vault cannot make other users pay to process its position or delay a fully funded child continuation.

In that formula, sourcePrincipalAtFork is the aggregate raw unresolved principal installed in the continuation's fork snapshot: the sum across outcomes of stored inheritedUnresolvedTotal and localUnresolvedTotal before effective direct-claim deductions. It is not the post-claim effective carry total or the child game's current REP balance.

1. The parent pool forks, stores canonical unresolved escalation state, and locks the game's aggregate physical REP once.
2. Each selected child pool is created in a child universe and marks itself as awaiting fork continuation.
3. Each created child initializes a paused continuation escalation game from that snapshot and receives the full aggregate escalation backing once.
4. After the migration window and any required truth auction, the child pool becomes operational, clears the wait marker, and resumes the paused continuation game only after its aggregate REP funding check passes.

A continuation pool can fork again only when it has no inherited fixed outcome. Within that pool-level boundary, its game can become eligible by inheriting a threshold tie at snapshot initialization or by recording a local non-decision after resuming. The game-local canTriggerOwnFork() predicate returns true for a local non-decision, but it does not bypass the pool's fixed-outcome guard. When both levels are eligible, the forker stores the game's current balances, carry totals, peaks, leaf counts, and current nullifier roots after any prior proof consumption. It drains and locks the remaining aggregate REP once. Each selected grandchild receives that same canonical snapshot and full remaining backing once; winning proofs remain their own authorization. Escalation can therefore branch recursively with Zoltar universes without replaying spent proofs or requiring other vaults to migrate. Before consuming a carried proof, the forker derives a stable global deposit id as keccak256(abi.encode(securityPoolFactory, originId, uint8(outcomeIndex), parentDepositIndex)). A direct claim recorded anywhere in that factory-scoped origin lineage therefore blocks the corresponding descendant proof with one mapping lookup.

Recursive continuation adds another descendant branch to the migration lifecycle described here. The normative recursive-fork gas-bound requirement, current enforcement status, and evidence are maintained in EXT-05. Total historical data and offchain proof coordination can still grow as more forks occur.

For example, suppose Zoltar has two ended questions: “Did London record a temperature of at least 30 °C on August 1, 2030?” and “Did the Atlas protocol upgrade activate by July 1, 2031?” A security pool in the Genesis universe is still escalating the London-temperature question. Before that escalation resolves, a caller invokes Zoltar.forkUniverse with the unrelated, already ended Atlas-upgrade question, causing Zoltar to fork the Genesis universe. Each resulting child universe represents one possible answer to the Atlas-upgrade question. The pool's unresolved London-temperature escalation migrates into selected child universes as separate paused continuation games, one in each selected child universe. After a continuation resumes, it still disputes the London-temperature question. Because the unrelated fork did not give the continuation pool a fixed outcome, an inherited threshold tie or a later local non-decision lets a caller invoke the security-pool fork path, causing Zoltar to fork that child universe again. The first fork therefore creates branches for the possible answers to the unrelated Atlas-upgrade question; the recursive fork creates branches for the possible answers to the pool's original London-temperature question.

The inherited-carry baseline is implemented with Merkle Mountain Range peaks and nullifier roots so a child game can consume proofs without replaying already-spent parent deposits. New child deposits are tracked separately as local carry. Proof settlement is per requested winning leaf, not a depositor-wide loop. Immutable peaks and leaves remain the proof commitment even if separate parent cleanup occurs.

A carried proof's source principal authenticates the leaf and decrements inherited unresolved principal. Normal winning-payout math then pays from the aggregate child backing, so a reward may exceed the proof principal without per-vault scaling. Direct parent claims reduce effective inherited principal by outcome and remain blocked from a second payout in every descendant. Once the final winner's proofs are consumed, inherited losers have retired, local deposits are settled, and no local escrow remains, residual REP can be swept back to the security pool.

Recursive Continuation Example

Child Outcome Resolution

Child pools resolve outcomes through the forker. When the parent universe forks on the pool's question, each child stores its selected Zoltar outcome index as the fixed result, whether the fork began through the pool-specific path or a direct Zoltar call. The pool stores and reports that result from child creation, and it is final for that pool. Pool asset redemptions begin after the child becomes operational. When a continuation game exists, it uses the same result for carried-deposit settlement only after its remaining continuation deadline. Later universe forks cannot transition a pool with an inherited fixed result, even when they reuse the pool question. A child created by an unrelated fork without an inherited fixed result uses a local escalation result only if that escalation ended before the universe forked; otherwise it remains unresolved until continuation or later state produces an outcome. The ownFork flag changes accounting, not question semantics.

This finality is also a collateral-accounting boundary. Winning-share redemption burns only the fixed winning token and reduces the pool's remaining economic claim supply. A later fork must not reclassify a surviving sibling outcome token as winning against that reduced denominator.

The same boundary closes new local escalation deposits. A fixed-outcome pool cannot use another fork to export a local non-decision, while local settlement rejects deposits after non-decision. Accepting new REP in that state would therefore lock the depositor's vault ownership and block REP redemption. Carried winning proofs from the parent continuation remain claimable through their separate withdrawal path.

Security assumptions: A01 bidder incentives, A02 viable operating costs, A03 independent demand, A12 efficient REP conversion, A13 REP liquidity, A16 timely inclusion, A06 lifecycle executors, A20 bid-data availability, A25 safe immutable parameters, and A22 native-ETH recipient compatibility.

After the parent migration window ends, a child pool may still hold less ETH than users need for clean redemption. The truth auction sells child-universe REP for ETH to repair that gap, subject to both an ETH raise cap and a maximum REP sale cap.

The repair target is the contract’s direct statement of the collateral gap: parentCollateralAtFork minus forkCollateralReceived, floored at zero. The received counter records actual cumulative-ceiling transfers after the parent’s available-collateral cap, so nominal migrated REP cannot overstate child funding. The auction start gate is tied to the parent pool’s fork timestamp plus the eight-week migration window, not to any child-universe fork time. If migrated REP has reached the pool-auctionable baseline, or if that baseline is zero, the child pool can finalize this phase without running the division path or selling REP. For an own fork that baseline is vaultRepAtFork; for an external fork it is auctionableRepAtFork.

The REP sale cap is deliberately not just “all remaining REP.” The forker computes the auctionable pool REP baseline, subtracts a tiny floor-rounded haircut tied to the REP that already migrated, and gives the auction that maximum inventory. For an own fork, poolAuctionableRepAtFork means only the vault REP bucket, so the separate own-fork escalation REP bucket is not sold in the truth auction. For an external fork, it means the parent pool’s full auctionable REP at fork.

The forker tracks collateral received through migration and the auction separately from the child contract's raw ETH balance. ETH forced into the child does not count toward the repair target. After the deadline, value-free finalization activates the child with migrated collateral plus accepted auction ETH and releases every bid to settlement. Nonzero finalizer ETH is rejected.

Auction winners become the responsible child-pool owners only when their claims attach ownership and allowance to bidder vaults. Recipient behavior cannot roll back that accounting transition. The Truth Auction settlement specification owns the exact zero-migration ownership conversion, allowance activation, and failed-refund recovery rules.

Clearing and Settlement

The Truth Auction design owns tick pricing, cap selection, underfunded qualification, and the interactive examples; its settlement section owns allocation rounding and recovery behavior. The security model separately states efficient REP-to-ETH auction conversion as an explicit assumption.

Security assumptions: A01 arbitrage incentives, A02 viable operating costs, A13 REP liquidity, A16 timely inclusion, A17 corrector capability, A18 independent correction incentive, A19 observable correctable price, A06 settlement executors, and A20 report-state availability.

The REP/ETH oracle is narrow in purpose. OpenOraclePriceCoordinator uses OpenOracle to obtain a fresh REP/ETH price for liquidation, REP withdrawal, and bond-allowance updates. A stale price also blocks depositToEscalationGame whenever the pool still has active security-bond allowance. It is not the oracle for question truth; escalation and, if necessary, Zoltar forks handle that path.

The OpenOracle path is contestable before the coordinator can use it: the sponsor funds the request, the coordinator atomically posts the initial token amounts and becomes the onchain reporter, disputers can replace a bad report with the contract-required replacement amounts strictly before the settlement deadline, and a settler can finalize the report at or after that deadline. OpenOracle credits the final position to the final reporter. Its callback supplies the accepted amounts to the coordinator, which withdraws only its own internal WETH/REP balances back to the sponsor. Request, dispute, settlement, callback safety, and recovery details are maintained in the dedicated OpenOracle integration guide.

If the last price is stale, solvency-sensitive operations can be queued until a valid report is settled. The coordinator then replays the pending operation against the fresh price. Escalation deposits are the exception: they require a fresh price when bond allowance is outstanding, but they revert instead of entering the staged callback queue. This price path is only for security backing against ETH collateral.

The Protocol Security Model defines assumptions A01–A28 and the guarantees deliberately excluded from the protocol model.

Primary economic assumptions: A07 fork value preservation, A08 REP valuation, A09 truthful-branch preference, A12 truth-auction demand, A14 REP economic backing, and A05 lineage access value.

• REP backing must remain economically meaningful relative to the obligations it secures.
• Profitable oracle corrections must receive timely inclusion; this is an assumption, not an onchain guarantee.
• Truth-auction demand may be insufficient, in which case the child activates with the collateral actually migrated and raised.
• Usable value depends on users and capital coordinating on the child branches they continue to support.

Zoltar creates child universes, while Statoblast carries underwriting state, collateral accounting, and outcome-share claims into child pools. REP migration, proportional collateral migration, and truth-auction repair can rebuild usable market state, but none of those mechanisms independently identifies truth or guarantees full collateral repair.

Security assumption: A25 safe immutable parameters.

• Origin security pools currently support the exact categorical market shape Yes / No, with Invalid added as the third trading and resolution outcome.
• Statoblast issues transferable shares and manages redemption and migration, but does not provide secondary-market trading.
• Zoltar fork economics are constructor-configured.
• Retention-rate bounds and several oracle and auction parameters are fixed constants in the current implementation.
• The retention-rate curve in SecurityPoolUtils is heuristic rather than final market design.