API + MCP live · talk to usAPI + MCP live on Kalshi and Polymarket · book 20 minutes with the founder →

// GLOSSARY

The vocabulary, defined with worked examples.

54 terms across markets, execution, APIs, agents, and risk — each grounded in how it actually shows up on Kalshi and Polymarket.

// MARKETS & CONTRACTS

Binary contract

A contract that pays a fixed amount (usually $1) if an event happens and nothing if it doesn't. Prediction-market prices are therefore probabilities: a 42¢ yes contract implies a 42% market-assigned chance.

CLOB (central limit order book)

A central limit order book matches buyers and sellers by price-time priority. Polymarket runs a CLOB with off-chain matching and on-chain settlement; Kalshi runs a traditional exchange CLOB.

Event market

A market (or group of markets) tied to a real-world event — an election, a Fed meeting, a game. On Kalshi, an event groups related binary markets under one umbrella; Polymarket similarly groups outcome markets under an event page.

Expiry / expiration

The time a contract stops trading and awaits settlement. Distinct from resolution: a market can close (no more trading) before the outcome is known. Orders can also carry their own expirations, e.g. good-till-cancel vs time-limited.

Oracle resolution

How a market learns the real-world outcome it settles on. Kalshi resolves via its own rules and cited sources as a regulated exchange; Polymarket resolves through UMA's optimistic oracle, where proposed outcomes can be disputed onchain.

Order book

The live list of resting buy (bid) and sell (ask) orders for a market at each price level. Book depth determines how much size can trade before the price moves — the central constraint in thin prediction markets.

Settlement

The final exchange of value once a market resolves: winning contracts pay out ($1 on Kalshi; redeemable outcome tokens in USDC on Polymarket), losing ones expire at zero. The step where paper P&L becomes cash — and where timing risk lives.

Spread (bid-ask spread)

The gap between the best bid and best ask — e.g. 42¢ bid / 45¢ ask is a 3¢ spread. The immediate cost of trading now rather than waiting: takers pay it, makers earn it. In thin prediction markets, spreads are often wide relative to any edge.

UMA oracle

The optimistic oracle Polymarket uses for resolution: a proposer posts the outcome with a bond; if unchallenged through a dispute window it stands, and disputes escalate to a vote of UMA token holders. "Optimistic" = assumed correct unless challenged.

Yes / No side

The two sides of a binary market. Yes and no prices are complements — they sum to $1 at fair value — so buying no at 58¢ is economically the mirror of selling yes at 42¢. Each side has its own book presentation, and liquidity can differ between them.

// EXECUTION & FEES

Arrival price

The market price at the moment you decide to trade — usually the mid or the touch when your order arrives. Execution quality is measured against it: the gap between arrival price and your fee-adjusted fill price is your implementation cost.

Best execution

The obligation (or discipline) of executing orders on the terms most favorable to the order's owner — best net price after fees, across available venues. In prediction markets it means comparing Kalshi and Polymarket fee-adjusted, not just quoted prices.

Execution receipt

A per-fill record proving execution quality: what each venue quoted at order time, the fee-adjusted price you got, and the measured difference. Turns "we get you better prices" from a marketing claim into a number you can audit on every trade.

Fee-adjusted net price

The all-in price per contract after fees: fill price plus taker fees (and any gas) for buys. The only number that makes Kalshi and Polymarket comparable, since one charges a formula-based taker fee and the other mostly charges no exchange fee.

Fill

An execution: some or all of your order matching against the other side of the book. One order can produce many fills at different prices. Fills — not orders — are what you reconcile positions, fees, and P&L against.

IOC order (immediate-or-cancel)

An order that fills whatever it can against the book right now and cancels the remainder — it never rests. The standard way to take liquidity with a price cap: you get immediacy without leaving a stale order behind.

Limit order

An order with a worst acceptable price: buy at your limit or lower, sell at your limit or higher. It fills immediately if the book allows, otherwise rests. The default order type for anything automated — it bounds what you can pay.

Maker / taker

A maker adds liquidity by resting an order in the book; a taker removes it by crossing the spread. Fee schedules usually charge takers and reward (or don't charge) makers — on Kalshi, resting orders generally pay no trading fee.

Maker rebate

A payment (or fee discount) some exchanges give makers for providing liquidity. On Kalshi and Polymarket the standard schedules mostly feature zero maker fees rather than cash rebates — though venues run liquidity/rewards programs that can function like rebates.

Market order

An order to fill immediately at whatever the book offers, with no price limit. Maximum immediacy, zero price protection — in thin prediction markets it can sweep several levels and fill far from the quote. Prefer marketable limits or IOC with a cap.

Partial fill

When only part of your order executes — the book didn't have enough size at your price. The remainder rests, cancels (IOC), or is rejected, depending on order type. Bots must handle partials as the normal case in thin markets, not an edge case.

Passive post

Placing an order that rests in the book (at or inside the touch) instead of crossing the spread — trading immediacy for price. You earn the spread and typically pay maker (often zero) fees, at the cost of uncertain and delayed fills.

Post-only order

A limit order that must rest — if it would execute immediately (cross the spread), the venue rejects or re-prices it instead of filling. Guarantees maker treatment: you'll never accidentally pay a taker fee because the book moved as you sent.

Price impact

How much your own order moves the price — consuming book depth pushes your later fills to worse levels and often shifts the quote after you trade. In thin prediction markets, impact from even modest size can exceed the spread itself.

Resting order

A limit order sitting in the book waiting for the other side to come to it. Resting orders are the liquidity everyone else trades against; they earn maker treatment (often zero fees on Kalshi) but carry queue, timing, and adverse-selection risk.

Sliced order

A parent order broken into smaller child orders executed over time or across venues, so no single slice consumes enough depth to move the price. The basic defense against price impact in thin books; TWAP is the simplest schedule.

Slippage

The difference between the price you expected and the price you actually got — from crossing the spread, walking book levels, or the market moving mid-execution. In thin prediction markets it's routinely the largest trading cost.

Smart order routing (SOR)

Automatically choosing where and how to execute an order across venues — comparing Kalshi and Polymarket books fee-adjusted for your size, then splitting or directing the order to whichever combination yields the best net price.

Sweep the book

Executing through multiple price levels at once — taking all available liquidity up (or down) to some price. Buys certainty of fill at the cost of walking the book: each successive level fills worse, and the market is left visibly moved.

Taker fee

The fee charged when your order removes liquidity. Kalshi's standard formula: 0.07 × contracts × price × (1 − price), rounded up to the next cent — peaking near 50¢. Polymarket charges no exchange trading fee on most markets.

TWAP (time-weighted average price)

Both a benchmark (the average price over a window) and an execution style: slicing an order into equal pieces at regular intervals so your average fill tracks the period's average price instead of one moment's thin book.

Worked order

An order executed patiently by algorithm on your behalf: posted passively, re-priced as the market moves, sliced across time and venues, escalating to taking only when needed. How size gets filled in thin books without paying sweep prices.

// APIS & INFRASTRUCTURE

API key signing

Authenticating API requests by signing them with a private key rather than sending a shared secret. Kalshi signs requests with an RSA private key; Polymarket orders are EIP-712 signatures from a wallet key. The venue verifies the signature, and the key never travels.

CLOB operator

The party that runs a CLOB's matching engine. On Polymarket, the operator matches signed orders off-chain and submits matched trades for on-chain settlement — a hybrid model: non-custodial settlement, but matching depends on the operator being live and honest.

Condition ID

Polymarket's onchain identifier for a market's resolution condition — a 0x-prefixed hash from the conditional tokens framework. Each market has one condition ID; each outcome within it has its own token ID. The key you join metadata and orders on.

EIP-712

An Ethereum standard for signing typed, structured data instead of opaque byte blobs. Polymarket CLOB orders are EIP-712 messages: the fields you sign (token, price, size, expiration) are exactly the terms that can settle onchain.

Gamma API

Polymarket's public metadata API (gamma-api.polymarket.com): markets, events, slugs, condition IDs, and token IDs, no authentication required. The discovery layer you query before sending orders to the separate CLOB API at clob.polymarket.com.

Idempotency key

A unique client-generated ID sent with an order so that retries don't create duplicates. If the first request succeeded but the response was lost, resending with the same key returns the original order instead of placing a second one.

Rate limit

A cap on how many API requests you may send per time window. Exceeding it returns errors (often HTTP 429) and, if abused, can get keys restricted. Well-built bots budget requests, batch reads, and prefer WebSockets to polling.

REST API

The request/response HTTP interface a venue exposes: fetch markets, read books, place and cancel orders. Kalshi's trade API and Polymarket's Gamma + CLOB APIs are REST; pair with WebSockets for streaming and keep REST for actions and snapshots.

Series ticker

Kalshi's identifier for a recurring family of markets — e.g. one series for monthly CPI releases. Series contain events (each release), which contain markets (each strike). Filtering the API by series ticker is the efficient path to recurring data.

Token ID / ERC-1155

Polymarket outcome shares are ERC-1155 tokens on Polygon; each outcome (yes, no) in a market has its own token ID. Orders on the CLOB are placed against token IDs, and winning tokens redeem for $1 of USDC at settlement.

Unified market ID

One identifier for one real-world question across venues — mapping a Kalshi ticker and a Polymarket condition ID to a single mkt_ ID. The prerequisite for cross-venue routing, price comparison, and arbitrage without hand-maintained lookup tables.

WebSocket feed

A persistent connection over which the venue pushes live updates — book changes, trades, fills — as they happen. The right way to consume market data: lower latency than polling REST and no rate-limit burn per update.

// AI AGENTS

AI trading agent

An LLM-driven agent (Claude, Codex, etc.) that researches markets and places orders through tools — typically an MCP server or REST API — rather than a human clicking a UI. Safe deployment requires server-side risk limits the agent cannot override.

MCP (Model Context Protocol)

An open protocol that lets AI models use external tools and data through a standard interface. An MCP server exposes typed tools (e.g. search_markets, place_order) that clients like Claude can call — the standard way to give an AI agent trading capability.

MCP tool

A single callable capability an MCP server exposes to AI models — a name, a description the model reads, and a JSON schema for arguments. Good trading tools are narrow and validated: place_order with typed fields, not execute_anything.

// RISK & CUSTODY

Envelope encryption

Encrypting data with a unique data key, then encrypting that data key with a master key. Compromise of one stored secret doesn't expose the rest, and the master key can live in an HSM/KMS. A standard pattern for storing users' exchange API keys.

Kill switch

A control that immediately halts all trading — cancelling open orders and blocking new ones — enforced server-side so a runaway bot or misbehaving AI agent can't keep trading. The last line of defense in any automated setup.

Non-custodial

An arrangement where a service never takes control of your funds or keys. Polymarket settlement is non-custodial (positions live in your wallet); services that hold encrypted venue keys and act only on your instruction occupy a middle ground worth understanding.