Paper Trading Bot

A paper trading bot is a live-market rehearsal system. It runs the same signal, data, contract-selection, sizing, and routing logic that a real strategy would use, but sends orders to a paper broker or dry-run sink instead of allocating production capital.

For options strategies, the important point is parity. The paper bot should not be a separate demo script. It should be the closest possible live version of the backtest object: same profile, same option-selection rules, same timing assumptions, same risk limits, and the same rejection reasons.

This page describes the architecture CuteMarkets uses when moving an options strategy from historical research into paper execution.

Component map

Layer	Responsibility	Typical objects
Strategy profile	Defines signal logic, entry window, exit rules, option constraints, and risk assumptions	opening-range profile, VWAP mean-reversion profile, option-native overlay
Market data	Supplies underlying bars, option contracts, quotes, trades, and aggregates	CuteMarkets API, `cutemarkets-python`, `cutebacktests` providers
Backtest runtime	Replays historical sessions with causal timestamps and explicit fills	`cutebacktests`, DuckDB cache, trade log
Paper runtime	Polls live data, evaluates the same profile, selects contracts, submits paper orders, and records state	scheduler loop, broker adapter, state file, trade log
Operations	Promotes candidates, checks parity, monitors rejects, and reviews each session	launch contract, parity check, smoke run, daily review

The public cutebacktests package covers the research and backtesting runtime. It intentionally does not ship live or paper bots. A production paper bot adds broker integration, operational state, kill switches, and review discipline on top of the backtesting surface.

Lifecycle

A credible paper bot moves through a fixed ladder:

Define the strategy profile and freeze its public parameters.
Run historical backtests with causal entries and quote-aware option fills.
Evaluate robustness with out-of-sample windows, stress costs, and trade-density gates.
Promote one candidate into a launch contract.
Run parity checks on known benchmark sessions.
Run one in-session dry-run smoke.
Run a limited paper loop.
Review daily artifacts before increasing confidence.

The paper loop is not there to prove the strategy is profitable. It is there to identify drift between research and live execution. Common drift sources include stale contract selection, rejected option quotes, broker order behavior, timing mismatch, missing live bars, duplicate entries, and risk-control triggers.

The launch contract

Use a launch contract to make the paper bot reproducible. A good contract records:

profile name
ticker universe
artifact root
dry-run or paper mode
strict parity mode
option DTE window and contract status
risk per trade
maximum trades per day
broker and data-provider choices
kill switch and daily loss cap settings
polling, quote freshness, and execution timing rules

The contract should render the exact loop command, smoke command, parity commands, and daily review template. That keeps operator decisions out of the session and makes the bot easier to audit after a surprising trade or no-trade day.

State and artifacts

Every paper bot should write enough artifacts to explain what happened without relying on broker screens:

Artifact	Purpose
State file	Current session day, active trade, closed trades, kill-switch state, daily loss state
Trade log	Entries, exits, selected option contract, quantity, entry and exit prices, slippage fields
Funnel log	Opportunities before and after filters, entry attempts, submitted orders, fills, exits, reject counts
Execution log	Order type, limit price, reprices, fallback decision, broker order id, final status
Daily review	Human-readable checklist for parity, no-trades, rejects, duplicates, and risk controls

The funnel log is especially useful because a no-trade day can be healthy. If the strategy rejected the session for a known gate, that is a different result than a broken data feed or a silent contract-selection failure.

Public package boundaries

CuteMarkets separates public research tooling from private execution tooling:

cutemarkets-python is the typed Python client for the CuteMarkets options market-data API.
cutebacktests is the public intraday/options backtesting runtime.
cute-intraday-option-strats packages a narrow public strategy entrypoint on top of cutebacktests.

Live and paper execution should remain your responsibility because broker credentials, account rules, risk policies, and regulatory constraints are environment-specific. CuteMarkets provides the data building blocks: contracts, chains, quotes, trades, aggregates, expirations, and snapshots.

Minimal architecture

bash

strategy profile
  -> historical backtest
  -> promotion gate
  -> launch contract
  -> parity replay
  -> dry-run smoke
  -> paper loop
  -> daily review

Do not skip the middle steps. The failure mode is not usually that the Python loop cannot submit an order. The failure mode is that the live order no longer represents the research object you thought you promoted.

Research Docs

Docs