Statoblast Protocol 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 contract guarantee. Each entry names the boundary that must remain true, the failure that follows when it does not, and the documentation whose mechanics rely on it. The Protocol Invariants catalog owns contract-enforced properties and their implementation evidence.

Participation and coordination

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

  1. 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. 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: auction gas bounds, oracle gas parameters, and escalation deployment costs.

  3. 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. Participants can mobilize REP to raise an alarm

    Market participants can mobilize enough vault-backed REP through security-vault operators to fund an early competing Invalid, Yes, or No deposit and keep the local contest active while additional capital reacts.

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

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

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

    Access-value boundary. 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. At least one executor advances every required public transition

    An adequately funded participant or service monitors and calls each needed permissionless transition, including liquidation initiation, 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, overflow operation execution, and proof-based claims.

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

    Mechanics: lifecycle liveness, fork operations, and oracle operations.

Forks, truth, value, and liquidity

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

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

    Fork value boundary. 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. 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. 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

    Value concentration. 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: Zoltar security and child outcome resolution.

  4. Participants can access timely outcome evidence

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

    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 child resolution.

  5. 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 operator migration guidance.

  6. Truth auctions can convert supported child REP efficiently

    When repair is needed, enough demand can buy some supported-child REP for ETH at an acceptably small discount and operating cost. This does not assume that the full repair target is raised.

    Failure boundary: Weak or strategically withheld demand leaves the child operational with impaired collateral.

    Mechanics: auction lifecycle, clearing, and repair accounting.

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

    Economic backing. 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. 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, question identity, and pool selection.

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.

  1. 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, staging, and settlement 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. 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. 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. 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. 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. 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 configured genesis REP burn sink remains inaccessible. On mainnet these token behaviors are external assumptions. On Sepolia, the reviewed GenesisReputationToken and WETH9 enforce issuance and transfer behavior, provided A23 verifies their deployed bytecode and wiring and A26 preserves Ethereum execution. The configured burn sink's inaccessibility remains an external assumption on Sepolia as well as mainnet. Canonical child REP is likewise implemented by the reviewed ReputationToken contract rather than being an additional external-token assumption.

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

    Mechanics: EXT-01, genesis REP handling, and oracle token pair.

  2. Participant-controlled recipients can accept required asset deliveries

    Vaults, bidders, oracle sponsors, traders, share holders, and other caller-controlled recipients use addresses that accept native ETH when claiming fees, collateral, proceeds, or refunds. 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 push may revert or become bidder-specific deferred credit; 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 pool payout guardrails.

  3. Users select verified canonical deployments

    The reviewed release is built reproducibly with its pinned compiler and toolchain configuration. Release artifacts identify the manifest addresses and reviewed bytecode hashes. Users and integrations compare locally rebuilt and deployed runtime bytecode with those reviewed hashes, then verify constructor-installed dependencies, factory and forker provenance, pool lineage, question ID, and manifest. Constructor admission 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, deployment bytecode, and authority invariants.

  4. 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, canonical replay, and operator verification.

  5. Immutable parameters preserve economic and executable security margins

    The selected parameter relationships keep the fork threshold and haircut economically meaningful, the initial escalation deposit affordable, the liquidation multiplier above one plus the bonus, 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 parameters, fork economics, liquidation economics, oracle parameters, and oracle attack model.

  6. 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: reorg handling, atomicity and deadlines, and bytecode and gas bounds.

  7. 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. OpenOracle's fixed Permit2 singleton additionally validates either an EOA signature or an ERC-1271 contract-account signature correctly.

    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. Canonical Permit2 owns 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, pinned Permit2 implementation provenance, and deterministic deployments.

  8. 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, vault and pool operations, 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.