Dome vulnerable to API restrictions
Dome
Dome is strongest when prediction markets behave like open infrastructure, not closed apps. The product only works because it can read market data, map the same event across venues, and route orders to whichever platform has the best price or depth. That makes Dome less like a standalone exchange and more like a middleware layer sitting on top of Polymarket and Kalshi, so any change in API terms, rate limits, or partner priorities hits the core product immediately.
-
Dome’s current workflow depends on platform level access at a very literal level. It reads directly from Polymarket’s on chain and API based data, pulls from Kalshi’s APIs, standardizes both into one schema, then uses that merged view for analytics, market matching, and order routing. If one side closes, coverage and execution quality both drop.
-
The risk is real because the largest venues are also becoming full stack distributors themselves. Kalshi has official API docs, developer agreements, media data partnerships, and distribution through Robinhood. Polymarket has public docs, SDKs, a builder program, and its own incentives for developers. As these platforms become the default liquidity hubs, they have more reason to keep builders close and control the interface.
-
At the same time, open access is part of why Dome exists at all. Prediction market operators are chasing volume, and broader integrations can send them more order flow. That creates a familiar exchange dynamic where upstream platforms want third party distribution until they are big enough to prefer direct relationships or tighter partner control.
The direction of travel is toward a few major exchanges becoming the system of record for liquidity, with aggregators fighting to stay one layer above them. Dome’s long term leverage will come from owning the developer workflow, normalization layer, and routing logic deeply enough that platforms still see it as a volume source rather than a replaceable wrapper.