Modeling Settlement Delays in Prediction Markets
Settlement delay is one of the most underpriced risks in prediction markets. When a market should resolve in hours but actually takes days or weeks, the capital opportunity cost can dwarf your trading edge. Yet most traders treat settlement timing as binary: either the market resolves on schedule, or something has gone wrong. The reality is far more nuanced, and modeling it correctly is the difference between a capital-efficient portfolio and one that bleeds returns through hidden lockup costs.
Why Delays Are Lognormal
Settlement delays follow a lognormal distribution for a structural reason: most markets resolve quickly (within the expected window), but a meaningful tail experiences extended delays due to disputes, oracle failures, or ambiguous criteria.
This is similar to how insurance claim processing times behave -- most claims settle fast, but complex ones can take orders of magnitude longer. The same pattern appears in software incident response times, legal case durations, and construction project overruns. Anywhere a process can get "stuck" in an unexpected state, you see lognormal behavior.
A lognormal distribution is characterized by:
- A median (p50) that represents the typical outcome
- A long right tail capturing dispute scenarios
- Parameters mu and sigma that map directly to market characteristics
The key property that makes lognormal the right choice: it is always non-negative (delays cannot be negative), it is right-skewed (long tail of bad outcomes), and the log of delay times is approximately normally distributed. This last property means that small multiplicative shocks -- an oracle taking twice as long, a dispute adding a 3x multiplier -- compound naturally into the heavy tail we observe empirically.
The Mathematics of Lognormal Delays
Understanding the formulas behind the delay distribution helps you reason about what drives changes in the output. SettleRisk's delay model is fully deterministic and documented in our methodology, so there is no black box here.
Step 1: Baseline Parameters
Each platform starts with a baseline median and sigma:
| Platform | Baseline Median (hours) | Baseline Sigma | |----------|------------------------|----------------| | Polymarket | 6.0 | 0.90 | | Kalshi | 3.0 | 0.70 |
Polymarket's higher baseline reflects the UMA oracle challenge window, which introduces a structural floor on resolution time. Kalshi's lower baseline reflects its centralized resolution mechanism, which is faster in the common case but still subject to data source delays.
Step 2: Risk Multiplier
The aggregate risk score (0-100) stretches the median via a power-law multiplier:
s = aggregate_risk_score / 100.0
risk_multiplier = 1.0 + 2.5 * (s ^ 1.7)
median_hours = baseline_median_hours * risk_multiplier
The exponent of 1.7 ensures that low-risk markets (scores under 20) see minimal delay inflation, while high-risk markets experience sharply increasing expected delays. A score of 50 yields a multiplier of roughly 1.77x; a score of 80 yields approximately 2.96x.
Step 3: Sigma Adjustments
The spread of the distribution widens based on specific risk factors:
sigma = baseline_sigma
sigma += 0.60 * ambiguity_score
sigma += 0.40 * spof_strength
sigma = clamp(sigma, 0.35, 2.00)
Ambiguity score has a larger coefficient because ambiguous resolution criteria create open-ended dispute processes where the delay magnitude is genuinely uncertain. Single-point-of-failure (SPOF) risk also widens the distribution, but its effect is more bounded since oracle outages tend to have more predictable durations.
Step 4: Lognormal Parameters and Quantiles
With the adjusted median and sigma, the lognormal distribution is fully specified:
mu = ln(median_hours)
p50 = exp(mu) -- equals median_hours
p90 = exp(mu + 1.282 * sigma)
p99 = exp(mu + 2.326 * sigma)
expected_delay = exp(mu + 0.5 * sigma^2)
The z-scores 1.282 and 2.326 correspond to the 90th and 99th percentiles of the standard normal distribution. Note that the expected (mean) delay is always higher than the median for a lognormal distribution, and this gap grows as sigma increases. This is why using the median for capital planning systematically understates your actual expected lockup.
How We Calibrate the Distribution
SettleRisk's delay model uses two inputs:
1. Platform Median
Each platform has a baseline median settlement time:
- Kalshi: Typically resolves within hours of the data source publishing
- Polymarket: UMA oracle process adds 2-4 hours minimum, more for disputed markets
2. Risk-Adjusted Sigma
The distribution's spread (sigma) increases with:
- Ambiguity score: More ambiguous criteria = wider delay distribution
- Oracle dependency: Single oracle = higher tail risk from outages
- Complexity: Multi-step resolution processes add sequential delay risk
Reading the Delay Output
SettleRisk returns three percentiles for every market:
{
"delay_distribution": {
"p50_hours": 48.0,
"p90_hours": 168.0,
"p99_hours": 504.0,
"family": "lognormal",
"params": { "mu": 3.871, "sigma": 0.97 },
"fit_quality": 0.50
}
}
- p50 (48h): Half of similar markets resolve within 2 days
- p90 (168h): 90% resolve within 1 week -- plan your capital accordingly
- p99 (504h): In the worst 1% of cases, resolution takes 3 weeks
The fit_quality of 0.50 reflects that v1 uses heuristic calibration rather than historical fitting. As we accumulate resolution timing data across platforms, this quality metric will improve in future versions. See our features roadmap for details on upcoming statistical model integration.
Case Study: When Delays Cascade
The most instructive examples of settlement delay risk come from real-world incidents. Our case studies page documents several, but the BLS API outage is particularly relevant for delay modeling.
In January 2025, a Kalshi market on monthly unemployment data relied on the Bureau of Labor Statistics API as its sole resolution source. The BLS API experienced a 4-day outage during the exact resolution window due to a government IT infrastructure migration. With no fallback data source specified in the rules, resolution was delayed 10 days until the API came back online.
SettleRisk's scoring engine would have assigned this market a risk score of 58 (HIGH tier), flagging the SINGLE_ORACLE_DEPENDENCY and EXTERNAL_DEPENDENCY drivers. The delay distribution for this market was modeled at p50 = 168 hours (7 days) and p90 = 480 hours (20 days). The actual 10-day delay fell squarely between p50 and p90 -- exactly where the model predicts most adverse outcomes will land.
The capital impact was significant: $850K locked for 10 extra days, translating to approximately $2,800 in opportunity cost at 12% APR. That may sound small in isolation, but this was a single position. Traders running portfolios of 20-50 similar positions face multiplicative exposure to this kind of event.
The lesson is structural: government data sources have no uptime SLA for public consumers. Any market that depends on a single government API without a fallback source carries inherent delay tail risk that should be priced into your positions. SettleRisk's risk scoring catches this automatically via the SINGLE_ORACLE_DEPENDENCY driver.
Delay Correlations Across Markets
When running a portfolio of prediction market positions, the delay distributions are not independent. A platform outage, regulatory action, or systemic dispute can simultaneously delay multiple markets. This correlation is the most dangerous aspect of settlement delay risk, because it strikes precisely when you most need liquidity.
Consider three categories of correlated delay events:
Platform-level outages. When Polymarket's UMA oracle system experiences congestion or when Kalshi's data ingestion pipeline goes down, every market on that platform is affected simultaneously. Your diversification across markets on the same platform provides zero protection against platform-level delay events.
Data source correlations. Markets that depend on the same underlying data source -- government economic releases, specific API endpoints, the same news organization's reporting -- will experience correlated delays if that source has issues. The BLS outage didn't just affect the unemployment market; it would have affected any Kalshi market resolving on BLS data during the same window.
Regulatory shock. A regulatory action that questions the legality or classification of certain prediction market contracts can freeze resolution across an entire category. This is the most extreme correlation scenario, and it maps directly to the tail of the delay distribution.
For portfolio construction, this means you should stress test your aggregate capital lockup assuming that all positions on a single platform experience p90 delays simultaneously. The p99 estimate for any individual market becomes your portfolio stress test for correlated events. Our pricing engine accounts for this by letting you model capital costs at the portfolio level.
Capital Planning with Delay Distributions
The delay distribution directly feeds into position sizing and capital allocation:
Position Sizing
If your fund targets 95% capital availability, you need to reserve capital for the p90 delay scenario. A market with a p90 of 168 hours means you should assume that capital is locked for a full week in your worst-case planning.
Opportunity Cost
At a 12% annual capital cost:
| Delay Scenario | Duration | Cost per $100K | |---------------|----------|----------------| | p50 (typical) | 48 hours | $66 | | p90 (stress) | 168 hours | $230 | | p99 (tail) | 504 hours | $690 |
These numbers matter most for large positions where even small bps costs compound.
Portfolio-Level Worked Example
Consider a fund running 10 prediction market positions across two platforms. Here is how delay-aware capital planning works in practice:
| # | Platform | Notional | Risk Tier | p50 (hrs) | p90 (hrs) | p90 Lockup Cost | |---|----------|----------|-----------|-----------|-----------|-----------------| | 1 | Polymarket | $150K | MEDIUM | 12 | 42 | $86 | | 2 | Polymarket | $80K | HIGH | 48 | 168 | $184 | | 3 | Polymarket | $200K | LOW | 8 | 24 | $66 | | 4 | Polymarket | $120K | HIGH | 72 | 240 | $395 | | 5 | Kalshi | $100K | LOW | 4 | 14 | $19 | | 6 | Kalshi | $90K | MEDIUM | 18 | 60 | $74 | | 7 | Kalshi | $250K | HIGH | 36 | 120 | $411 | | 8 | Polymarket | $60K | CRITICAL | 168 | 504 | $414 | | 9 | Kalshi | $180K | MEDIUM | 10 | 36 | $89 | | 10 | Polymarket | $75K | HIGH | 54 | 180 | $185 |
Total portfolio notional: $1.305M. Under the p50 (typical) scenario, total lockup cost is approximately $520. Under the p90 (stress) scenario, total lockup cost climbs to $1,923 -- roughly 15 bps on the portfolio. But in a correlated stress scenario where all six Polymarket positions hit p90 simultaneously, those positions alone account for $1,330 in lockup costs, and $685K in capital is frozen for a week or more.
The CRITICAL-tier position (#8) deserves special attention. SettleRisk's pricing engine would return do_not_quote: true for this market, indicating that the resolution risk is too high for any spread to adequately compensate. A disciplined capital allocator would either skip this market entirely or size it at a fraction of their normal position. See our pricing documentation for details on how do_not_quote thresholds work.
Using Delays for Position Entry Timing
Delay distributions are not just defensive tools for capital planning -- they can inform offensive position entry decisions. When you understand the delay risk profile of a market, you can time entries to maximize your risk-adjusted return.
Pre-resolution window entries. As a market approaches its expected resolution date, the delay distribution becomes increasingly relevant. If a market has a p90 of 168 hours, entering a position 7+ days before expected resolution gives you time to exit before the delay risk materializes. Entering 24 hours before resolution means you are fully exposed to the tail.
Post-dispute entry. When a market enters dispute and prices crash due to uncertainty, the delay distribution tells you how long capital will likely be locked. If the p50 delay post-dispute is 14 days and the price has dropped 15%, you can calculate whether the expected return justifies the lockup cost. This is where SettleRisk's pricing engine is most valuable -- it gives you the exact bps cost of entering a disputed market.
Platform migration timing. When one platform has significantly higher delay risk for a particular market type (e.g., economic data markets on Polymarket vs. Kalshi), the delay distribution can inform which platform to trade on. Lower delay risk means lower capital costs, which means tighter effective spreads and better returns.
Delay-informed limit orders. If you are willing to enter a position but only at a price that compensates for delay risk, you can use the capital_lockup_cost_bps output to set your limit price. A market trading at $0.65 with 42 bps of lockup cost should be entered at $0.6458 or lower to break even on the delay risk alone.
Delay and Pricing Integration
The delay distribution feeds directly into SettleRisk's pricing engine. Here is how to use it in both Python and TypeScript:
from settlerisk import SettleRiskClient
client = SettleRiskClient(key_id="vx_...", secret="...")
pricing = client.price({
"platform": "polymarket",
"platform_market_id": "0xabc",
"mid_price": 0.65,
"position_side": "YES",
"position_notional_usd": 100000,
"annual_capital_cost_apr": 0.12
})
# capital_lockup_cost_bps incorporates the expected delay
print(f"Lockup cost: {pricing['capital_lockup_cost_bps']} bps")
print(f"Adjusted fair price: {pricing['adjusted_fair_price']}")
print(f"Do not quote: {pricing['do_not_quote']}")
import { SettleRiskClient } from "@settlerisk/sdk";
const client = new SettleRiskClient({
keyId: "vx_...",
secret: "...",
});
const pricing = await client.price({
platform: "polymarket",
platformMarketId: "0xabc",
midPrice: 0.65,
positionSide: "YES",
positionNotionalUsd: 100_000,
annualCapitalCostApr: 0.12,
});
// capital_lockup_cost_bps incorporates the expected delay
console.log(`Lockup cost: ${pricing.capitalLockupCostBps} bps`);
console.log(`Adjusted fair price: ${pricing.adjustedFairPrice}`);
console.log(`Do not quote: ${pricing.doNotQuote}`);
The capital_lockup_cost_bps output uses the expected delay (the mean of the lognormal distribution, which is always higher than the median) to compute your actual opportunity cost. This is computed as:
expected_lockup_years = expected_delay_hours / 8760
capital_lockup_cost_bps = annual_capital_cost_apr * expected_lockup_years * 10000
For a market with an expected delay of 72 hours and a 12% APR capital cost, this yields approximately 99 bps -- a non-trivial cost that most traders ignore entirely.
Key Takeaways
- Delays are right-skewed -- the median understates the mean, and the tail is where capital gets trapped
- Use p90 for planning -- the p50 is the happy path; the p90 is what your capital allocation should be based on
- The math is transparent --
mu = ln(median_hours), sigma adjusts for ambiguity and oracle risk, and percentiles follow directly from z-scores - Delays compound across positions -- portfolio-level analysis needs correlated delay modeling, especially within a single platform
- Price the delay into your spreads -- if you're not charging for capital lockup risk, you're giving it away for free
- Use delays offensively -- delay distributions inform entry timing, platform selection, and limit order placement
Start Modeling Your Delay Risk
Every position you hold without understanding its delay distribution is a position where you are accepting unpriced risk. SettleRisk's API gives you p50, p90, and p99 delay estimates for any market on Polymarket or Kalshi in a single call -- along with the pricing adjustments you need to trade profitably around that risk.
Explore our methodology to understand the full scoring and delay framework, review real-world examples on our case studies page, or go straight to our pricing page to find a plan that fits your trading volume. If you want to see the delay distribution for a specific market before committing, our live demo lets you evaluate any market with no account required.