Augur Placeholder White Paper

Augur Placeholder is the market layer built on top of Zoltar. It creates one security pool per question, lets traders mint and redeem ETH-backed shares, lets REP vaults provide underwriting, and tries to settle disputes locally before asking Zoltar to fork.

If a fork does happen, Placeholder migrates the market into child pools and can repair missing child-pool ETH collateral through a truth auction. Despite the name, that auction repairs collateral; it does not choose the truthful branch.

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

Placeholder's lifecycle starts by creating one pool for one question, letting traders and REP vaults use that pool, trying to resolve disputes locally, and only then turning to fork and collateral-repair machinery. The overview sequence below follows that same order.

Placeholder also depends on two different oracle paths that answer different questions. Zoltar represents unresolved market-truth disputes by creating child universes. OpenOracle supplies only a bounded REP/ETH solvency price for withdrawals, allowance updates, and liquidations.

1. A question is registered in Zoltar and a Placeholder 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 fails and the system reaches non-decision, Zoltar forks and Placeholder migrates pool state into child universes.
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

Placeholder 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.

• Question creators register questions in Zoltar question data, creating the objects around which Placeholder 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.
• Users mint complete sets with ETH and hold outcome shares.
• 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, eligible escalation positions, and shares across child universes after a Zoltar fork; some settlement helpers are permissionless.
• 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.

A SecurityPool is the central Placeholder contract for one question in one universe. Vault operators deposit REP, choose bond allowance, and underwrite ETH-backed complete sets.

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 Placeholder 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 also deterministic. Origin-pool deployment salts include the zero parent address, universe id, question id, and securityMultiplier; child-pool salts include the parent pool address as well. The share token uses a separate salt based on securityMultiplier and question id so the share-token address stays stable across forked child pools for the same market shape.

The next equations compare REP backing with ETH-denominated obligations. This price is a price-oracle value, not a truth outcome. OpenOracle settles REP/WETH amounts, and the coordinator stores the result as scaled REP per ETH because solvency checks compare REP backing against ETH obligations.

The contract applies related conditions at both the vault level and the whole-pool level before allowing operations such as performWithdrawRep, performLiquidation, and performSetSecurityBondsAllowance.

Users and Complete Sets

Users call createCompleteSet with ETH. The pool mints one Invalid, one Yes, and one No ERC-1155 share through ShareToken for the current universe. The deposited ETH becomes completeSetCollateralAmount.

• While the pool is operational, a full complete set can be burned with redeemCompleteSet to recover its pro rata share of collateral.
• After the fork route finalizes an outcome, users can redeem winning outcome shares through redeemShares.
• Minting checks the next collateral amount against available bond capacity before minting shares, then updates pool accounting before the share-token mint call.

Fee Extraction and Retention Rate

Complete-set collateral gradually decays into fees owed to vaults. 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 starts lower and grows over time.
• 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. The Retention Rate Curve figure shows the same shape as the contract.

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 plotted line below follows the same annualization the UI uses: annualFee = 1 - (retentionRate / PRICE_PRECISION)^SECONDS_PER_YEAR.

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 also no-op when total bond allowance is zero or when the pool is outside Operational mode, so fork handling does not silently change the live fee curve.

Solvency Operations and Liquidation

REP withdrawal, liquidation, and bond-allowance updates depend on a valid REP/ETH price. Withdrawal and allowance changes check backing against allowance, while liquidation applies the stronger securityMultiplier-adjusted liquidability condition.

Liquidation is a punitive vault-to-vault transfer: debt moves to the caller vault, and unlocked target REP moves to that caller at the liquidation bonus. When a vault becomes undercollateralized, another vault can call performLiquidation through the queued-oracle path. The contract snapshots the target vault’s state at queue time and uses that snapshot when the operation executes, so later target-vault manipulation cannot trivially invalidate the liquidation attempt. The queued liquidation executes only if the fresh current REP/ETH price is strictly above the computed threshold and far enough beyond it to satisfy the configured minLiquidationPriceDistanceBps liquidation distance check.

Economically, liquidation is punitive: the liquidator vault absorbs target debt and receives unlocked target REP at a fixed five-percent bonus over the debt chunk’s REP market value. That punishes the target and rewards the liquidator, while the securityMultiplier still makes the target healthier as long as required backing falls faster than seized REP.

The purpose is therefore threefold: punish the liquidated vault, reward the liquidator, and move the system into a healthier state. The first two effects are direct REP transfers; the third comes from the strict health-improvement guard that rejects chunks whose rounding would fail to reduce the target shortfall. Healthier means the target shortfall shrinks and the moved debt lands only on a caller vault that remains non-liquidatable under the securityMultiplier-adjusted collateral threshold; liquidation redistributes REP and allowance rather than increasing aggregate backing.

Snapshot sizing, REP-seizure math, the strict health-improvement guard debtToMove * securityMultiplier * currentRepPerEthPrice > repToMove * PRICE_PRECISION, target/caller dust floors, and repeated-liquidation edge cases define the liquidation execution envelope; Liquidation Design derives that flow in full.

Implementation guardrails for withdrawal locks, external-fork locks, liquidation snapshots, direct ETH receiver restrictions, fee clamps, and complete-set minting order are in Security Pool Guardrails .

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.

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

• The selected target list must be non-empty.
• The caller must hold a positive balance of the parent token id.
• The entire parent token balance is burned; callers cannot migrate only part of that token id.
• Target outcomes must be valid for the fork question and strictly increasing, which prevents duplicate child mints in one call.

At the implementation level, redeemShares burns the holder’s full balance of the winning token id and pays sharesToCash(amount) out of the pool’s current collateral accounting. 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 full burned balance is reproduced into each selected child universe.

Placeholder tries local resolution before asking Zoltar to fork. Vault operators move REP out of their security-pool position and behind Invalid, Yes, or No. The required attrition cost rises from the starting bond to the non-decision threshold over seven weeks after a three-day activation delay.

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

The plot below is the same curve used 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.

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 the stronger non-decision condition, the local resolution helper first checks whether two or more outcomes still meet the running cost. If not and all three balances are zero, it falls back to Invalid. Otherwise, a strict leading outcome wins. Valid deposits prevent tied maxima below non-decision by reducing the accepted amount by one atomic REP unit, or reverting if that adjusted amount becomes invalid. Continuation snapshots reject preserved positive tied maxima below nonDecisionThreshold. Ties already at the fixed nonDecisionThreshold, or all-zero preserved balances, remain valid carried states. A local deposit that brings a second outcome to nonDecisionThreshold records nonDecisionTimestamp and opens the fork path. A fork continuation can instead inherit a threshold tie without rebasing balances or recording a new timestamp during snapshot initialization.

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 burned or retained, so the remaining 60% becomes the reward pool.
• The reward-eligible cap is bindingCapitalAmount + floor(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.

If the actual Zoltar fork threshold for the universe is lower than the escalation game’s configured nonDecisionThreshold, the payout is scaled down by actualForkThreshold / nonDecisionThreshold.

Settlement uses different calls for local games, own-fork claims, external-fork migration, and child continuation games. The distinction matters because some paths settle local deposit indexes, while continuation games settle inherited parent deposits by proof.

Escalation Settlement Call Matrix

Local withdrawals adjust the vault's parent-pool ownership by the gain or loss relative to the original locked REP. Own-fork claims instead convert source REP into child-universe REP and pay it to the vault owner’s wallet, rather than minting child-pool ownership. In the own-fork path, those 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 migrateVaultWithUnresolvedEscalation require msg.sender to be the affected vault.

Continuation withdrawals use Merkle Mountain Range proofs against the inherited carry snapshot. Each accepted proof advances the nullifier root, so a carried parent deposit cannot be replayed in the child.

If an unrelated external Zoltar fork interrupts the local escalation game before it resolves, unresolved escalation deposits stop being withdrawable on the parent pool. The vault owner must migrate all remaining unresolved parent locks for the chosen child universe through repeated migrateVaultWithUnresolvedEscalation calls until the function reports no more work. Each call pages only a bounded chunk of unresolved export data, so large carry sets can require multiple transactions. If the vault does not migrate in time, the unresolved position remains locked in the parent escalation game and is no longer withdrawable from the parent pool.

Unresolved Escalation Migration Trace

Fork handling spans both layers. Zoltar creates child universes and handles REP splitting. Placeholder separately moves vault state, eligible escalation-game positions, proportional collateral, and share positions into child pools.

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

SystemState is primarily a fork-and-migration state machine, not a generic question-resolution state machine.

• The parent pool enters fork mode.
• Anyone can call createChildUniverse to deploy a child pool for a valid fork outcome.
• Vault owners call migrateVault to move their own pool ownership and bond allowance when they do not have unresolved external-fork escalation locks.
• Vault owners with unresolved external-fork escalation locks call migrateVaultWithUnresolvedEscalation, which can require multiple calls before it returns that migration is complete.
• Vault owners claim winning own-fork escalation deposits through claimForkedEscalationDeposits; the own-fork path is open only during the parent migration window.
• Parent collateral is partially transferred into child pools in proportion to migrated REP.
• Shares migrate independently through ShareToken.migrate.

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

Placeholder 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.

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 is the external-fork unlocked transfer path. In an own-fork migration, child collateral uses cumulative ceiling accounting so repeated vault migrations do not strand collateral because each individual transfer rounded down.

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. Placeholder 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, and per-outcome carry state. Each relevant child pool can initialize its own paused fork-continuation escalation game from that snapshot. The continuation preserves the parent live Invalid, Yes, and No balances, each unresolved deposit’s original outcome, stable parent deposit index, payout ordering, and the remaining REP backing that still needs to arrive through forked escrow. Forked escrow then tracks how much child REP backing has arrived for those inherited unresolved deposits without rebasing the preserved live balances.

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.

1. The parent pool forks and snapshots unresolved escalation state.
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.
4. Affected vaults migrate unresolved parent locks through migrateVaultWithUnresolvedEscalation; large carry sets can require multiple calls.
5. After the migration window and any required truth auction, the child pool becomes operational, clears the wait marker, and resumes the paused continuation game.

A continuation game can later reach non-decision too. When that happens, it exports a materialized carry snapshot made from inherited unresolved deposits plus new local deposits placed after resume. That snapshot can seed another set of child continuation games, so escalation does not end at a single fork; it can branch recursively along with Zoltar universes.

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, and local unresolved export work is paged in batches of at most 64 refs per vault. This is why large unresolved carry sets can require multiple migration calls.

Forked escrow records both source-principal amounts and converted child REP by original outcome. The scaling path applies only when a claim has positive source principal and a forked-escrow record exists. If inherited carry requires forked escrow, missing escrow blocks settlement. A zero-source, zero-child escrow record is a no-op; recorded escrow with zero child REP can settle a positive proof for zero child REP. Once a game is final, all unresolved principal is cleared, and no escrow remains, any residual REP still sitting in the escalation game can be swept back to the security pool.

Recursive Continuation Example

Child Outcome Resolution

Child pools resolve outcomes through the forker. In an own-fork child, the child's outcome is fixed by the child's Zoltar outcome index. In an external-fork child, a local escalation result is used only if that escalation ended before the universe forked; otherwise the child remains unresolved until its own continuation or later state produces an outcome.

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 after proportional REP migration. 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.

Auction Mechanics

• Tick 0 means 1 ETH/REP.
• Positive ticks mean a higher ETH-per-REP bid.
• Negative ticks mean a lower ETH-per-REP bid.

The auction intentionally has no total bid cap and no active-tick cap. Instead, it stores aggregate ETH by tick in an AVL tree. The tick range is finite (-524288 through 524288), so even a tree containing every possible tick has bounded height. Finalization descends aggregate tree paths and does not scan every bid; individual bid settlement is paged later. Bidding, refund, finalization, and settlement guardrails are collected in Truth Auction Operations .

For the underfunded threshold row below, underfundedWinningEth is the finalized winning ETH kept after the winning prefix is fixed and ticks below clearingTick are excluded for refund. If underfundedWinningEth > 0, the contract computes the synthetic threshold from that winning ETH and allocates the full REP cap across ticks >= clearingTick. If no winning prefix exists, underfundedThreshold is stored as type(uint256).max, totalRepPurchased remains zero, and every bid refunds. The contract still records aggregate submitted ethRaised, but the underfunded threshold and uniform winner allocation both use underfundedWinningEth when it is non-zero.

In normal clearing, bids above the clearing tick win in full, bids below it lose, and bids at the clearing tick are filled in submission order. In the underfunded path, ticks at or above the finalized clearingTick boundary share the full REP sale cap pro rata by winning ETH contribution.

Both finalized paths carry division dust across paged withdrawals. Normal clearing carries clearingRemainder through the uniform-price ETH-to-REP division, and underfunded clearing reuses that same remainder while dividing the full REP cap across winning ETH, so bid-level withdrawals reconcile to the aggregate finalized REP allocation.

Settlement then turns purchased REP into child-pool vault accounting. The filled REP amount becomes pool ownership at the auction-specific auctionPoolOwnershipPerRep rate set during auction finalization. Any security-bond allowance left behind by parent vaults is assigned to auction buyers pro rata by purchased REP, with the final settlement claim taking the remainder left by integer division.

• startAuction sets ethRaiseCap, the ETH repair target.
• startAuction also sets maxRepBeingSold, the maximum REP inventory the child pool will sell.
• The direct startAuction and finalize calls are owner-only. Anyone can reach those steps through SecurityPoolForker.startTruthAuction and SecurityPoolForker.finalizeTruthAuction.
• Bids are accepted only after start, before finalization, and before auctionStarted + 1 week.
• Finalization walks aggregate AVL tick totals from the highest ETH/REP tick to the lowest; raw bids are settled later through paged withdrawals.
• The sweep stops when the ETH raise cap binds or when the ETH collected so far, at that price, would buy at or beyond the REP sale cap. Because ticks and Solidity division are discrete, the final purchased REP can land at or just below that cap.
• In an underfunded auction, the contract computes $\mathrm{underfundedThreshold}=\{\begin{array}{cc}\mathrm{ceil}\left(\frac{\mathrm{underfundedWinningEth}\cdot \mathrm{PRICE\_PRECISION}}{\mathrm{maxRepBeingSold}}\right)& \text{if underfundedWinningEth > 0}\\ \text{type(uint256).max}& \text{otherwise}\end{array}$, where underfundedWinningEth is the finalized ETH kept after the winning prefix is fixed and losing bids are refunded.
• When underfundedWinningEth > 0, the stored clearingTick marks the lowest winning tick. Underfunded winners are bids at ticks >= clearingTick, and those winners share the full REP cap pro rata by ETH at the synthetic underfundedThreshold price. If no winning prefix exists, the contract stores type(uint256).max, totalRepPurchased stays zero, and every bid refunds.
• Normal clearing carries division dust through clearingRemainder; underfunded clearing reuses that remainder while dividing the full REP cap across winning ETH.
• Before finalization, losing bids below the currently found clearing tick can be refunded in paged batches.
• After finalization, only the owner withdraws bid outcomes from the auction; SecurityPoolForker wraps that call so anyone can settle a vault's bid pages.

The Binding condition output reports one of four outcomes: ETH cap, REP cap, both caps, or underfunded. The same bid ladder shows how ETH-cap uniform clearing, REP-cap uniform clearing, both-cap clearing, and weak-demand outcomes clear.

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; that path is handled by escalation and, if necessary, Zoltar forks.

The OpenOracle path is contestable before the coordinator can use it: the coordinator requests a REP/WETH report, a reporter posts token amounts, disputers can replace a bad report with a larger one, a settler finalizes the report after the timing window, and the settlement callback returns the final amounts to the coordinator. Request, dispute, settlement, and callback safety checks are detailed 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.

When the coordinator accepts a settled REP/ETH price, that price is reusable only inside its freshness window. It does not authorize a fixed amount of operation exposure. The initial OpenOracle report is instead sized from dispute profitability assumptions so a wrong report at the target error is profitable to challenge.

Oracle-Staged Operation Trace

When no fresh price is available, the caller funds the OpenOracle request bounty. The coordinator sizes that ETH cost from the current base fee, the callback gas limit, and the configured gas budget for reporting the price.

While a report remains pending, only the original pending report sponsor can queue more staged operations against that settlement. Those follow-up queues pay no extra ETH join fee; other callers must wait until the pending report settles before they can stage their own operations.

Staged operations also need an expiry because they are caller-authorized actions, not permanent permissions. A delayed callback should not execute an old withdrawal, allowance change, or liquidation after the caller-selected validity window has passed.

The initial report equation below names the configured REP-side exactToken1Report. It is a dispute-profitability parameter, not an exposure cap. The numerator estimates one dispute gas cost converted into REP with a profit buffer; the denominator is the target price-error room left after OpenOracle fees and expected adverse REP/ETH movement during settlement.

The canonical formula inputs live in shared/ts/oracleInitialReport.ts, exported as @zoltar/shared/oracleInitialReport. The UI deployment helper and simulator deployment helper consume that shared value. The current inputs are requiredDisputerProfitBuffer = 2x, gasUnitsForOneDispute = 300,000 gas, assumedGasPriceInEthPerGas = 30 gwei, repPerEthPrice = 1,000 REP / ETH, targetPriceErrorForDispute = 10%, openOracleProtocolFeeFraction = 1%, openOracleReporterFeeFraction = 0.1%, disputeReportSizeMultiplier = 1.15x, and expectedRepEthPriceMoveDuringSettlement = 1%. Those values produce a positive denominator and exactToken1Report = 259.332023575638507216 REP (259332023575638507216 atomic REP). The helpers evaluate the displayed equation with ORACLE_FORMULA_PRECISION = 1e18 fixed-point integers: fee fractions, disputeReportSizeMultiplier, disputeProfitFraction, and priceMoveFraction use integer division that floors at that precision, then the final report amount uses ceiling division by ORACLE_FORMULA_PRECISION * denominator. If the denominator is zero or negative, the assumptions do not leave enough price-error room for profitable disputes.

The detailed immediate-execution path, staging constraints, pending report bound, callback no-op cases, recovery path, consumed failure modes, liquidation snapshot staleness, and liquidation-distance check are listed with source links in the REP/ETH Oracle Operations reference.

Protocol Assumptions

• The economic value of REP backing remains larger than the value of the obligations that REP is securing.
• Users accept that, after a fork, the protocol may sell part of a child universe’s REP backing in the truth auction to refill missing ETH collateral.

Market and Liquidity Assumptions

• The child-universe truth auction can attract enough demand for child-universe REP to repair missing ETH collateral when repair is needed.
• REP and ETH can be exchanged with sufficient liquidity and price discovery that collateral repair and solvency operations do not fail purely because markets are too thin.

Coordination Assumption

• Users who want clean resolution continue in the child universe they expect other users to keep valuing.

Operational Failure Modes

• If truth-auction demand is weak, a child pool can resume with only partial collateral repair.
• If REP/ETH liquidity is thin or price discovery is poor, solvency-sensitive operations become less trustworthy.
• If users and capital split across multiple child universes, no single child universe may recover the dominant economic value assumed by the simpler fork story.

Zoltar forks only create child universes, and Placeholder carries underwriting state, collateral state, and outcome shares into them. If users and bidders coordinate on the child universe they expect to keep using, REP migration, proportional collateral migration, and truth-auction repair can rebuild usable market state there.

Escalation Parameters

Rows marked as deployment-configured are constructor or factory inputs for a deployment. Rows marked as constants come from the named Solidity constant and require a contract change to modify.

Migration, Auction, Solvency, and Retention Parameters

Oracle Parameters

The lifecycle has four checkpoints: pool creation, local escalation, fork migration, and optional collateral repair. The Lifecycle Flow figure shows the happy path; fork migration and auction repair cover the exceptional cases.

• Local resolution keeps redemption in the original pool.
• Non-decision moves the relevant state into child pools.
• Short child collateral triggers truth-auction repair before normal child operation resumes.
• Solvency-sensitive operations run through the bounded REP/ETH price-oracle path, not through the truth/forking path.

• Origin security pools currently support the exact categorical market shape Yes / No, with Invalid added as the third trading and resolution outcome.
• Placeholder issues transferable shares and manages redemption and migration, but does not provide secondary-market trading.
• Zoltar fork thresholds and fork burn parameters are constructor-configured economics; the default deployment config uses forkThresholdDivisor = 20 and forkBurnDivisor = 5.
• The escalation-game initial deposit is deployment-configured, with a default of 1 REP (1000000000000000000 atomic REP units).
• 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.
• Some comments in SecurityPool acknowledge open accounting questions around child-pool complete-set behavior.