Statoblast security model

Statoblast and Zoltar enforce accounting, authorization, and lifecycle rules onchain. Their economic safety and practical liveness still depend on the participant, market, asset, deployment, client, data, Ethereum, and cryptographic assumptions below.

An assumption is not a guarantee enforced by the contracts. Each entry says what must remain true, what can fail if it does not, and where the related mechanics are explained. The Statoblast and Zoltar invariants catalog lists contract-enforced properties and their implementation evidence.

Security-model orientation

The assets and state at stake are REP, ETH settlement collateral, outcome shares, vault backing, Escalation Game deposits, child-universe accounting, and the integrity of event-derived state.

Boundary Examples
Trusted protocol components Zoltar, SecurityPools, share tokens, price coordinators, forkers, and their configured delegates.
External dependencies OpenOracle, WETH/REP token behavior, Ethereum execution and finality, RPCs, wallets, and proof data.
Untrusted actors Traders, vault owners, liquidators, disputers, bidders, settlers, keepers, and indexers.
Failure outcomes Reverted calls, delayed transitions, underfunded child repair, stale prices, incorrect external data, or unreconstructable history.

The assumptions below explain what must remain true for these assets and transitions to retain their intended safety or liveness properties; they are not additional contract guarantees.

Reviewing an operational concern

To classify an economic or liveness concern, find its external dependency in the grouped assumptions below and follow that entry's mechanics links. Contract-enforced properties are in the invariant catalog; fork-depth gas behavior, for example, is bounded lifecycle work.

Operator work relies particularly on these assumptions:

Participation and coordination

These assumptions explain why someone performs the economically useful action instead of merely being permitted to perform it.

  1. A01 Participants act on risk-adjusted economic incentives

    Enough participants prefer actions with greater expected value after gas, fees, delay, capital lockup, and risk. The model does not rely on altruistic defense.

    Failure boundary: A nominally profitable liquidation, dispute, bid, migration, or fork defense may not happen when its risk-adjusted return is unattractive.

    Mechanics: economic roles, liquidation incentives, auction clearing, and oracle incentives.

  2. A02 Required actions remain worth their operating costs

    For each time-sensitive action, transaction fees, opportunity cost, coordination cost, and capital lockup remain small enough relative to the value protected or earned.

    Failure boundary: An action can be technically executable but economically abandoned before its deadline.

    Mechanics: Collateral Repair Auction lifecycle, oracle gas parameters, and Escalation Game lifecycle.

  3. A03 Each economic role has enough independent participants

    Trading, liquidation, escalation, migration, auction bidding, price correction, and settlement have enough non-colluding participants for the relevant action. Secondary-market trading is external to Statoblast.

    Failure boundary: Thin or controlled participation can remove price discovery, competitive bidding, or an opposing outcome deposit.

    Mechanics: economic roles, fork coordination, and auction participation.

  4. A04 Participants can mobilize REP to raise an alarm

    Market participants can mobilize enough REP, from wallet balances or withdrawable portfolio principal, to fund an early competing Invalid, Yes, or No deposit and keep the local contest active while additional capital reacts. Resumed, unresolved continuation games can accept wallet REP.

    Failure boundary: A wrong local outcome can become final before better-capitalized participants enter.

    Mechanics: escalation resolution, escalation accounting, and escalation guardrails.

  5. A05 Participants value continued access to the supported Statoblast lineage

    The participants whose coordination determines durable use value continued access to the supported Statoblast lineage at least as highly as its configured statoblastSecurityMultiplierBps basis points of the value secured by that lineage. BPS_DENOMINATOR = 10_000 converts that stored value to its human multiplier.

    ValueStatoblast access × BPS_DENOMINATOR ≥ statoblastSecurityMultiplierBps × Valuesecured

    Compare one lineage’s continued-use value and secured value at the same pre-attack time.

    Failure boundary: Participants may rationally abandon, grief, or coordinate away from a lineage whose continued-use value is too small.

    Mechanics: fork security, fork migration, and Statoblast security boundary.

  6. A06 At least one executor advances every required public transition

    An adequately funded participant or service monitors and calls each needed permissionless transition, including funded takeovers, local escalation deposits and settlement, fork activation, child creation, vault and share migration, auction start and finalization, bid settlement, OpenOracle report settlement, settled-report callback recovery, branch finalization, and proof-based claims.

    Failure boundary: Permissionless state can remain stalled even though no contract authorization prevents progress.

    Mechanics: lifecycle liveness, fork migration guardrails, and oracle guardrails.

Forks, truth, value, and liquidity

These assumptions connect onchain branching and accounting to offchain truth judgments, asset value, liquidity, and migration.

  1. A07 A supported lineage preserves enough aggregate child value

    For each protected Statoblast origin lineage, evaluate the parent and its child-pool continuations in one numeraire at the fork-security decision horizon, before long-run value has fully concentrated on one branch. The sum of traded child-lineage values remains large enough compared with that parent lineage’s pre-fork value under the origin’s immutable statoblastSecurityMultiplierBps. Each child asset is valued in its own branch; unrelated external collateral is not counted again.

    Valueparent lineage ≤ ∑ child∈Lineage continuations Valuechild × BPS_DENOMINATOR statoblastSecurityMultiplierBpslineage

    Parent and child values use the same origin lineage, valuation source, numeraire, and decision horizon. For multiplier 20_000 BPS, aggregate child-lineage value must be at least twice parent-lineage value; multiplier 30_000 BPS requires three times that value.

    Failure boundary: Value destruction or fragmentation can make a malicious or unnecessary fork cheaper than the harm it causes.

    Mechanics: fork economics, fork coordination, and pool migration.

  2. A08 REP market capitalization approximates economic value

    At the stated valuation time and system scope, REP market capitalization is a sufficiently accurate observable proxy for the discounted cash flow participants expect from REP.

    Failure boundary: Thin, manipulated, or speculative pricing can overstate the economic value securing open interest.

    Mechanics: REP economics and economic backing claims.

  3. A09 Users value the universes they judge truthful

    Users prefer the universe or universes they judge truthful, so economic activity and durable asset value concentrate there. Unlike A07’s fork-security decision horizon, this assumption describes the later, durable allocation of value after users coordinate.

    Valuebefore fork ≈ Valuetruthful universe

    When several branches remain plausibly truthful, document the value split instead of assuming one winner.

    Failure boundary: Coordination on a false branch, or durable fragmentation across branches, defeats the value-concentration security argument.

    Mechanics: branch non-guarantees and pool fork migration.

  4. A10 Participants can access timely outcome evidence

    Users can obtain enough reliable real-world evidence before the relevant protocol deadline to judge which universe is truthful.

    Failure boundary: Missing, delayed, or conflicting evidence can split honest capital or let a false local outcome become final.

    Mechanics: question encoding, invalid outcomes, and local resolution.

  5. A11 Migration is operationally practical

    Users, exchanges, interfaces, custodians, and other integrations are willing and able to migrate assets and state into the child universe or universes they support during the applicable windows.

    Failure boundary: Supported branches can remain illiquid or undercollateralized because economic claims and backing do not move there.

    Mechanics: REP splitting, pool migration, and share migration guardrails.

  6. A12 Collateral Repair Auctions can convert supported child REP efficiently

    When repair is needed, competitive Collateral Repair Auction entry can convert supported child REP into ETH at an acceptably small discount and operating cost. This is a participation assumption, not a contract guarantee of revenue or full repair.

    Failure boundary: Weak or strategically withheld demand leaves the child operational with impaired collateral. A shared portfolio auction can sell all fresh inventory for one funded lot. Ordinary surplus withdrawal and retirement remain available to winners, so selling the inventory does not guarantee permanent backing.

    Mechanics: shared portfolio auctions, and repair accounting.

  7. A13 REP is sufficiently liquid

    Participants can acquire or sell the required REP quantities without price impact or delay large enough to invalidate reporting, disputing, liquidation, auction, or migration economics.

    Failure boundary: Capital may exist in principle but cannot be assembled at a usable price before the deadline.

    Mechanics: economic roles, escalation, and oracle positions.

  8. A14 REP economic value exceeds the open interest it secures

    For a stated pool, lineage, or system scope at one timestamp, open interest and REP discounted cash flow are valued in the same numeraire, and REP discounted cash flow remains strictly greater. For a pool-level evaluation, open interest means the pool’s protocol-accounted ETH collateral unless the analysis explicitly names a broader exposure measure. The REP supply and price basis must also be stated; market capitalization is the observable proxy in A08. This external relationship is separate from each pool’s onchain multiplier-adjusted REP backing check.

    Open Interest < Discounted Cash FlowREP

    Record scope, timestamp, common numeraire, price source, REP supply basis, and open-interest definition when evaluating this strict inequality.

    Failure boundary: REP holders may rationally accept or cause losses larger than the durable REP value placed at risk.

    Mechanics: security pools, liquidation backing, and oracle exposure analysis.

  9. A15 Question selection remains aligned with user intent

    Interfaces and users verify the immutable question ID and metadata when selecting a market or pool, and the question has evidence and wording from which participants can reach an outcome or intentionally choose Invalid.

    Failure boundary: Unverified selection can route users and capital to an unintended market or pool, while ambiguous wording or unavailable evidence can split local outcome coordination.

    Mechanics: UNI-02 and question identity.

Oracle correction, inclusion, and operational data

These assumptions cover truthful REP/ETH price discovery, deadline access, capital, independent correction, and the offchain information required to act. OpenOracle's optional flexible-escalation and halt-only-fee flags can change a corrector's required capital and net incentive, so a deployment that enables them must evaluate the same assumptions against its configured flag set.

  1. A16 Deadline transactions can obtain Ethereum inclusion

    Honest users can submit competitively priced Ethereum transactions and obtain canonical inclusion within every relevant dispute, escalation, migration, auction, and settlement window.

    Each onchain comparison assigns the exact deadline timestamp to one phase. Same-block ordering cannot move an action across that boundary: users must target the phase valid at the block timestamp rather than rely on transaction ordering to extend an expired window.

    Failure boundary: Censorship or congestion lasting through a deadline can finalize a wrong report or prevent a supported action.

    Mechanics: deadline invariants, auction windows, and oracle censorship model.

  2. A17 OpenOracle has an available, adequately capitalized corrector

    At least one OpenOracle participant continuously monitors pending REP/ETH reports, can identify candidate errors using the reference market in A19, can fund the scenario-dependent WETH and REP replacement position plus transaction costs, and can obtain inclusion before settlement. The participant's net incentive to perform the correction is the separate boundary in A18.

    Failure boundary: An incorrect report can settle and authorize price-sensitive pool actions when no capable participant detects, funds, and includes a correction.

    Mechanics: REP/ETH oracle, correction incentives, and attack model.

  3. A18 At least one available corrector has an independent net incentive

    At least one participant satisfying A17 is not under common control with the sponsor-funded coordinator reporting path, does not share the manipulation payoff, and is not bribed or compensated. The participant's net payoff from correcting is strictly greater than its net payoff from leaving the harmful report uncorrected. Two external submissions are not required for every request.

    Failure boundary: A sponsor-controlled, bribed, or economically indifferent corrector can make the contestable report path behave like a single trusted reporter.

    Mechanics: settlement validation scope, economic tradeoffs, and oracle invariants.

  4. A19 A robust reference market makes harmful REP/ETH errors correctable

    Independent participants can observe a manipulation-resistant reference REP/ETH price. Every price error large enough to unlock a security-relevant pool action also leaves a correction opportunity that remains profitable after actual gas, prevailing priority fees, OpenOracle fees, price impact, and required capital lockup.

    Failure boundary: A harmful deviation below the profitable correction threshold, or a manipulated/illiquid reference market, can settle without an economically rational challenge.

    Mechanics: report sizing, external-payoff model, and settlement limits.

  5. A20 Canonical chain data and proof construction remain available

    Participants can access reorg-aware Ethereum history, recognized contract addresses, OpenOracle report state, and the event data needed to construct carry and nullifier proofs before use.

    Failure boundary: A valid dispute, settlement, migration, or inherited claim can become practically unavailable even while its contract entrypoint remains live.

    Mechanics: event replay, carry proofs, and operator orientation.

Assets, clients, deployment, Ethereum, and cryptography

These assumptions define the technical foundation below the protocol’s onchain guards.

  1. A21 Genesis REP and configured WETH obey the required accounting model

    Genesis REP and configured WETH move exactly the requested base units, use 18 decimals, return supported ERC-20 values, and do not rebase, charge transfer fees, invoke unexpected callbacks, blacklist protocol contracts, pause required transfers, or permit unauthorized minting. WETH remains redeemable 1:1 for ETH, the genesis theoretical supply is accurate, and the hard-coded Constants.BURN_ADDRESS burn sink remains inaccessible. These are external assumptions on both networks, with one exception: on Sepolia the reviewed GenesisReputationToken enforces genesis REP issuance and transfer behavior, provided A23 verifies its deployed bytecode and wiring and A26 preserves Ethereum execution. Sepolia WETH is Uniswap's published contract, which the deployer verifies only by runtime-code hash. Canonical child REP is the reviewed ReputationToken contract and adds no external-token assumption.

    Failure boundary: Origin-pool, genesis-fork, or oracle accounting can overstate balances, backing, burned supply, or WETH value.

    Mechanics: bounded lifecycle work and oracle token pair.

  2. A22 Participant-controlled recipients can accept required asset deliveries

    Vaults, oracle sponsors, traders, share holders, and other caller-controlled recipients use addresses that accept native ETH when claiming fees, collateral, or proceeds. Collateral repair auction settlement instead credits bidder-specific pull escrow without calling the bidder; the bidder must accept ETH only when withdrawing that credit. Contract recipients also return the required ERC-1155 receiver selector when complete-set creation, share migration, or an outcome-share transfer delivers tokens to them. A rejected ETH pull or push reverts that transfer, and a rejected ERC-1155 callback reverts the mint or transfer and its surrounding protocol action. No protocol path can force a rejecting address to accept a later delivery or redirect every payout or mint.

    Failure boundary: A contract account that rejects ETH or the required ERC-1155 callback can strand its own payout or make its complete-set, migration, transfer, or claim action unavailable even while protocol-wide accounting remains safe.

    Mechanics: ETH callback safety, ERC-1155 callback safety, share-token receipt, auction refunds, oracle request refunds, and security pool guardrails.

  3. A23 Users select verified canonical deployments

    The reviewed release is built reproducibly with its pinned compiler and toolchain configuration. The deterministic manifest freshness check rejects address drift, while the deployment plan verifies pinned runtime-code hashes for planned contracts and bootstrap descendants. Users and integrations must still verify post-deployment wiring, factory and forker provenance, pool lineage, question ID, and the manifest against the intended network. Constructor admission alone is not a safety proof.

    Failure boundary: Toolchain drift, unavailable or mismatched reviewed hashes, permissionless lookalike instances, wrong dependencies, or unintended lineage and question wiring can bypass the reviewed protocol even when the selected bytecode functions as configured.

    Mechanics: release posture, deployment status, compiler configuration, OpenOracle build provenance, and authority invariants.

  4. A24 Clients, RPCs, and wallets preserve user intent and canonical state

    Interfaces, indexers, RPC providers, and wallet software return canonical, reorg-aware state; construct and display the intended chain, target, calldata, parameters, and ETH value; and submit only transactions the user authorizes. Users verify transaction previews rather than treating an application label as an onchain guarantee.

    Failure boundary: Compromised or stale offchain software can misroute signatures or capital, hide deadlines or events, or cause users to authorize valid but unintended calls without violating contract guards.

    Mechanics: deployment discovery, contract interactions, and operator verification.

  5. A25 Immutable parameters preserve economic and executable security margins

    The selected parameter relationships keep the fork threshold and fork haircut economically meaningful, the start bond affordable, the pool multiplier and the pool-held-REP branch multiplier derived from it (capital health) large enough for their distinct coverage roles, the oracle target error profitable to correct after fees and gas, dispute and settlement windows usable, and callback and transition gas executable. The Statoblast pool statoblastSecurityMultiplierBps is distinct from openOracleSecurityMultiplierBps.

    Failure boundary: Weak or internally inconsistent immutable parameters can defeat the economic or liveness argument even when the canonical contracts function exactly as configured.

    Mechanics: Statoblast pool parameters, fork economics, liquidation economics, oracle parameters, and oracle attack model.

  6. A26 Ethereum preserves the execution environment the protocol relies on

    Ethereum continues to provide correct EVM execution and atomic rollback, sufficient canonical finality, usable timestamp and block.basefee semantics, and block gas limits and gas schedules under which every mandatory immutable transition remains executable.

    Failure boundary: Deep reorganizations, invalid state execution, adversarial time behavior, or gas repricing can reverse accepted state or strand required transitions.

    Mechanics: contract interactions, atomicity and deadlines, and Escalation Game lifecycle.

  7. A27 Ethereum cryptographic primitives remain secure

    Keccak-256 remains collision- and preimage-resistant at the truncated widths used by the protocol, and CREATE2 identity remains sound. secp256k1 ECDSA signatures remain unforgeable with correct EOA signer recovery for Ethereum transactions and EIP-712 authorizations. Contract paths using SignatureValidation additionally rely on correct EOA or ERC-1271 contract-account signature validation; OpenOracle also relies on its fixed Permit2 singleton.

    OpenOracle fixes the Permit2 address, requires the exact permitted amount, sends the requested tokens to itself, and constructs the witness from the beneficiary, relayer, token owner, and intent. Permit2 defines the EIP-712 domain, deadline, permitted-amount ceiling, unordered-nonce replay protection, and EOA/ERC-1271 signature validation. Verification under A23 must cover the pinned Permit2 implementation at that fixed address.

    Failure boundary: Forged identities, colliding questions or universes, false carry proofs, forged EOA transactions, incorrect EOA recovery or ERC-1271 acceptance, or broken domain and nonce enforcement can violate otherwise-correct guards or authorize an unintended token transfer.

    Mechanics: universe identity, proof hashing, Permit2 deposit authorization, Permit2 signature interface, liquidation-approval signature validation, pinned Permit2 implementation provenance, and deterministic address guardrails.

  8. A28 Participants retain control of account authority

    Participants protect the private keys, signing devices, session permissions, and delegated ERC-20 or ERC-1155 approvals that authorize their accounts. Account recovery and custody arrangements do not give an unintended party effective control during a security-sensitive window.

    Failure boundary: A stolen key, compromised signer, or overbroad approval can authorize valid but unwanted transfers, deposits, bids, migrations, or configuration changes without violating a contract guard.

    Mechanics: transaction authority, security pool guardrails, and account-authority monitoring.

Guarantees deliberately not made

These outcomes remain possible without contradicting the security model. They should be included in user, operator, and integration risk disclosures.