Oracle Failure Modes: A Failure Tree for Prediction-Market Resolution

Executive Summary

When a prediction-market resolution fails, it almost always fails at the oracle layer. The question is not whether oracles can fail — they can — but which failure modes are dominant for a given market and how to price them. This post walks through a seven-mode failure tree for oracle dependency, calibrates each mode against historical incidents, and shows how SettleRisk's SINGLE_ORACLE_DEPENDENCY driver and related taxonomy capture the structure.

Core Concept

A prediction-market oracle is any source of truth that feeds the resolution decision. It can be:

An API (CoinGecko, BLS, Bloomberg terminal)
A human committee (UMA voters, Kalshi internal review)
A public document (Federal Reserve press release, court filing)
A composite (median of N exchange prices)

Each of these has distinct failure modes. The seven canonical ones:

| Failure mode | Example | Annualized incidence | |--------------|---------|----------------------| | Source unavailable | API outage during resolution | ~4% | | Source ambiguity | Multiple feeds disagree | ~3% | | Source delisted | Exchange removes the ticker | ~1% | | Source revised | Data restated after publication | ~2% | | Source captured | One party controls the source | ~0.5% | | Source mis-aligned | Source measures something subtly different | ~3% | | Source latent | Source publishes but no one notices in time | ~1% |

The aggregate single-oracle failure probability is roughly 12-15% annualized for markets that depend on a single non-redundant source. That is roughly an order of magnitude worse than markets with three-or-more redundant feeds.

Worked Example

A Kalshi market on "Will April 2026 CPI exceed 3.5% YoY?" depends on the BLS API as its sole resolution feed. Two failure modes apply:

Source unavailable — BLS API has 99.5% reliability but historical outages cluster around data-release events (high-traffic load)
Source revised — BLS revises ~7% of monthly CPI prints within 30 days

SettleRisk surfaces both:

from settlerisk import SettleRiskClient

client = SettleRiskClient(api_key="sk-...")
score = client.get_risk_score("kalshi", "cpi-april-2026")

for d in score.drivers:
    if d.driver_type in ("SINGLE_ORACLE_DEPENDENCY", "DATA_REVISION_RISK"):
        print(f"{d.driver_type:30s}  {d.points_contribution:&gt;3}  conf={d.confidence:.2f}")

SINGLE_ORACLE_DEPENDENCY        12  conf=0.95
DATA_REVISION_RISK               9  conf=0.81

Combined contribution: 21 points on top of the 8-point Kalshi base — pushes this from LOW into MEDIUM tier.

TypeScript:

import { SettleRiskClient } from "settlerisk";

const client = new SettleRiskClient({ apiKey: "sk-..." });
const score = await client.getRiskScore("kalshi", "cpi-april-2026");

for (const d of score.drivers) {
  if (["SINGLE_ORACLE_DEPENDENCY", "DATA_REVISION_RISK"].includes(d.driverType)) {
    console.log(`${d.driverType.padEnd(30)}  ${d.pointsContribution.toString().padStart(3)}  conf=${d.confidence.toFixed(2)}`);
  }
}

Implementation Notes

Redundancy moves the needle most. Adding even one redundant oracle cuts the effective failure probability roughly in half. Markets with 3+ redundant sources fall into LOW tier almost automatically (absent linguistic ambiguity).

Distinguish source unavailability from source captured. An API outage is a transient problem; a captured source (one party controls the data feed) is an existential one. SettleRisk's COUNTERPARTY_RISK driver captures capture cases separately.

Match resolution window to source SLA. If a market resolves in a 24-hour window and the source publishes monthly with a 7-day revision window, the rules text is internally inconsistent — flag it as MULTI_STEP_RESOLUTION regardless of source quality.

| Source type | Reliability heuristic | |-------------|----------------------| | Government API (BLS, Census, Treasury) | 99.5% with weekly maintenance | | Top-3 crypto exchange | 99% with deeper outage tail | | Centralized data vendor | 99.9% with paywall risk | | Public document repository | 95% with publication-lag risk | | Human committee | Variable; depends on quorum rules |

Subscribe to oracle health. SettleRisk's url_health table tracks 24h, 7d, and 30d uptime for every URL referenced in any market rules. The data is exposed via the /v1/status endpoint at the source level.

Failure Modes

1. Treating "single oracle" as automatically bad. Single-oracle markets backed by a high-reliability government API (e.g. BLS) can still be LOW tier. The driver fires on dependency; severity depends on the source.

2. Ignoring publication-time clustering. Source outages don't distribute uniformly. They cluster on release days. A market resolving the moment a data print drops faces above-average outage risk.

3. Missing revision windows. Many official sources publish first-print numbers and revise. If your market resolves before the revision window closes, you carry latent revision risk.

4. Confusing source ambiguity with source unavailability. Two oracles disagreeing is not the same as one oracle being down. The first creates dispute work; the second creates delay.

5. Skipping the url_health check. SettleRisk tracks URL uptime separately from market scoring. A market that scored MEDIUM yesterday can move to HIGH today if its primary source dropped below 90% recent uptime.

Checklist

[ ] Count oracle sources per market — 1 vs 2+ is a tier transition
[ ] Match source type to reliability heuristic
[ ] Pull recent url_health for primary sources
[ ] Treat publication-time clustering as a real risk
[ ] Watch revision windows on government data feeds
[ ] Distinguish unavailability from capture in your reporting

Sources + Further Reading

SettleRisk methodology — full SINGLE_ORACLE_DEPENDENCY logic
Redundant oracle feeds post — practical infrastructure patterns
Bureau of Labor Statistics — CPI publication and revision schedule
UMA Documentation — voter quorum rules
Oracle Manipulation in Decentralized Finance (Chen et al. 2021)

Audit oracle health on any market: free key at /signup.