Lognormal Settlement Delay: A Market Maker's Practical Guide

Executive Summary

When a prediction market goes to resolution, the median time-to-cash is rarely the time-to-cash you should be worried about. The distribution of settlement delays in real prediction markets is heavy-tailed and lognormal: a 4-hour median, a 30-hour p90, and a 200-hour p99 is not an unusual profile. Quoting against the median guarantees you mis-price the capital cost on a meaningful fraction of contracts.

This guide explains why lognormal is the right model, how SettleRisk parametrizes it, and how to plug p50/p90/p99 estimates into a market-making book without hand-waving the carrying cost.

Core Concept

Settlement delay in a venue like Polymarket or Kalshi is the time between when an underlying event resolves and when proceeds settle to your account. The components include:

Detection lag — how quickly the venue's oracle layer registers the outcome
Challenge window — UMA optimistic-oracle bond-and-challenge period, or Kalshi's internal review window
Distribution lag — actual settlement payout processing

Each component is lower-bounded (you cannot resolve faster than the oracle protocol allows) and upper-bounded only by operational hard limits (UMA's escalation game can stretch to many days in adversarial cases). That asymmetry is what makes a lognormal a good fit: log of delay is roughly normal because the upper tail compounds across components.

SettleRisk parametrizes the distribution with two numbers:

mu    = ln(median_hours)
sigma = base_sigma * (1 + ambiguity_score) * (1 + spof_count)

ambiguity_score is in [0, 1] and comes from the LLM extraction layer. spof_count is the number of single-point-of-failure dependencies flagged by the driver taxonomy. The p50/p90/p99 estimates are then:

p50 = exp(mu)
p90 = exp(mu + 1.282 * sigma)
p99 = exp(mu + 2.326 * sigma)

Worked Example

A Kalshi market on "Will the next CPI print exceed 3.5%?" has the following SettleRisk delay block:

"expected_delay": {
  "median_hours": 6.0,
  "p90_hours": 42.0,
  "p99_hours": 168.0,
  "mu": 1.7918,
  "sigma": 1.5184
}

Median is 6 hours — basically the BLS release window plus internal Kalshi review. But the p99 is 168 hours, a full week. Why? Because if BLS has a publication anomaly or revises the print within 30 days, the entire resolution flow can be re-opened.

A market maker who quoted assuming a 6-hour median capital lockup is mispricing the 1-in-100 case where the position is locked for a week. Across hundreds of similar markets, that 1% tail dominates the realized PnL drag.

The right formulation:

import math
from settlerisk import SettleRiskClient

client = SettleRiskClient(api_key="sk-...")
delay = client.get_expected_delay("kalshi", "cpi-3p5-2026")

cost_of_funds_annual = 0.055  # 5.5% blended cost of capital
hourly = cost_of_funds_annual / (365 * 24)

# Carrying cost in basis points at each delay quantile
for label, hours in [("p50", delay.p50_hours), ("p90", delay.p90_hours), ("p99", delay.p99_hours)]:
    bps = hours * hourly * 1e4
    print(f"{label}: {hours:&gt;6.1f} h  carrying cost {bps:&gt;6.2f} bps")

p50:    6.0 h  carrying cost   0.38 bps
p90:   42.0 h  carrying cost   2.64 bps
p99:  168.0 h  carrying cost  10.55 bps

A market maker quoting purely on p50 leaves ~10 bps of carrying cost unpriced on the worst-case path. Across a book that touches thousands of markets a year, that compounds.

The same call in TypeScript:

import { SettleRiskClient } from "settlerisk";

const client = new SettleRiskClient({ apiKey: "sk-..." });
const delay = await client.getExpectedDelay("kalshi", "cpi-3p5-2026");

const hourlyCOF = 0.055 / (365 * 24);
const quantiles: Array<["p50" | "p90" | "p99", number]> = [
  ["p50", delay.p50Hours],
  ["p90", delay.p90Hours],
  ["p99", delay.p99Hours],
];

for (const [label, hours] of quantiles) {
  const bps = hours * hourlyCOF * 1e4;
  console.log(`${label}: ${hours.toFixed(1)} h carrying cost ${bps.toFixed(2)} bps`);
}

Implementation Notes

The right quantile to quote against depends on your risk appetite and how much of your spread you are willing to give back to the long tail:

| Quantile | Use case | |----------|----------| | p50 | Loose internal pricing; client-facing skip | | p75 | Aggressive market making with active hedge | | p90 | Default for desk inventory pricing | | p99 | Quote-or-skip cutoff for thin books |

For high-volume MM strategies that touch the order book continuously, the right move is to set a hard do_not_quote cutoff at p99 > 500h. SettleRisk's pricing engine returns this flag directly via the pricing endpoint.

Cache the delay block separately from the score. Delays drift slowly across rule versions — they are dominated by venue-level operational parameters that change quarterly, not weekly. A 1-hour TTL on expected_delay is fine; the aggregate_risk_score may need 15 minutes.

Failure Modes

1. Quoting against the median. Across a portfolio, the long tail dominates realized PnL drag. Use p90 or p99 in your inventory pricing, not p50.

2. Treating delay and risk score as the same input. They reflect different things. A LOW-tier market on a niche topic can have a long delay because no one watches it for disputes. A CRITICAL-tier market with active media coverage may resolve quickly because everyone is paying attention.

3. Ignoring platform asymmetry. Polymarket's UMA flow has a hard 24-48h challenge window on the optimistic path. Kalshi has no equivalent. The shapes of the two distributions differ enough that one shared model is suboptimal.

4. Failing to record mu and sigma. If you only persist the quantiles, you cannot reconstruct the distribution for backtests. Always log mu and sigma alongside p50/p90/p99.

5. Forgetting the upper truncation. Real delays are bounded by venue policy (e.g. forced resolution at T+30 days on Kalshi). A naive lognormal puts probability mass beyond that bound. Truncate at the venue policy cap.

Checklist

[ ] Pull expected_delay block including mu, sigma, and quantiles
[ ] Pick a quoting quantile and document it (p90 is a sane default)
[ ] Cap with venue policy ceiling (e.g. 720h on Kalshi)
[ ] Multiply quantile by your hourly cost-of-funds to get bps
[ ] Persist mu and sigma alongside the quoted price for post-mortem
[ ] Subscribe to score.tier_changed and re-quote on change

Sources + Further Reading

SettleRisk methodology — full lognormal parameterization
Pricing engine — how delay feeds into capital lockup bps
Atkinson & Brown, Lognormal Distributions in Operational Contexts (1969)
UMA Optimistic Oracle docs — bond-and-challenge timing
CFTC final order on Kalshi event contracts — settlement window guarantees

Try it on a live market: a free key from /signup lets you pull expected_delay on any market in under 200ms.