Kalshi Terminal.

A market signal is only one component of a trading system. The system must identify the correct contract, validate entry conditions, manage order state, track exposure, handle exits and reconcile the final economic outcome.

Failures can arise when market data is stale, runtime configuration differs from displayed settings, fills are confused with submitted orders, or settlement and fees are represented inconsistently. The objective is to make these responsibilities explicit and inspectable.

The system consumes prediction-market information alongside cryptocurrency reference-price feeds. Development configurations have included BRTI and reference sources such as Coinbase, Kraken, Bitstamp and Gemini.

The architecture distinguishes the reference price used to evaluate direction from the executable price and liquidity available in the prediction market. Directional agreement does not guarantee a favorable contract price.

• Normalize incoming observations
• Track source and timing context
• Treat stale or incomplete inputs as explicit conditions

The strategy orientation is momentum and trend-following breakouts, with counter-trend entries blocked by design. The system has included a nine-period EMA trend guard and a momentum-thesis guard.

Entry bounds, confirmation cycles, take-profit distance, stop-loss behavior, allocation and expiration protection represent different controls. Keeping them distinct makes each assumption easier to test.

• Entry-price bounds and confirmation cycles
• Trend and thesis guards
• Configurable exit and expiration behavior

A signal, submitted order, fill and closed position are different states. The execution layer must preserve those distinctions and avoid treating an intended action as proof that the exchange completed it.

The boundary between signal generation and execution authorization prevents a valid signal from bypassing order controls.

• Explicit order lifecycle
• Validation before execution
• Separate intended actions from exchange-confirmed events

The system exposes position-sizing and allocation controls alongside trend validation, thesis validation and expiration-related safeguards. Each addresses a different failure mode.

The presence of controls does not prove profitability or guarantee bounded losses in every market condition. Effectiveness must be evaluated against observed execution and realistic failure scenarios.

• Position quantity and allocation constraints
• Trend consistency and thesis invalidation
• Expiration-aware handling

Economic results must be reconstructed from actual fills, fees, remaining quantity and settlement events. A partial exit does not necessarily close the whole position, and multiple events can belong to a single economic trade.

The project has included validation of buy/sell/settlement scenarios and review of persistent trade records, to distinguish order activity from final position outcomes.

• Reconcile fills and settlement
• Account for fees and residual quantity
• Distinguish event records from trade-level outcomes

The system has used Linux and Docker deployment, a web interface and SQLite/JSON-oriented operational records. Logs and persistent events help investigate what the strategy intended, what the runtime did and what the exchange confirmed.

Shadow and live operation must remain distinct. Shadow behavior does not prove equivalent live fills; live operation introduces liquidity, latency, fees and exchange-side state changes.

• Inspect effective runtime configuration
• Trace events through logs and persistent state
• Verify the running deployment after changes