Dome

What do they actually do

Dome provides a unified developer API and SDK that aggregates prediction‑market data from multiple venues—currently Polymarket and Kalshi—into one consistent interface. It offers live prices, trade history, candlesticks, historical order‑book snapshots, and cross‑venue “matching markets,” plus websockets/webhooks for real‑time updates and TypeScript/Python SDKs so developers can integrate once and query multiple markets from the same codebase (homepage, docs, SDK).

Today the product is focused on data access and developer tooling. A universal, cross‑venue trading/execution API is not documented as generally available; the team has signaled execution/agent capabilities as upcoming rather than fully live across all customers (docs, posts).

Who are their target customer(s)

• Quant traders and bot developers running strategies across Polymarket/Kalshi: They spend time writing and maintaining multiple venue adapters and normalizing schemas. They want clean, consistent live feeds and historical order‑book snapshots for backtests and bots (docs).
• Data scientists and researchers building models/backtests: They lose weeks cleaning mismatched trade/candle/orderbook data and often lack realistic historical order‑book states. They need analysis‑ready datasets and cross‑venue market matching (docs; example integration NautilusTrader).
• Dashboard/analytics product teams: They must maintain many connectors, normalize market identifiers, and juggle multiple websockets. They want one integration for matching markets, streaming, and history to power multi‑venue dashboards (docs).
• Market makers and liquidity managers: They need low‑latency, accurate order‑book snapshots and aggregated views of equivalent markets to monitor spreads and hedges across venues. Maintaining venue‑specific tools is costly (docs).
• Teams seeking turnkey cross‑venue execution: They want to write a strategy once and run it everywhere, but a vendor‑agnostic order‑placement API isn’t broadly available yet. Dome has signaled execution/agent features as a roadmap item, so these teams still need separate execution for now (docs; public posts).

How would they acquire their first 10, 50, and 100 customers

• First 10: Direct outreach to active Polymarket/Kalshi devs and YC network contacts; offer free API credits and 1:1 onboarding to wire their bots/analytics to Dome’s SDKs and orderbook‑history endpoints, then capture feedback and testimonials (docs, YC).
• First 50: Publish reproducible backtest notebooks and reference apps using unified feeds and historical order‑book snapshots, and secure partner integrations (e.g., NautilusTrader) to drive reciprocal referrals from their user base (docs, integration example).
• First 100: Improve self‑serve onboarding (docs, templates, webhook/websocket recipes), launch a referral/affiliate program for integrators, and run targeted developer channels (newsletters, Discord/X, hackathons) while converting pilots into paid plans and public case studies (SDK, docs).

What is the rough total addressable market

Top-down context:

Near‑term TAM is the global set of developers, trading teams, market makers, and analytics products that need unified prediction‑market data. If 10k–15k paying seats each spend $200–$500/month on data/infra, TAM spans roughly $24M–$90M annually (estimate).

Bottom-up calculation:

Assume ~1,200 potential org customers: 300 trading firms at ~$12k/yr, 200 market makers at ~$18k/yr, 400 analytics/research/data teams at ~$4k/yr, and 300 indie/prosumers at ~$1.2k/yr. That implies ≈$9M–$10M in near‑term, serviceable TAM (estimate).

Assumptions:

• Prediction‑market adoption continues to grow; more venues become relevant to aggregate.
• A mix of professional firms and indie builders are willing to pay for unified data, history, and streaming (not execution).
• ARPA ranges from $100–$1,500/month depending on segment and data depth/SLA.

Who are some of their notable competitors

• FinFeedAPI: Commercial API aggregating prediction‑market data (e.g., Polymarket, Kalshi) into a single feed; a direct alternative for unified access to live and historical data.
• Integrating each venue directly: Teams can build directly on venue APIs/websockets (e.g., Polymarket and Kalshi) to avoid a middle layer but must maintain multiple connectors and normalizations (Polymarket docs, Kalshi docs).
• Kaiko (as a class of general market‑data vendors): Institutional market‑data providers with unified REST/streaming and historical order‑book feeds for other asset classes; some teams use such vendors instead of a prediction‑market specialist.
• Metaculus (forecasting platforms): Community forecasting datasets and APIs that researchers sometimes prefer for probability estimates over raw trade/orderbook data.