Polymarket vs Kalshi for Bot Builders: API & Edge Compared

Kalshi hands you a REST endpoint, an API key, and a signed message header. Polymarket hands you an EIP-712 order struct, a proxy wallet, and a gas-free relayer you have to trust. That single difference — where the matching engine lives and who guarantees settlement — decides most of what your bot code will look like on each venue, and it's the first thing to understand before you pick one.

Both are order-book prediction markets. Both let you quote YES/NO contracts that settle at 0 or 1. From a distance they look interchangeable. They aren't. The mechanics diverge in ways that change your latency budget, your inventory risk, and the kind of edge you can realistically automate.

The order book: same shape, different plumbing

Polymarket runs a central limit order book (CLOB) off-chain for matching, then settles fills on Polygon. You post orders as signed messages; the operator matches them and submits the trade on-chain. Kalshi runs a fully centralized exchange — matching, custody, and settlement all inside their infrastructure, the same architecture as any equities venue, because Kalshi is a CFTC-regulated Designated Contract Market.

The practical consequence: on Kalshi your order is live the instant the exchange acknowledges it. On Polymarket there's a signing step and a relayer in the path. Your quote isn't a plain HTTP POST — it's a structured order you hash and sign with your wallet key, and getting the domain separator and struct exactly right is where most first bots break. If you want the full mechanics of that, the deep dive on Polymarket order signing walks through the EIP-712 fields and the common off-by-one on the expiration and nonce.

A minimal Polymarket order looks roughly like this with the official client:

from py_clob_client.client import ClobClient
from py_clob_client.clob_types import OrderArgs, OrderType

client = ClobClient(host, key=PRIVATE_KEY, chain_id=137,
                    signature_type=2, funder=PROXY_ADDR)
client.set_api_creds(client.create_or_derive_api_creds())

order = client.create_order(OrderArgs(
    token_id=YES_TOKEN_ID,
    price=0.61,           # probability, 6-decimal tick
    size=200,             # shares
    side="BUY",
))
client.post_order(order, OrderType.GTC)

Note signature_type=2 and the funder — that's the proxy-wallet setup. Your EOA signs, but funds sit in a Gnosis Safe or Polymarket proxy, and mixing those up is the classic "order accepted but never fills" bug.

Kalshi is closer to what you'd expect from a normal exchange:

# Sign the request with your RSA key, then:
POST /trade-api/v2/portfolio/orders
{ "ticker": "KXHIGHNY-25JUL01", "action": "buy",
  "side": "yes", "count": 200, "type": "limit",
  "yes_price": 61 }   # price in cents, integer 1–99

Prices are integer cents. No wallet, no gas, no signing struct — just an RSA-signed HTTP request. If you've built against Coinbase or Binance REST APIs, Kalshi will feel familiar in an afternoon. Polymarket takes longer because you're also dealing with Polygon, allowances, and a proxy.

Settlement: optimistic oracle vs the CFTC

This is the real fork in the road.

Polymarket resolves via UMA's optimistic oracle. A proposer asserts the outcome, a challenge window opens, and if nobody disputes with a bond, that outcome finalizes. It's permissionless and it usually works — but "usually" is doing load-bearing work. Ambiguous question wording, a late-breaking event, or a contested proposal can drag resolution out for days, and disputes have gone the "wrong" way relative to reality more than once. If you're holding inventory into resolution, that tail risk is real money. I've written up how the UMA optimistic oracle resolution works and where it bites, including the bond math you should model before quoting near expiry.

Kalshi settles by rule. The contract specifies a source, Kalshi determines the outcome, done. No challenge window, no bond, no dispute — but also no ambiguity for you to arbitrage, and a regulator who can halt a market. You trade oracle risk for counterparty-and-regulatory risk. For a market maker that's often the better trade; for someone hunting mispriced resolution edge, it removes a whole category of opportunity.

API access and the fine print

• Auth. Polymarket: wallet signature + derived API creds for the CLOB endpoints. Kalshi: API key with an RSA-signed request header per call.
• Rate limits. Kalshi publishes tiered limits and gates higher throughput behind account standing. Polymarket's CLOB has its own limits, and because matching is off-chain you can post and cancel quickly, but on-chain settlement adds a floor to how fast realized positions update.
• Cost of a cancel. On Kalshi, cancels are free API calls. On Polymarket, order placement and cancellation happen off-chain (cheap), but the fill settles on Polygon, so your effective cost model includes occasional gas and the relayer.
• Market data. Both offer WebSocket feeds for book updates. Polymarket's book is per-token (YES and NO are separate ERC-1155 tokens); Kalshi's is per-ticker with a yes/no side. Small thing, big impact on how you structure your internal book.
• Geography. Kalshi is US-regulated and US-accessible; Polymarket historically restricted US users. That alone dictates which venue is even an option for you.

Where the edge actually is

Different venues reward different bots.

Market making is viable on both, but the risk shape differs. On Polymarket you're quoting two ERC-1155 legs and managing inventory against oracle-resolution tail risk; on Kalshi you're quoting a cleaner cents book with rule-based settlement. Our CLOB market-making guide covers the inventory-skew and quote-refresh logic that applies to Polymarket specifically, and it's the backbone of how we build a Polymarket market-making bot.

Arbitrage is where Polymarket's structure opens doors. Because YES and NO are independent tokens, the pair can drift so that YES + NO ≠ 1.00, and the same real-world event sometimes trades across correlated markets. Automating that mispricing is a well-defined Polymarket arbitrage bot problem. Cross-venue arb between the two exchanges sounds tempting but the US/non-US split and settlement-timing mismatch make it operationally hard — the two books rarely clear against each other cleanly.

Spread capture on thin markets favors whoever quotes tightest without getting run over on news. A disciplined Polymarket spread bot that widens on volatility beats a naive fixed-spread quoter on both platforms, but Polymarket's longer-tail political and crypto markets tend to have more persistent spread to work with.

News-driven flow is Polymarket's sharpest edge. Its markets react to events before the price fully adjusts, and a Polymarket news bot that ingests a feed and repositions in seconds captures moves Kalshi's more efficient, US-headline markets close faster.

The short version

Pick Kalshi if you want clean REST semantics, rule-based settlement, and you're building a market maker or spread engine where regulatory certainty matters more than raw opportunity. Pick Polymarket if you want fatter spreads, real arbitrage structure, oracle-driven inefficiency, and you're comfortable with EIP-712 signing and Polygon plumbing. Most of the automatable edge — and most of the interesting engineering — sits on the Polymarket side, which is why that's where most of our build work lands.

If you're deciding which of these to build against, our team can scope a Polymarket market-making bot around your capital and latency constraints before you write a line of signing code.