Strategy Reference

Every strategy you build in Turbine Studio is saved as a short YAML document, the strategy DSL. This reference lists every parameter in that document, venue by venue: its type, default, allowed values, and what it does once a Bot is running.

Start here to pick your venue, learn the shape of a strategy document, and see which features each venue supports. Then follow the links to the section for your venue or feature.

What a strategy document is

When you describe a strategy in Studio, Studio's AI writes it as a YAML document. You can read it on the strategy's Config tab, and you change it by asking the AI in chat. The document is the contract between what you asked for and what the Bot does: the Bot runs the document, not the conversation.

Studio checks every save in three steps:

1. Parse. The YAML must be well formed, and every top-level key must be one Studio knows.
2. Validate. Values must be in range, each key must be supported on your venue and strategy type, and custom rules must pass logic checks. For example, Studio rejects an exit rule that would fire right after every entry.
3. Compile. The document is turned into the program your Bot runs.

If any step fails, the change isn't saved. The AI gets the list of problems and revises the strategy. The one exception is an arbitrage strategy whose markets are still search placeholders: Studio saves it as a draft that can't deploy until the markets are resolved. See Arbitrage. When you deploy, Studio compiles the saved document again, so a Bot always runs a version that passed.

Every complete example in this reference is checked by an automated test that runs the same three steps. Examples that start with Rejected are checked to fail with the message they show.

Importing a saved strategy

A saved strategy's history does not prove its source still passes Studio's current checks. Its detail page offers import only when the saved document passes current validation and compilation; otherwise it shows Studio import unavailable, while the original document and saved history remain readable. An import that fails these checks reports the validation errors and creates no draft.

A successful import creates an undeployed draft from the original document and preserves its venue, including platform: kalshi_perps on older saved strategies whose stored venue label was Kalshi. Backtest availability is checked separately: an unsupported backtest does not by itself prevent import, and a saved backtest does not guarantee import or deployment eligibility. Review the draft and risk settings before deploying.

Deployment size limit

A valid saved strategy can still be too large to deploy. The runner accepts at most 2,000,000 bytes in the complete code-upload request, including credentials and signatures. Studio reserves 64 KiB for that metadata, leaving a 1,934,464-byte budget for the JSON-encoded compiled code; browser checks also include any environment settings supplied with it. This measures UTF-8 bytes after JSON escaping, not YAML length or Python character count. The completed signed request must still fit the full limit.

An oversized deployment or update is refused with strategy_too_large. Saving a draft does not remove this limit. Ask Studio to simplify the generated code while preserving the trading rules, then save and retry; upgrading the runner does not raise the limit.

Note: Examples use small, illustrative values and placeholder markets to show how a key behaves. They are not recommendations of markets, sizes or thresholds, and nothing here suggests a strategy will be profitable. Read Risk & Limits before you deploy.

Choose your venue

The platform: line decides which venue the Bot trades on, which document shape applies, and which keys are allowed. There are five strategy families.

A Studio chat is tied to one venue. You can't move a strategy to another venue by editing platform:. Studio rejects the change as a platform mismatch and also clears the strategy saved in that chat, so the AI has to write it again for the chat's venue. To trade on another venue, start a new chat there.

Arbitrage documents always use platform: arbitrage. The venue pair comes from the second leg, venues.b.platform, which is polymarket or polymarket_us.

Anatomy of a strategy document

Kalshi, Polymarket and Polymarket US strategies share one document shape. A few keys identify the strategy. market, risk and loop say what to trade, how much and how often. params or rules holds the logic, optionally fed by edge and derived data. Two optional blocks control timing.

Two either/or choices shape every document:

• params or rules. Built-in strategies read params. strategy: custom reads rules and ignores params. On Kalshi and Polymarket a built-in strategy accepts a rules block but never runs it. Polymarket US rejects it.
• active_window or trading_schedule. You can use one or neither, never both.

Unknown top-level keys are rejected, for example description: unknown top-level field. The old key name is still accepted but does nothing; use strategy_name.

A complete example

This Kalshi strategy follows the 15-minute Bitcoin series. It buys YES when YES is cheap early in a window, and exits on a profit target or shortly before the window closes. The values are illustrative only.

version: 1                        # always 1
platform: kalshi                  # the venue
strategy: custom                  # your own rules (or a built-in type)
strategy_name: Illustrative BTC 15-minute dip buyer
strategy_name_origin: user
market:
  series_ticker: KXBTC15M         # follow the series' current market
risk:
  max_position: 2                 # contracts per market
  price_floor: 0.05               # dollars: 5 cents
  price_ceiling: 0.60             # buy limit prices are clamped between 5 and 60 cents
  max_entries_per_market: 1       # one entry in each 15-minute market
loop:
  interval: 30                    # seconds to wait after each cycle
rules:                            # checked top to bottom; the first match acts
  - name: flatten_before_close
    when:
      all:
        - {field: position_size, op: ">", value: 0}
        - {field: time_to_expiry, op: "<=", value: "2m"}
    action: sell_all
  - name: take_profit
    when:
      all:
        - {field: yes_position_size, op: ">", value: 0}
        - {field: yes_best_bid, op: ">=", value: 0.55}
    action: sell_yes
  - name: enter_cheap_yes
    when:
      all:
        - {field: position_size, op: "==", value: 0}
        - {field: time_to_expiry, op: ">", value: "8m"}
        - {field: yes_best_ask, op: ">=", value: 0.05}
        - {field: yes_best_ask, op: "<=", value: 0.30}
    action: buy_yes
    size: 1

What each block does:

• version, platform, strategy: schema version 1, the Kalshi venue, and a strategy built from your own rules. See Custom Rules.
• strategy_name, strategy_name_origin: the label Studio shows. They don't change how the Bot trades.
• market.series_ticker: on every cycle, trade the event in the series that closes soonest. By default the Bot trades that event's most liquid bracket. See Kalshi.
• risk: the band buy limit prices are clamped into, the position size, and one entry per market. On Kalshi custom rules the floor clamps the limit price but doesn't block a cheaper fill, so the entry rule also checks yes_best_ask >= 0.05. Each new 15-minute market starts a fresh entry count.
• loop.interval: after each cycle finishes, the Bot waits 30 seconds before it starts the next one.
• rules: exits come first, so they run before any entry is considered. Only the first rule whose conditions all hold acts on each cycle.

When you deploy this example, Studio pre-fills the deploy dialog with 1 contract and $1 per order, 2 open contracts per market and a $2 daily loss, so the 1-contract entry fits. See Strategy risk fields vs deployment risk limits.

Kalshi Perps and Arbitrage documents

Kalshi Perps and Arbitrage use their own document shapes. The prediction-market keys above, such as market, edge and trading_schedule, are rejected at their top level.

Feature support across prediction-market venues

Kalshi, Polymarket and Polymarket US share a document shape, but not every key works on every venue. When a venue doesn't support a key, Studio usually rejects the save with a message that names the venue; the exceptions are listed under the matrix. The venue pages have the details.

Some combinations save without an error but do nothing, or fail when the Bot starts. Watch for these:

• A rules block on a built-in strategy, on Kalshi or Polymarket.
• An edge block on a built-in strategy, on Kalshi or Polymarket US. The data is never fetched.
• A params block on a custom strategy.

Conventions used across the reference

Prices

Prices are dollars per contract (or per share on Polymarket) on a 0 to 1 scale, which is also the market's implied probability. 0.05 means 5 cents and 0.60 means 60 cents. Always write dollars, never cents: price_ceiling: 60 is rejected as out of range.

Which quote a price field reads (bid, ask, midpoint or last trade) and which side it refers to differ by venue. Each venue page says exactly. Kalshi Perps prices are dollars per perp contract, where a contract is a fixed fraction of one coin.

Sizes

Whole-number keys reject decimals: max_position: 2.5, size: 1.5 or cooldown: 2.5 is rejected, and 3.0 is accepted. That covers risk, loop, a rule's size, whole-number params on built-in strategies, and arbitrage risk and fees. Window lengths in Kalshi Perps archetype params are strict in the same way.

Money amounts such as risk.max_notional, risk.max_loss, sizing.margin_usd and risk.max_position_usdc are dollars.

Durations and times

loop.interval: "30s" and loop.interval: "30" are both rejected: the interval must be a bare number. The interval is a pause after each cycle finishes, so the real time between cycles is the cycle's own run time plus the interval.

Percent, fraction or basis points

Strategy names

strategy_name is the name Studio shows for the strategy, up to 80 characters. Studio shortens longer names when it saves. strategy_name_origin records where the name came from:

• user: you typed it. Studio keeps it as written.
• generated: Studio's AI wrote it. Missing or unknown origins, and the older value legacy, are saved as generated.
• curated: it came from a Turbine template.

Neither key changes how the Bot trades. To change strategy_name, ask in chat. The Rename button in the Studio sidebar changes only the strategy's title in your list, not strategy_name.

How validation errors look

Once the YAML itself reads cleanly, each problem is reported as path: message, where the path points at the key, and Studio lists all of them together, not just the first. This Polymarket US strategy uses two features the venue doesn't support and loops too fast:

# Rejected: Polymarket US doesn't support trading_schedule or max_notional, and the loop is faster than 10 seconds
# error: risk.max_notional: is currently supported only for Kalshi and regular Polymarket strategies
# error: trading_schedule: supported only for Kalshi event strategies
# error: loop.interval: must be >= 10 seconds
version: 1
platform: polymarket_us
strategy: custom
market:
  slug: btc-above-120k-on-oct-31
risk:
  max_position: 1
  price_floor: 0.10
  price_ceiling: 0.90
  max_notional: 5.00
loop:
  interval: 5
trading_schedule:
  timezone: America/New_York
  trading_hours:
    - days: [mon, tue, wed, thu, fri]
      start: "09:30"
      end: "16:00"
rules:
  - name: take_profit
    when:
      all:
        - {field: position_size, op: ">", value: 0}
        - {field: price, op: ">=", value: 0.70}
    action: sell_all
  - name: enter_yes
    when:
      all:
        - {field: position_size, op: "==", value: 0}
        - {field: price, op: "<=", value: 0.40}
    action: buy_yes
    size: 1

Studio reports:

risk.max_notional: is currently supported only for Kalshi and regular Polymarket strategies
trading_schedule: supported only for Kalshi event strategies
loop.interval: must be >= 10 seconds (prevents API rate limiting)

Some problems are reported on their own, and the other checks wait until you fix them:

• Problems reading the document. A YAML formatting or type error, such as a quoted number, is reported alone, with a line number instead of a key path, for example line 13: cannot unmarshal !!str `30` into int. Structural problems, such as an unknown top-level key, a missing market selector or a rule with no action, are also reported before any range or venue checks run.
• Rule logic. Logic checks on custom rules run only once every rule's keys and fields are valid. Their errors name the rules involved and give a sample market state that triggers the problem. See Custom Rules.

What validation doesn't catch

• Typos inside params and edge aliases. Unknown keys there are ignored without an error, so a misspelled exit_targt: 0.6 saves and the default is used. Most nested keys in Kalshi Perps and Arbitrage documents behave the same way. Check spelling carefully. (Unknown keys inside market, risk, loop and active_window are rejected; see below.)
• Everything after a --- line. Only the first YAML document is read. Keep the whole strategy in one document, indented with spaces, not tabs.

These mistakes do produce errors:

• A quoted number in risk, loop, a rule or any built-in params key, such as interval: "30" or cooldown: "60".
• An unquoted >, >= or != operator, which breaks the YAML or reads as an empty operator. Quote every operator (op: ">=") so you never hit this one.
• An unknown key inside market, risk, loop or active_window, such as risk.max_notinal, which fails with risk.max_notinal: unknown risk field.
• A decimal in a whole-number key, such as interval: 10.9 or max_entries_per_market: 0.5, which fails with must be a whole number. 10.0 is fine.
• .nan or .inf anywhere a number goes, which fails with must be finite (or the key's range error).
• A mistyped optional built-in param: post_only: "false" or no instead of false, exit_target: abc, or a drift_direction outside auto, bullish and bearish. See Built-in Strategies.

# Rejected: max_entries_per_market must be a whole number; 0.5 used to become 0 (no cap)
# error: risk.max_entries_per_market: must be a whole number, got 0.5
# error: risk.max_notinal: unknown risk field
version: 1
platform: kalshi
strategy: custom
market:
  ticker: KXFEDDECISION-26OCT-C25
risk:
  max_position: 5
  price_floor: 0.05
  price_ceiling: 0.95
  max_entries_per_market: 0.5
  max_notinal: 20
loop:
  interval: 30
rules:
  - name: enter
    when:
      all:
        - {field: position_size, op: "==", value: 0}
        - {field: price, op: "<", value: 0.40}
    action: buy_yes
    size: 1
  - name: exit
    when:
      all:
        - {field: position_size, op: ">", value: 0}
        - {field: price, op: ">", value: 0.60}
    action: sell_all

Strategy risk fields vs deployment risk limits

Two separate layers limit what a Bot can do, and an order has to pass both wherever the venue's Bot reads the deployment limits. The strategy's risk block is part of the YAML. The deployment risk limits are set in the Risk limits section of the deploy dialog and belong to that deployment.

• Where you set them. Strategy risk fields live in the YAML, so you change them by asking Studio's AI, and Studio checks them on every save. Deployment risk limits are set in the deploy dialog each time you deploy.
• What happens at a limit. A strategy field can skip an entry, clamp an order's size or price, or halt the run. On Kalshi, Polymarket US and Kalshi Perps, a deployment limit refuses an order that would break it rather than shrinking it. The exceptions are exits: Kalshi exits (custom-rule, per-fill and built-in) and max_loss liquidations, and every Polymarket US exit, are split into several orders that each fit Max contracts per order. Arbitrage works the other way: it sizes each lock to fit Max contracts per order, Max dollars per order, and what is left of Max open contracts and Max daily notional traded.
• Backtests. Backtests simulate the strategy's risk fields, with gaps that each venue page lists. They don't read the deploy dialog: a Kalshi backtest applies max_position as the per-market cap instead.

Strategy risk fields

The price band works differently by strategy type and venue. Built-in strategies mostly use it as an entry gate, checked against the market price, and spread_capture clamps its quotes into it. Custom rules clamp the buy limit price into it instead, so on Kalshi a buy when the ask is below price_floor can still fill at the cheaper ask, and a buy when the ask is above price_ceiling rests as a bid at the ceiling. Exits are never clamped, on any venue, so an exit when the bid is below price_floor still sells at the bid.

On Kalshi, entry counts, max_notional spend and the max_loss ledger belong to one deployment run. They start over when you deploy or update the Bot, and restarting the same run doesn't reset them. On Polymarket, the entry count and spend are read from your account's trade history in that market, so earlier runs and manual trades there count too.

Note: On Kalshi and Polymarket US, the live per-market cap on held plus resting contracts is the lower of max_position and the deploy dialog's Max open contracts, which Studio pre-fills from max_position. Setting Max open contracts higher doesn't let the Bot hold more than max_position. Kalshi backtests block buys past max_position the same way.

Deployment risk limits

For Kalshi, Polymarket and Polymarket US strategies, Studio pre-fills the dialog from your strategy. Max contracts per order comes from the largest single order the strategy sends: the biggest buy size (an omitted size counts as 1) or composite orders leg, or for built-in strategies min(max_position, 10) for mean_reversion, max_position for observation_momentum, min(max_position, 5) for pre_announcement_drift, fade_size for panic_fade and 1 for spread_capture. Max dollars per order is the same number in dollars. Max open contracts and Max daily loss come from max_position. Max daily notional traded is the largest of the order size, max_position, and 10 × the order size. For Kalshi Perps, Max dollars per order is pre-filled from sizing.margin_usd × sizing.leverage, plus the execution.max_slippage_pct allowance, rounded up to whole dollars.

On runner version 29 or later, deployment risk settings belong to each Bot, even when several Bots share a runner. Updating one Bot's limits doesn't change another Bot's settings. When the running Bot's settings can be verified, its redeploy dialog starts from those limits. If readback is missing or unverified, the Config tab shows the running settings as unknown. Review the suggested limits in the deploy dialog before confirming an update. Older shared settings captured during a runner upgrade are unconfirmed; explicitly review and update that Bot's limits to confirm them.

Starting a Paper Run also opens a Paper Run risk limits dialog before the run starts or Studio requests missing credentials. Review the limits and choose Start paper run. The confirmed values travel with the paper deployment, including when it reuses saved credentials. They apply to simulated orders only where that venue's Bot reads them, as listed below; regular Polymarket shows no editable deployment limits. Paper fills are simulated, not orders submitted to the exchange or confirmed exchange fills.

Turbine MCP can inspect deployment status and activity, but deployment controls are unavailable through MCP. Use Turbine Studio to deploy, update, stop or recover a Bot. See Turbine MCP.

Not every venue's Bot reads every limit, and the deploy dialog shows only the ones it does:

Note: Max daily loss pauses entries for the rest of the UTC day. On Kalshi custom strategies, risk.max_loss is the loss halt for a whole run: once the run's losses reach it, the Bot cancels its orders, sells the inventory it bought, and opens nothing new for the rest of that run.

Where to go next

Each link opens the first page of a section. That page covers what the section's topics share and lists the rest of its pages under In this section.

For how strategies are tested and run, see Backtest, Run, Monitoring and Prompting.