Why Statoblast uses OpenOracle

Protected operations

A per-pool price coordinator protects withdrawals and liquidations that depend on REP value. Escalation Game deposits also require a fresh accepted price when the pool has active capacity ownership. Each SecurityPool still applies its own current health and authorization checks after a price is available.

Cached and fresh prices

An accepted report becomes the coordinator's cached price for a limited freshness window. An operation can use that cache while it remains fresh. When it is stale, a sponsor funds a new report and the coordinator stages eligible work until settlement. A child pool may inherit a numeric starting value, but it cannot use that value until the child accepts its own report.

One request, dispute, and settlement

Alice requests a REP withdrawal from a market's vault while its cached price is stale. She funds an initial REP/ETH report and the coordinator records her pending operation. Bob believes the report is inaccurate, so he replaces it with the required opposing position before settlement. The dispute restarts the settlement window. If nobody replaces Bob's report before its new deadline, OpenOracle settles it and calls the coordinator. The coordinator validates the report, refreshes its cache, and attempts Alice's withdrawal against the pool's live safety checks.

Security limitations

OpenOracle relies on participants noticing and profitably correcting inaccurate reports. Congestion, censorship, incorrect gas assumptions, insufficient economic incentives, or repeated disputes can delay or undermine that process. A fresh price is not a guarantee that an operation will succeed, and a settled price says nothing about the market question's outcome.

The OpenOracle integration reference specifies funding formulas, report sizing, optional flags, sponsor rules, queues, callbacks, recovery paths, configuration, and interactive estimators. The security model states the participation assumptions.