Methodology & Oracle Models

How it works

Traditional prediction markets rely on human moderators or crowd consensus to determine outcomes. Latent Markets takes a different approach: we use advanced AI systems—large language models paired with deep research capabilities—to objectively evaluate each market's resolution criteria when it closes.

When you create or trade on a market, you specify a clear question and resolution criteria. At the market's close time, our oracle pipeline automatically gathers relevant information, analyzes it using state-of-the-art AI models, and produces a verifiable outcome. Every resolution includes a cryptographic proof bundle so you can independently reproduce and audit the result.

This AI-driven oracle approach eliminates human bias, scales to any topic, and delivers results in minutes—not days. Whether you're a casual trader or a technical user who wants full transparency, our methodology ensures that every market settles fairly and verifiably.

Trading & liquidity

Markets trade continuously using an LMSR automated market maker (AMM). When you buy, your funds are added to a shared collateral pool and you receive outcome shares. When you sell, the AMM buys your shares back at the current price. Funds are not held in per‑bet escrow; instead, the pooled collateral is sized to guarantee payouts.

• Exit anytime (OPEN): you may sell some or all shares back to the AMM during continuous trading. Larger orders move the price (slippage) depending on market liquidity.
• State gates: trading is batched during AUCTION, may be paused during CHALLENGED finalization, and stops atRESOLVED (only redemptions remain).
• Liquidity and risk: the AMM’s worst‑case loss is bounded byb · ln(n), where b is the liquidity parameter andn outcomes. We provision collateral accordingly and surface status in the UI.
• Redemptions: after resolution, winning shares redeem for the quoted currency (e.g., pUSDC). Losing shares have no value. If a market isINVALID, we refund participant spend.

This pooled‑collateral model enables fast price discovery without per‑order matching and lets traders adjust positions throughout the market’s life.

Oracle models

Every market declares its oracle configuration up front. You can choose between two approaches:

• Pinned models: The market locks to a specific AI model version (for example, gpt-4o-2024-08-06) that never changes. This guarantees absolute consistency and reproducibility throughout the market's lifecycle.
• Provider alias at close: The market references a provider's "best available" model (for example, openai:best-gpt-4o). When the market closes, we freeze the exact model version active at that moment, ensuring all participants resolve against the same AI snapshot.

“Best at close” maps a provider alias to a concrete model version at the exact market close timestamp. The resolved version is recorded in the proof bundle for auditability.

Both approaches use the same settlement and proof pipeline. Oracle metadata—including the exact model version used—is displayed on market cards, detail pages, and in the resolution proof bundle.

Reproducibility & verifiability

At the market's close_at timestamp, our system records the inputs required to reproduce the settlement. For alias-based markets, the backend resolves the provider alias to an exact model version using the latest active mapping at or before close time. This resolved model is stored on the market record and included in the proof bundle.

Each proof bundle contains the inputs used for settlement: the prompt, random seed (if applicable), retry parameters, and the final resolved_model_version. For pipelines that retrieve external evidence, we include or reference the evidence snapshot used. Anyone can replay the evaluation against these recorded inputs to verify the decision. The market detail page displays this information in the Oracle panel, ensuring transparency without relying solely on documentation.

Note: model providers and web content are inherently non‑deterministic over time. Our claim is reproducibility under the recorded inputs and frozen model version—not that a fresh, unconstrained re‑run will always produce identical text. When inputs or models change, divergence is expected.

Oracle health & availability

Reliable oracles are essential for timely market settlement. Our platform continuously monitors every AI provider and model version using automated health checks that run every two minutes. These checks measure median response latency, success rate, and uptime.

The Oracle Status card on the homepage and analytics dashboards display real-time health indicators so traders can assess confidence in upcoming settlements:

• Online: Fast responses (<2 s median latency) with ≥99% success rate. Markets settle normally.
• Delayed: Slower responses but still reliable. Markets may display a "Delayed" badge to set expectations.
• Degraded/Offline: High error rates or extended outages trigger operational alerts. New market creation may be paused until conditions improve.

This proactive monitoring ensures that you always know the current state of our oracle infrastructure before placing a trade.

Fairness & fallbacks

Settlement is designed to be idempotent and fault-tolerant. If a provider alias cannot be resolved at market close—due to a temporary outage or data issue—our system retries once after a five-minute delay using the latest registry data. If both attempts fail, the market is marked INVALID with a documented reason, and all participant funds are returned.

If the alias cannot be resolved at close due to provider incident, we retry once after a fixed delay; otherwise the market transitions to Invalid per policy.

This strict retry policy mirrors our handling of transient failures for pinned models and ensures that traders are never exposed to silent, best-effort fallbacks that could bias outcomes. Fairness and transparency are non-negotiable: if we cannot resolve a market deterministically, we return capital rather than guess.