Polymarket CLOB vs Kalshi API: Building a Resolution Bot

Both platforms let you trade the same event — "Will the Fed cut rates in September?" — but the machinery underneath is so different that a bot written for one is useless on the other. Polymarket is an on-chain central limit order book (CLOB) on Polygon, settled in USDC, with disputed outcomes arbitrated by UMA's optimistic oracle. Kalshi is a CFTC-regulated exchange in the US with a FIX gateway and a REST/WebSocket API, dollars in your bank, and outcomes resolved by an internal committee against a published rulebook. If you're building a resolution bot — one that takes positions as an event nears settlement and manages the payout — those differences decide whether you get paid on time or wait a week for an oracle dispute to clear.

Order entry and matching

Polymarket's CLOB is a hybrid: orders are signed EIP-712 messages you post to an off-chain matching engine, and only the fills settle on-chain through the CTF Exchange contract. You never pay gas to place or cancel an order, which matters because a market maker cancels far more than it fills. You sign an order, POST it, and the operator matches it:

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

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

order = client.create_order(OrderArgs(
    token_id=YES_TOKEN, price=0.62, size=250, side="BUY"))
client.post_order(order)

The gotcha: signature_type and funder. Polymarket routes most users through a proxy wallet (Gnosis Safe or the magic/email proxy), so the address holding your USDC is not the address signing orders. Get this wrong and every order silently rejects as unfunded. Budget half a day just getting allowances and the proxy relationship correct.

Kalshi is more conventional. You authenticate with an RSA-signed request header, then hit REST endpoints or the WebSocket for order books and fills. Serious flow goes through their FIX 5.0 gateway, which is what you want if you care about round-trip latency and deterministic order state. There's no wallet, no allowance, no proxy — you wire dollars in, and your buying power is a number on their ledger.

Fees

This is where the two diverge hard. Polymarket charges zero maker and zero taker fees on trades today; your costs are gas to deposit/withdraw USDC on Polygon (cents) and the spread. Kalshi charges a taker fee that scales with how close the price is to 50 cents — the formula is roughly 0.07 × contracts × price × (1 − price), rounded up. On a 50-cent contract that's about 1.75 cents per contract per side, which is brutal for high-frequency strategies and forces you to be a maker or to trade well away from the midpoint. A resolution bot that scalps the last few cents before settlement will get eaten alive by Kalshi's taker fee, whereas on Polymarket the same strategy only pays the spread.

Latency and reliability

Polymarket's off-chain book is quick to quote, but settlement is bounded by Polygon block times (~2s) and finality, and the operator is a single centralized matcher that can and does go into maintenance. Your bot needs to handle the matcher returning 5xx while the chain keeps moving. I treat Polymarket like any centralized venue with a chain settlement tail: reconcile fills against on-chain events, never trust the REST response alone.

Kalshi's FIX path gives you the tighter, more predictable latency and proper session-level heartbeats and sequence gaps to reason about. It's the more professional plumbing. The tradeoff is rate limits and the fact that you're one regulated entity's uptime away from being flat. If your infrastructure instincts come from CEX or DEX market making, the reasoning is similar to what we covered comparing Jito and bloXroute for landing Solana bundles — you're always trading raw speed against inclusion certainty.

KYC and access

Kalshi requires full KYC, a US residency check, and geofencing; the API is only as open as your verified account. That's a feature if you want clean tax reporting and bank rails, a wall if you're outside the US or want to run size anonymously. Polymarket blocks US persons and does lighter verification, and access is a wallet — which means your bot's opsec is your seed phrase, not a login. Neither is "better"; they serve different operators. If you're deciding which venue to build against before writing a line of code, this is exactly the kind of tradeoff worth a strategy consultation rather than discovering it three weeks into a build.

Resolution risk — the part that actually bites

Here's the difference that a naive backtest never shows you.

On Kalshi, resolution is fast and rule-bound. The exchange resolves against the source named in the contract's rulebook, usually within hours of the event, and disputes go through the exchange, not a token vote. Your capital is locked for a known, short window.

On Polymarket, settlement runs through UMA's optimistic oracle. Someone proposes an outcome, posts a bond, and if nobody disputes within the challenge window (commonly two hours), it finalizes. But if the outcome is ambiguous — think a "before X date" question that hinges on a technicality — anyone can dispute, escalating to a UMA token-holder vote that can take 48 hours or more. During that window your USDC is stuck, the market can't be redeemed, and the final answer is whatever UMA voters decide, which has surprised traders on genuinely contested markets. Your resolution bot must model this explicitly:

• Treat time-to-redemption as a distribution, not a constant.
• Discount positions in ambiguously-worded markets, and read the resolution source in the market metadata before sizing.
• Keep capital reserved so a stuck settlement doesn't cascade into missed opportunities elsewhere.

I've seen a "sure thing" at 97 cents get disputed and drift for two days. The edge was real; the funding assumption was wrong. That's not a code bug, it's a mechanism you have to price in — and it's the single most common thing teams miss. Before you deploy real size, having someone audit the settlement and edge-case handling is cheap insurance against a locked-capital blowup.

Which one to build on

Pick Kalshi if you want regulated rails, dollar settlement, predictable resolution timing, and you can stomach the taker fee — it's the better home for lower-frequency, thesis-driven bots. Pick Polymarket if you want zero trading fees, deeper liquidity on crypto and politics markets, and you can engineer around proxy wallets and UMA's dispute latency. Many desks run both and arbitrage the spread between them when the same event trades at different implied probabilities, which is its own build with its own reconciliation headaches — closer in spirit to running two LP venues at once, like the Meteora vs Orca liquidity comparison, than to a single-venue strategy. And as with the managed-bot-versus-custom tradeoff on Solana, the off-the-shelf clients get you a demo, but the money is in the plumbing they don't handle.

If you're weighing which venue your capital and latency profile actually fits, our strategy consultation will save you the three-week detour of finding out the hard way.