Zoltar Protocol Security Model
Zoltar and Statoblast combine contract-enforced rules with an explicit economic assumption and an intentional loss-allocation policy. The failure modes and allocation boundaries below are parts of the protocol design, not omitted contract guarantees.
Normative scope. ORACLE-A1 and
AUCTION-A1 define a launch assumption and a conformance
policy, respectively. A deployment that cannot substantiate
ORACLE-A1 is outside the claimed security model. Code that
deviates from the contract behavior stated under either identifier is a
protocol defect. A conforming implementation still carries the
documented residual risk if the oracle assumption fails or auction
demand is weak.
The accepted design properties below are also normative review boundaries. The mere absence of a downstream-notional cap, question-to-universe binding, or absolute pending-report deadline is not a vulnerability claim against this design. Reviewers should instead test the stated costs, guards, accounting, and economic assumptions.
Contract-level invariants remain cataloged in Protocol Invariants. The OpenOracle integration and truth-auction design provide the full mechanics behind both boundaries.
Security Claim BoundaryContract conformance is necessary but does not make external participation or liquidity endogenous. Each boundary names the excluded guarantee and the party exposed when outside conditions do not provide protection.
Accepted Design Properties for Security Review
The following behaviors are deliberate protocol choices. A report that only restates one of them has not demonstrated a vulnerability. A valid finding must instead show that the implementation departs from the documented mechanics, that an advertised cost can be bypassed or recovered, or that the required launch assumption is not credible under concrete parameters.
| Accepted property | Intended security mechanism | What would be a finding |
|---|---|---|
| Oracle security is not bounded by downstream value. Report liquidity need not equal the value of one operation or all operations using the cached price. | ORACLE-A1: independent, profit-driven arbitragers monitor every pending report, correct profitable errors, and obtain inclusion before settlement. The selected initial WETH position equals the greater of the gas-based minimum and the sponsor's requested amount. The multiplicative-escalation halt equals the greater of the floored selected-initial-times-halt-multiplier candidate and the configured OI-derived floor. The position remains an incentive for correction rather than loss collateral. |
Incorrect sizing or settlement math; a bypass of public dispute access; cache use outside the documented window; or concrete launch parameters under which a material false report cannot be corrected profitably and in time. |
| A caller may use any existing ended global question to fork any eligible universe. See the canonical global-question mechanics. | Permissionless fork admission is economic: the initiator commits the computed fork threshold in parent REP and receives migration credit only after the computed, floored haircut. Either value can floor to zero at dust supply. Applications may impose stricter question relevance above Zoltar. | A fork before the question ends; failure to collect or account for a nonzero computed threshold or haircut; recovery or duplication of a nonzero haircut; bypass of one-fork-per-parent state; malformed branches; or an application claiming stricter eligibility without enforcing it. |
| Valid rolling disputes may extend the pending oracle lane indefinitely. The coordinator has no absolute settlement deadline while disputes continue. | Every extension executes a valid OpenOracle limit-order replacement, restarts settlement, and requires the replacement position. The computed protocol fee can floor to zero at atomic-unit dust, but a wildly wrong dust-side quote exposes the reporter's opposite-side position to immediate profitable correction under ORACLE-A1. Availability against an indefinitely funded participant or sustained correction censorship is excluded. |
A free or underfunded reset; fee avoidance or refund; unauthorized queue use; invalid deadline transition; accounting that lets capital be reused simultaneously; or documentation or UI that promises bounded completion. |
Cost boundaries depend on configured parameters. Fork admission uses a computed, floored threshold and haircut, so its strength depends on supply along the recursive lineage. The Zoltar economics section owns current defaults, flooring boundaries, and worked values. Each valid rolling dispute must fund a replacement position and its computed protocol fee. Dust flooring can reduce that fee to zero, but it does not remove the executable limit order or replacement-position requirement. Crediting an economically inaccessible internal fee balance is not an ERC-20 supply burn. See the OpenOracle security classification and parameter table for current values and numerical examples.
Recursive fork gas. The invariant catalog's
EXT-05 entry is the
canonical source for the requirement, current enforcement status,
and depth-independence evidence. Reviewers should use that entry
rather than infer gas behavior from the economic cost of an
individual fork.
Guarantees and Excluded Guarantees
| Mechanism | Contract-enforced behavior | External condition or policy | Deliberately excluded guarantee |
|---|---|---|---|
ORACLE-A1 |
Reports are sized from configured gas, fee, and target-error parameters to target profitable correction; accepted prices expire after the cache window. | An independent funded arbitrager monitors, acts, and obtains inclusion before settlement. | Report liquidity does not collateralize or cap downstream or cumulative operation value. |
AUCTION-A1 |
Qualifying underfunded bids receive the full REP sale cap for retained ETH, and the child activates with collateral actually migrated and raised. | No minimum demand is assumed; actual buyer demand determines how much ETH repair is available. | The auction does not guarantee a minimum execution price, full repair, or that open-interest holders are made whole. |
ORACLE-A1 — Always-Available Profitable Arbitrager
Required deployment assumption. At least one independent, rational, adequately capitalized OpenOracle participant continuously monitors pending REP/ETH reports, corrects every report for which correction is profitable under the configured economics, and can obtain transaction inclusion before settlement.
Report liquidity is a correction incentive, not collateral for the assets whose solvency checks consume the resulting price. The coordinator intentionally imposes no downstream-notional or cumulative cache-usage cap. One accepted price may support multiple otherwise-valid withdrawals, liquidations, allowance updates, or escalation deposits while it is fresh.
If monitoring, capital, or timely inclusion fails, the protocol places no onchain upper bound on loss based on the report position. For example, a report funded with a few WETH can still be consumed by operations whose combined external value is hundreds of ETH. That mismatch is expected: the claimed defense is profitable correction before settlement, not reimbursement after a false price is accepted.
Implementation and test evidence:
OpenOraclePriceCoordinator.sol,
priceOracleSecurity.test.ts
(dynamic minimum sizing and repeated cached-price use), and
the full integration threat model.
AUCTION-A1 — Punitive Underfunded Clearing
Intentional loss-allocation rule. A truth auction is
both a collateral-repair mechanism and a penalty for security capital
that does not migrate into the child. The cap-implied
underfundedThreshold is a bid-qualification threshold. It
is not an execution-price floor.
When ordinary clearing reaches neither auction cap, bids at or above the
qualifying tick are retained. If any ETH qualifies, those bidders
collectively receive maxRepBeingSold for their actual
retained ETH and share the complete unmigrated security-bond allowance.
The common effective price is therefore
underfundedWinningEth / maxRepBeingSold, which can be below
the qualification threshold. Bids below the threshold refund. If no bid
qualifies, all bids refund and no REP is sold.
The auction clearing design owns the qualification formula, tick rounding, worked examples, and per-bid allocation rules.
The child activates with the ETH actually routed during migration plus the ETH actually retained by the auction. It may remain undercollateralized, and open-interest holders are not guaranteed to be made whole. That shortfall is the intended consequence of insufficient demand: non-migrating security positions lose the auctioned economic value, while users of the affected child bear any remaining collateral impairment.
Implementation and test evidence:
UniformPriceDualCapBatchAuction.sol,
SecurityPoolForker.sol,
SecurityPoolForkerVaultMigrationDelegate.sol,
truthAuction.test.ts
(the minimum-bid underfunded-winner test), and
the full clearing design.
Review and Deployment Classification
The accepted assumption, design properties, and loss-allocation policy do not remove these paths from security review. They change the question from “does Solidity enforce an excluded property?” to “does the implementation conform, and is the external assumption credible for deployment?”
| Review result | Classification | Required response |
|---|---|---|
| Code deviates from the sizing, qualification, allocation, refund, activation, or accounting behavior defined above. | Implementation vulnerability, with severity based on impact. | Fix the contracts and add a regression test. |
| Code conforms, but the review demonstrates that profitable correction or timely inclusion is not credible under launch parameters. | Deployment-blocking economic risk. | Change parameters or design, or explicitly accept the quantified risk. |
| Code conforms and the concern is only that report liquidity does not bound downstream notional, or that weak demand may leave the child under-repaired. | Documented residual risk, normally informational rather than a new vulnerability. | Confirm the assumption or policy remains an explicit launch decision. |
Launch monitoring should track OpenOracle report visibility, correction profit after current gas and fees, practical inclusion latency, truth-auction participation, and the collateral deficit remaining after each auction. Monitoring detects oracle-assumption or auction-demand deterioration; it does not add an onchain guarantee or an emergency control.