The trading layer is where your prediction market agent connects intent to execution. Layer 1 gives it an identity. Layer 2 gives it a funded wallet. Layer 4 tells it what to trade. Layer 3 handles the mechanics: querying available markets, reading order books, placing bets, managing positions, and streaming real-time data.

This guide is the overview of everything that happens at the trading layer. For the full endpoint-by-endpoint API reference, see Prediction Market API Reference. For how all four layers fit together, see The Agent Betting Stack.


The Three Platforms

As of March 2026, three platforms matter for prediction market agents. Each has a different architecture, regulatory posture, and API surface.

PolymarketKalshiDraftKings Predictions
TypeDecentralized (hybrid CLOB)Centralized (CFTC-regulated)Centralized (state-regulated sportsbook)
SettlementUSDC on PolygonUSD (bank transfer / wire)USD (DraftKings account balance)
Order BookOff-chain CLOB, on-chain settlementCentralized matching engineInternal (no public order book)
Trading APIFull CLOB API + WebSocketREST API v2 + WebSocket + FIX 4.4Limited — no public trading API for agents
Python SDKpy-clob-clientkalshi-pythonNone
CLI Toolpolymarket (Rust, Homebrew)NoneNone
Auth (Trading)API key + HMAC (L2 headers)API key + RSA-PSS signatureOAuth (consumer-facing)
Market CoveragePolitics, crypto, sports, culture, scienceEconomics, weather, politics, sports, cryptoSports, entertainment
Volume (Daily)Highest among prediction marketsGrowing, strong in regulated eventsVery high (sportsbook), lower for predictions
US AccessGray area (no US block, no explicit license)Fully licensed (CFTC DCM)Licensed per state
Agent ReadinessProduction-ready. Full API, SDKs, CLI.Production-ready. Full API, SDKs.Not agent-ready. No trading API.

Bottom line: Polymarket is the primary platform for agent trading due to API maturity and volume. Kalshi is the choice when US regulatory clarity matters. DraftKings Predictions is relevant for its retail audience and as the sportsbook side of cross-market arbitrage, but lacks agent-accessible trading APIs.


How Agent Trading Works

A prediction market trade follows the same core flow regardless of platform:

  1. Discover markets — query available events, filter by category or keyword
  2. Read prices — fetch the current order book or last trade price for a specific outcome
  3. Place an order — submit a limit or market order specifying side (YES/NO), quantity, and price
  4. Monitor the position — track open orders, fills, and P&L
  5. Exit — sell the position before resolution or hold until settlement

The mechanics differ by platform. On Polymarket, the agent signs EIP-712-typed orders and submits them to the CLOB. On Kalshi, the agent sends RSA-PSS-signed REST requests. But the logical flow is identical.

Polymarket: CLOB Trading

Polymarket uses a hybrid Central Limit Order Book. Orders are matched off-chain for speed, but settlement happens on-chain on Polygon. Agents interact through three surfaces:

  • Gamma API (gamma-api.polymarket.com) — market browsing, search, metadata
  • CLOB API (clob.polymarket.com) — order placement, order book, positions, balances
  • WebSocket (ws-subscriptions-clob.polymarket.com) — real-time price and order updates

The Polymarket CLI (written in Rust, installable via Homebrew) wraps these APIs for quick terminal-based trading. For production agents, the Python SDK (py-clob-client) or TypeScript SDK (@polymarket/clob-client) provide full programmatic access.

Deep dives:

Kalshi: REST API Trading

Kalshi is a CFTC-designated contract market (DCM). All trading happens through a centralized REST API with an optional WebSocket for streaming and FIX 4.4 for institutional connectivity. Authentication uses API keys with RSA-PSS signatures.

Kalshi trades in USD cents — a YES share at 65 means $0.65. Agents need a funded Kalshi account (via bank transfer), not a crypto wallet.

Deep dive: Kalshi API Guide

DraftKings Predictions

DraftKings Predictions offers event contracts through a regulated sportsbook interface. Markets cover sports and entertainment outcomes. The platform reaches millions of existing DraftKings users but does not expose a public trading API for automated agents.

For agents, DraftKings Predictions is most relevant as the other side of a cross-platform arbitrage strategy — compare DraftKings prediction prices against Polymarket or Kalshi, and trade the mispricing on the platform with API access. See Cross-Market Arbitrage for the full strategy.

Platform overview: DraftKings Predictions


Order Types and Execution

Order TypePolymarketKalshiNotes
Limit (GTC)Yes — defaultYesGood-til-canceled. Sits on the book until filled or canceled.
Limit (GTD)YesNoGood-til-date. Auto-cancels at specified timestamp.
Fill-or-Kill (FOK)YesNoFills entirely or cancels entirely. No partial fills.
MarketVia aggressive limitYesOn Polymarket, simulate a market order by pricing above/below the book.
Stop-LossNo (build it yourself)NoNeither platform offers native stop-loss. Agents must implement monitoring + order logic.

For agents, limit GTC orders are the default. They give you price control and sit on the book until filled. Market orders (or aggressive limits) are used when speed matters more than price — for instance, when an arbitrage window is closing.


Unified APIs: Trading Across Platforms

If your agent operates on multiple platforms, you face the integration tax: different auth schemes, different data formats, different SDKs. Three unified APIs address this.

DomepmxtOddsPapi
StatusAcquired by Polymarket (Feb 2026)Open-source, activeActive, growing
ArchitectureHosted API (single key)Client-side libraryHosted API
PlatformsPolymarket, Kalshi, LimitlessPolymarket, Kalshi, othersPrediction markets + 350+ sportsbooks
Trading SupportPreviously yes, future TBDRead + Trade (per exchange)Read-only
Best ForLegacy integrationsMulti-platform agentsCross-market arbitrage data

For new projects: use pmxt if you need multi-platform prediction market trading, or OddsPapi if you need to compare prediction market prices against sportsbook lines.

Deep dive: Dome vs pmxt vs OddsPapi


Agent Execution Patterns

Pattern 1: Single-Platform Direct SDK

The simplest pattern. Your agent uses one platform’s SDK directly.

Best for: Agents focused on Polymarket or Kalshi. Maximum control, lowest latency, full API access.

Pattern 2: CLI-Based Execution

Use the Polymarket CLI for rapid prototyping. The CLI wraps the CLOB API and handles authentication, order placement, and position queries from the terminal.

Best for: Prototyping, manual spot-checks, quick one-off trades alongside an automated system.

Pattern 3: Multi-Platform via Unified API

Use pmxt or a custom abstraction layer to normalize operations across Polymarket and Kalshi. Your intelligence layer outputs a trade signal; the trading layer routes it to the optimal platform.

Best for: Cross-platform arbitrage, multi-venue market making, agents that need the best price regardless of platform.

Pattern 4: Cross-Market Arbitrage

Compare prediction market prices against each other (Polymarket vs Kalshi) or against sportsbook lines (via OddsPapi). Execute on the platform with API access when a mispricing is detected.

Best for: Agents that exploit price discrepancies. See Cross-Market Arbitrage for the full strategy and architecture.


Choosing Your Trading Stack

If you need…Use
Maximum volume and market coveragePolymarket CLOB API
US regulatory complianceKalshi REST API
Multi-platform trading from one codebasepmxt
Cross-market arbitrage data (prediction markets + sportsbooks)OddsPapi
Fastest path to a working tradePolymarket CLI
Complete endpoint-by-endpoint referencePrediction Market API Reference

For how the trading layer connects to wallets (Layer 2) and intelligence (Layer 4), see The Agent Betting Stack.