Reference
Subsystem guardrails
What a Statoblast security pool, share migration, Escalation Game, fork migration, Collateral Repair Auction, or REP/ETH price coordinator will and will not accept, one subsystem at a time. Statoblast is the prediction-market layer built on the Zoltar fork oracle; see the system overview. Every rule names the contract source that enforces it, so operators, indexers, and interface maintainers can check it against the exact Solidity.
The invariant catalog connects these local guardrails to cross-contract conservation, liveness, and the stated economic assumptions; the security model is normative for external assumptions. Release procedure lives in Prepare a protocol release, assumption monitoring in Monitor security assumptions, and the remaining support contracts in the contract inventory.
Portfolio capital operations
Every question belongs to a shared portfolio. Verify the factory registration, capital ledger, settlement module and universe before sending funds. Deposits add principal; setting a commitment separately authorizes risk. Withdrawals and retirement check current owner principal and demand. Complete-set purchases use the registered portfolio route and recheck fees, available healthy capacity and backing floor.
The Statoblast portfolio view includes Liquidation takeover. Its transaction uses takeOverWithBounds: the receiver supplies a minimum REP award and maximum own REP, total principal and total commitment. Price epoch, health target and retirement cohort must still match. The award stays pledged; it is not an immediately withdrawable keeper payout. The preliminary cure can make a quoted takeover unnecessary or unavailable.
See the canonical module and accounting reference and the contract entrypoints.
Reporting and settlement
For reports through the question ledger, approve wallet REP to that ledger; direct deposits into an existing Escalation Game require approval to the game. The accepted deposit enters separate reporter custody and never becomes provider capital. Finalized local claims use deposit indexes; inherited claims use authenticated frozen-leaf proofs. Payouts go to recorded owners. Batches can be split, and deep lineage proofs use bounded preparation transactions.
See the canonical module and accounting reference and the contract entrypoints.
Shared forks
Owners choose one branch before the native cutoff. The shared coordinator snapshots and prepares each chosen branch once, then lazy owner activation and question materialization apply that state. A missing keeper cannot extend choice or auction deadlines. Native migration still requires inclusion during its finite window.
See the canonical module and accounting reference and the contract entrypoints.
Collateral repair auctions
The branch auction sells fresh unchosen provider REP against its aggregate ETH shortfall. Buyers bid ETH lots with minimum REP-per-lot limits and their health targets. Winning backing and commitments enter aggregate accounting immediately at closing. Activating a winner enables individual controls; it is not required to count the winner’s obligation. Losing-bid credits and refunds remain independently withdrawable.
See the canonical module and accounting reference and the contract entrypoints.
REP/ETH price reports
The shared feed accepts independent candidates. A pending report cannot reserve a sponsor lane or block unrelated reports. Sponsor funding and public settlement bounties are separate from provider capital. Capital transactions execute directly and recheck the accepted price, owner authorization, current health and exposure. There is no coordinator operation queue or liquidation approval registry.
See the canonical module and accounting reference and the contract entrypoints.