Research question
How does liquidity provision, execution, and position management work in a crypto-native prediction market?
The investigation treats quoted probability, executable price, recorded trade, wallet position, and settled state as different evidence layers. The goal is to understand where those layers align — and where latency, depth, or data synchronization can make them diverge.
System architecture
Scope: researched, built, and investigated. This case study does not claim production deployment, audited returns, or permanently solved infrastructure failures.
Weather-market structure
Ordered, mutually exclusive outcome buckets
Temperature markets can be represented as an ordered set of mutually exclusive buckets. That order matters: a forecast concentrated one bucket away from the realized outcome is less wrong than a forecast concentrated at the opposite end of the range. The research therefore preserves the event-level bucket order rather than treating every binary token in isolation.
Sort outcomes by physical threshold, not API return order.
Check that one event resolves into one bucket under the stated rules.
Confirm buckets cover the intended range without gaps or overlaps.
Event-level forecast evaluation
Three complementary scoring rules were investigated at the complete-event level:
- Ranked Probability Score (RPS) respects the cumulative distance between ordered outcomes.
- Brier Score measures squared probability error across the mutually exclusive outcome set.
- Log Loss strongly penalizes assigning very low probability to the realized bucket and requires careful probability clipping.
Event-level evaluation avoids misleading comparisons created by scoring each YES token independently while ignoring that all buckets belong to one probability distribution.
CLOB mechanics: quote is not execution
The highest buy interest and lowest sell interest define an executable spread, not a single universal price.
A maker posts resting liquidity; a taker crosses the book. Fill probability and timing differ.
Displayed quantity at multiple price levels determines whether a theoretical edge survives actual size.
Probability-style prices communicate a market-implied view, but execution analysis must also consider side, spread, queue position, available depth, partial fills, and latency.
Negative Risk and executable arbitrage conditions
For a complete set of mutually exclusive outcomes, price relationships can imply a theoretical combination trade. The research separates that mathematical relationship from an executable opportunity.
An executable condition requires compatible contract semantics, correct event grouping, sufficient bid/ask depth at the required size, feasible simultaneous or safely sequenced fills, and remaining edge after fees, slippage, latency, and settlement risk.
Negative Risk mechanics were investigated as part of market structure. No profit or realized-arbitrage claim is made.
Transaction and position reconciliation
The workflow compares system records across sources rather than assuming one endpoint is sufficient. API status, local execution records, wallet transfers, token balances, and settlement interpretation can update at different times or use different identifiers.
Problems investigated
- API versus local database inconsistency and duplicate or missing records.
- Wallet or ERC-1155 position mismatch against recorded executions.
- Identifier mapping across event, market, condition, token, order, and trade.
- Settlement interpretation and the distinction between trade-time exposure and resolved state.
Latency and risk controls
Freshness checks, schema validation, synchronization state, and reconciliation alerts.
Spread/depth thresholds, fill-state monitoring, stale-order handling, and connectivity checks.
Position limits, event-level aggregation, exception states, and circuit-breaker behaviour.
Implications
- Technical: API reliability, state synchronization, identifier integrity, and wallet/on-chain truth.
- Market: liquidity, spread, execution quality, depth, and queue-dependent maker fills.
- Risk: incomplete execution, position imbalance, stale data, infrastructure dependency, and settlement misunderstanding.