Intro
Somewhere in the last hour of a college football Saturday in October 2025, a Kalshi user watched their resting order get filled while they couldn't do anything about it. The app that would have let them cancel or adjust the order was down, locked out along with roughly half the platform's users.
The order stayed live anyway, because the exchange's API never stopped working, and an automated trader on the other end of that API filled it at a price the retail user never got the chance to update.
Kalshi refunded the affected users afterward. That doesn't undo the moment itself, watching your own position move because the tool you needed wasn't there.
That's the kind of failure marketing decks don't prepare you for, because it's never described as a bug. It shows up as an outage, or a delay buried in a status update.
This series has already made the case that sports puts more pressure on trading infrastructure than any other category in this boom. What follows is the diligence version of that argument, four things worth checking in any exchange before trusting it with size.
Order Book Resilience at a Live Event
The true test of an order book is never a scheduled, middle-of-the-night maintenance window. The test is what happens when a sudden, massive data spike hits the system at a moment nobody chose.
During Super Bowl 55, five separate sportsbook operators ran into technical failures clustered around kickoff, and one Nevada operator couldn't accept bets at all in the ten minutes before the game started. That wasn't one company's bad night. It was five platforms hitting the same wall at the same moment, because the wall was the kickoff itself.
An uptime figure that's never been tested against a real discontinuity is just an average, and averages don't describe what happens at the one moment that decides whether the exchange is any good.
Source: Unplanned Outages During Super Bowl Place Damper On Extraordinary Demand For Mobile Sports Betting
What answering this actually looks like isn't a percentage on a status page, it's an order book that never leaves memory in the first place, tested against real load rather than an average day. STX for instance, has load-tested a single order book at 19,000 orders per second, full end to end through its public API as published in 'Inside the MCA', bots submitting real orders until the bots ran out of capacity before the system did. While that's a claim about one market and not a platform-wide guarantee, it's also a real number that has been stress-tested.
API Independence from the Consumer App
The Kalshi incident highlights a critical architectural reality: a retail trading app and a public API are often two completely separate systems.
One going down doesn't mean the other does. When a platform experiences a front-end crash, the retail app goes dark, but the programmatic API line frequently stays wide open.
That split isn't a flaw. Decoupling front-end and back-end systems is standard engineering. But it decides who bears the risk during a crisis.
Retail users without direct API access are frozen out of the market, while automated traders keep executing through the same outage. Whether a platform's reliability is really one reliability, or two, one fast lane for machines and one broken lane for everyone else, is rarely visible until the moment it matters.
This is exactly why institutional desks and serious market makers treat direct API access as non-negotiable before committing size to a venue. It isn't a preference for automation, it's insurance against a scenario every trader eventually runs into.
"the app is the thing that fails, and the only way to still act is to already have a line that doesn't depend on it."
STX runs two separate surfaces, a GraphQL REST API and a live socket API, sitting behind the same infrastructure rather than a fragile front end bolted onto something sturdier underneath. That's the right shape for keeping this kind of independence real rather than accidental.
Whether it holds under the conditions that hit Kalshi is a different question, nothing has forced that specific architecture to prove itself in public yet, the same way Super Bowl 55 and the Kalshi outage forced everyone else's hand.
The Ability to Exit Under Stress, Not Just Enter
Most reliability conversations focus on whether an order gets placed. The harder test is whether a trader can get out when they need to, and several well-resourced platforms outside sports trading altogether have failed at exactly that in public.
During the October 2025 crypto flash crash, market makers on Binance were locked out and unable to place risk-reducing orders, some for nearly two hours despite hundreds of attempts, while the exchange's interface froze and API connections lagged or failed outright.
Coinbase has gone offline eleven separate times in its history during major price moves, including two outages within a single week in 2020, one as bitcoin crashed 10 percent in thirty minutes, the other as it rallied 15 percent days earlier.
Binance and Coinbase aren't short on resources. Both are among the best-funded exchanges in the industry, and both failed anyway, right when traders needed to manage risk. Speed on the way in says nothing about what happens on the way out. Exiting under stress is a different problem, and it rarely shows up until someone's already stuck in it.
That gap matters most exactly when it's least affordable, a leveraged position, or one sized close to a stop. A trader isn't just inconvenienced by an inaccessible exchange during a crash, they're exposed to a loss that keeps compounding while the one tool that would let them reduce it simply doesn't respond. An entry failure costs you a trade. An exit failure can cost you the account.
Account Model: Funded Once, or Signed Per Order
This looks like a UX detail and functions as a reliability question. Crypto-native prediction markets that settle every order through an on-chain wallet signature have spent real time fighting their own infrastructure over it.
Developers building against Polymarket's V2 API documented, across at least six separate GitHub issues since its CLOB upgrade in April, that deposit-wallet accounts using the platform's own recommended signature flow had every order rejected. As detailed in the Polymarket V2 client tracker on GitHub, the failure was caused by a technical mismatch between how the SDK registers the API key and how it signs the order itself, a bug confirmed still open weeks later.
That's not a hypothetical inconvenience. It's a valid, funded account unable to trade, for reasons entirely disconnected from market conditions. For an active trader, that's not paperwork. It's a position sitting exposed while the one mechanism meant to manage it doesn't respond, not because the market moved against them, but because a signature validation step the account never should have depended on failed instead.
The two models carry genuinely different tradeoffs. A signature-based account gives a trader custody and verifiability an exchange-managed account cannot match. That's a genuine tradeoff, worth taking seriously rather than dismissing.
On the other hand, a funded account, closer to how regulated exchanges have operated for decades, trades some of that custody for removing signature validation as a point of failure entirely. Neither model is free. What matters is knowing which one a given venue uses, and what kind of failure that choice trades away.
STX runs the funded-account model specifically, fund once, clear compliance, and every order after that ties to the account with no signature required per trade.
That same structure has a second effect, one about integrity rather than uptime alone because a persistent, verified account makes bad actors, collusion, and market manipulation easier to catch, since every order traces back to an identity rather than a rotating wallet address.
STX operates as a regulated betting exchange, and treats anti-money laundering checks, KYC, and position limits as core infrastructure rather than something bolted on after the fact.
The Close
None of this requires trusting a claim at face value. Order book behavior under real load, the independence of the API from the consumer app, the ability to exit rather than just enter, and the structure of the account model, each of these tends to be invisible right up until the moment it isn't.
None of them show up on a pitch deck, and none of them show up in a normal week. They show up once, in the ten seconds nobody chooses, and by then it's not a diligence question anymore, it's already the outcome. Most exchanges never get asked. Fewer answer.
Building something interesting? We back founders shipping the next generation of crypto infrastructure.
Work with us →From Prop-AMMs to Liquidity Networks
Prop-AMMs showed that professional market-making logic can reach on-chain order flow. ElfomoFi is the live transition case toward a curator-based liquidity network.
Memecoins Need a Reputation Layer
fomo put public PnL, hold time, a trade thesis, followers, alerts and a buy button in one flow. Whether that reputation holds beyond memes is the open question.
