Production latency

A strategy that only works against a zero-latency book fails first under production latency, so the simulator can add the delay the live exchange adds. The profile, netprof_kalshi_v1, holds the latency and jitter measured against production Kalshi from us-east-2, the region it’s served from. At the median, reads take 7 to 23 ms, and creating or canceling an order takes 12 to 13 ms against a quiet book. It’s off by default.

export RYSTIC_URL=$(rystic run kalshi-twin -d --port 0 --name latency --scenario empty_book --json | jq -r .data.url)
curl -s "$RYSTIC_URL/_rystic/network" | jq -c '{enabled, profile: .profile.id}'
# -> {"enabled":false,"profile":"netprof_kalshi_v1"}
curl -s -X POST "$RYSTIC_URL/_rystic/network" -d '{"enabled":true}'
curl -s "$RYSTIC_URL/_rystic/network" | jq -c '{enabled, post_order_p50_ms: .profile.endpoints["POST /trade-api/v2/portfolio/events/orders"].out.quantiles_ms.p50}'
# -> {"enabled":true,"post_order_p50_ms":12.8}
curl -s -X POST "$RYSTIC_URL/_rystic/network" -d '{"enabled":false}'

The profile covers nine endpoints. POST /_rystic/network with {"enabled":true} turns it on, and rystic run kalshi-twin --network on (RYSTIC_NETWORK=on) boots with it on.

GET /_rystic/network reads the active per-endpoint profile, and POST /_rystic/network changes it. The same route sets injected rejects, which the network profiles page covers. The network-fault scenarios (flaky_500, brownout_503, rate_limited and the rest) carry such a profile.

A network-fault scenario replaces the active profile when it loads, or at the times its tape names. The next reset or scenario brings back the profile from before it. A profile you post survives resets, and so does whatever a post leaves in place while a scenario’s profile is active. Latency and fault injection are on Pro and Enterprise.