Prediction Market Execution.

Name: SimpleFunctions
Author: SimpleFunctions

Intents, triggers, routing, monitoring — for Kalshi and Polymarket.

Declare what you want done — market, side, size, price, trigger condition, expiry — and let the prediction market execution layer wait, risk-check, and route through your venue. Idempotent intents, condition-based triggers, audited status across both venues. Built for agents, operators, and institutional desks.

POST /api/intentsintent shape

Hedging·Prediction Market API·Institutional infrastructure

Realist oil painting in Edward Hopper urban-realism style — 1980s NYSE / CBOT open-outcry trading pit at peak hours

Open-outcry pit, 1980s — the chaos that resolves into trades.

Order lifecycle — seven steps

Every prediction market execution intent flows through the same lifecycle. The shape is constant; the policy in each step is the operator's.

01

Intent

Operator or agent declares: market, side, size, price, trigger, expiry

02

Trigger

Wait for the named condition — immediate, price level, time window, or monitored event

03

Risk check

Pre-trade checks against the operator-configured risk parameters (size, exposure, drawdown caps)

04

Venue route

Map normalized intent to Kalshi or Polymarket order shape; submit through the venue connection

05

Order

The actual venue order receipt — submitted, working, partial, filled

06

Fill / status

Status updates flow back: filled, partial, rejected, expired, cancelled

07

Monitor

Continuous watch for fill drift, price drift, or follow-up condition the operator wants surfaced

Intent shape

Ten fields define every prediction market execution intent. Anything not in this shape is not part of the contract — operator policy lives outside.

Field

Meaning

Example

marketId

Venue market ticker or Polymarket token id

KXRATECUT-26DEC31

venue

Execution venue

kalshi / polymarket

action

Buy or sell

buy

direction

YES / NO side or token direction

yes

targetQuantity

Contracts or units

25

maxPrice

Limit price in cents

49

triggerType

immediate · price_below · price_above · time · event

price_below

triggerValue

Numeric or temporal condition argument

0.49

expireAt

Intent expiry — ignore if condition never met

ISO datetime

idempotencyKey

Operator-supplied dedup key — same key = same intent

op-2026-04-30-abc

Status state machine

Every intent moves through a fixed set of states. Terminal states never transition. Subscribe to status changes to drive downstream agents and dashboards.

Status

Meaning

pending

Intent created, trigger condition not yet met

waiting

Trigger armed, watching market state

routing | expired

routing

Trigger fired; risk-checked; submitting to venue

working | rejected

working

Order accepted by venue, partially or fully open

partial | filled | cancelled

partial

Some contracts filled, the rest still working

filled | cancelled | expired

filled

Fully executed at the venue

— terminal —

rejected

Risk check failed or venue rejected the order

— terminal —

expired

expireAt elapsed before fill

— terminal —

cancelled

Operator or agent cancelled prior to fill

— terminal —

Create an intent

REST API and CLI both produce the same intent record — different interfaces, one audit log.

POST /api/intentsJSON

{
  "marketId":       "KXRATECUT-26DEC31",
  "venue":          "kalshi",
  "action":         "buy",
  "direction":      "yes",
  "targetQuantity": 25,
  "maxPrice":       49,
  "triggerType":    "price_below",
  "triggerValue":   0.49,
  "expireAt":       "2026-12-30T23:59:00Z",
  "idempotencyKey": "op-2026-04-30-abc"
}

CLI — same intentterminal

sf intent buy KXRATECUT-26DEC31 25 \
  --venue kalshi \
  --direction yes \
  --price 49 \
  --trigger price_below:0.49 \
  --expire 2026-12-30 \
  --idem op-2026-04-30-abc

sf intent watch op-2026-04-30-abc --json

SimpleFunctions vs raw venue API

What the venue owns, what SimpleFunctions adds. Most production agents use both — the venue for the order, SimpleFunctions for the workflow around it.

Raw venue (Kalshi / Polymarket)

SimpleFunctions execution layer

Authentication

Lives at the venue (Kalshi / Polymarket)

SimpleFunctions never custodies; you keep the venue relationship

Order shape

Venue-specific contract types and rules

Normalized intent shape across both venues

Triggers

Limit orders, GTC, immediate-or-cancel only

Price-below / price-above / time / event-condition triggers

Idempotency

Manual de-dup at the operator level

Idempotency key on intent — replay-safe by design

Status monitoring

Polling REST or venue WebSocket

Single status surface across venues, plus drift-watch hooks

Audit

Venue activity log

Every state transition logged with actor, time, reason

What this layer is not

Honest constraints. Read these before designing a strategy on top of intents.

Not a broker, exchange, custodian, FCM, or investment adviser

SimpleFunctions provides software, APIs, and workflow primitives. The user owns the venue account and credentials; orders execute at the venue.

Not a globally enforced risk-gate cascade — yet

Risk-check primitives exist and most execution paths run them; end-to-end verification across every live path is in progress. Treat risk checks as a pre-trade safety net the operator configures.

Not a fill guarantee

Fill quality depends on venue liquidity, order type, posted price, and market conditions. Intents declare what to attempt; the venue determines outcomes.

Not a substitute for venue API knowledge

Operators still need to understand venue-specific contract types, fee structure, and settlement rules. The execution layer normalizes the workflow, not the underlying contract semantics.

FAQ

What is a prediction market execution workflow?

A prediction market execution workflow is a software primitive for turning a market view into an auditable intent — market, side, size, price, trigger condition, expiry — then waiting for the trigger, performing a pre-trade risk check, routing through the user's venue connection, and monitoring status. The intent persists across restarts and survives the agent that created it.

Who is this for?

AI agents that need to delay an order until a price or event condition is met; operators running systematic strategies; institutional desks that need an auditable intent record before any order hits a venue; research workflows that simulate strategies before live deployment.

Does SimpleFunctions execute orders directly at Kalshi or Polymarket?

SimpleFunctions provides software, APIs, and workflow primitives. It is not a broker, exchange, custodian, FCM, or investment adviser. Orders route through the user's configured venue connection at Kalshi or Polymarket. The user owns the venue account and credentials.

What trigger types are available?

immediate (route now), price_below / price_above (wait for the venue price to cross a threshold), time (wait until a timestamp), and event (wait for a monitored upstream condition like a Fed announcement window). Triggers can be combined — for example, price_below within a time window.

How do risk checks work?

Pre-trade checks evaluate the intent against operator-configured risk parameters before the order is routed — typical checks include max position size per market, total notional exposure, daily loss caps, and venue-specific limits. Each operator configures their own risk profile; checks are pre-trade and conservative.

Are risk gates enforced on every live execution path?

Risk-check primitives exist and most execution paths run them; the team is in the process of verifying every live path end-to-end before describing this as a global guarantee. Today, treat risk checks as a pre-trade safety net the operator configures, not as a globally enforced cascade.

How does idempotency work?

Each intent carries an operator-supplied idempotencyKey. Posting the same key twice returns the same intent — the second call is a no-op. This makes retry-on-failure safe for agent loops and replayable for backtests.

What status updates does the system emit?

Intents move through pending → waiting → routing → working → (partial / filled / rejected / expired / cancelled). Each transition is timestamped and logged with the actor (operator user id, agent id) and the reason. Downstream agents and dashboards can subscribe to status changes.

Can an AI agent create and manage intents?

Yes. Agents create intents through the API or the SimpleFunctions CLI, attach triggers, and observe status updates. The intent layer is the contract between an agent's reasoning and the venue's execution; agents reason against intents, not raw orders.

How is this different from calling Kalshi or Polymarket's API directly?

You can absolutely call the venue APIs directly. SimpleFunctions adds a normalized intent shape across both venues, condition-based triggers (price/time/event) the venues do not natively expose, idempotency by design, and a single audit-log surface. Most production agents use both — the venue for the order, SimpleFunctions for the workflow around it.

What about partial fills and order amendments?

Working orders that partially fill remain in the working state with cumulative fill metadata; the remainder continues until the venue closes it or the intent expires. Amendments (price changes) cancel the existing venue order and re-submit; the intent persists across the swap so the audit trail stays clean.

Does SimpleFunctions guarantee fills?

No. Fill quality depends on venue liquidity, order type, posted price, and market conditions. SimpleFunctions provides intent, trigger, routing, and monitoring primitives; the venue determines fills.

Related surfaces

Prediction Market Hedging

Map real positions to event markets — the upstream that feeds intents.

Real-Time Data API

Sub-second WebSocket feed — what triggers actually watch.

Prediction Market API

Queryable normalized markets across Kalshi + Polymarket.

Agentic CLI

Command surface for agents to create and watch intents.

Agentic Usage

Patterns for AI agents on real-time data + execution.

Institutions

Institutional infrastructure overview.

Kalshi CLI

Operator command-line for Kalshi-specific workflows.