Automating an options rule is a materially different proposition from automating a cash rule. Leverage is involved, expiries are involved, and a mistake compounds faster than anyone can react to it.
PocketX handles this by making the exact-option specification strict rather than expressive. It is a deliberately small language, and each constraint blocks a specific, well-documented way that automated option strategies fail.
Reading the restrictions as a list of limitations misses the point. They are the design.
One exact expiry and strike source
An exact-option strategy names one exact expiry and strike source. It does not select a strike dynamically at runtime.
What this prevents. Dynamic selectors — "the strike nearest the money", "the strike with a delta near 0.3" — sound sophisticated and introduce a nasty failure mode: what the strategy trades changes based on conditions at the moment it fires. Your backtest examined one set of contracts. Live execution picks whatever qualifies on the day. You have proof about one thing and are trading another.
Fixing the source means the contract you tested is the contract you deploy. Dynamic option selectors are explicitly excluded from the first release, and this is why.
One leg, same as the position
A strategy carries one leg, and it matches the position. There is no multi-leg construction.
What this prevents. Multi-leg structures fail in ways single legs do not. One leg fills and the other does not, and a defined-risk spread silently becomes a naked position. Legging risk during volatile periods — exactly when it matters — is a serious and well-known hazard.
The practical consequence for you: spreads are not automatable here. Multi-leg option strategies are excluded from the first release. If you want a hedged structure, you place and manage it as manual orders. Your first hedged options trade covers building one by hand.
Do not plan around a capability that does not exist. That is worth more than any workaround.
MIS only
Exact-option strategies run as MIS — intraday.
What this prevents. Overnight gap risk on a leveraged position, with nobody watching. An automated rule that opens a position and holds it through the close is exposed to whatever happens before the next open, with no ability to respond.
Intraday-only is a hard boundary on how bad an unattended outcome can be.
Mandatory exit and mandatory square-off
An exact-option strategy must specify an exit condition, and must specify a square-off. Neither is optional.
What this prevents. The single most common failure in automated trading: a rule that knows how to enter and does not know how to leave. Entry logic is the enjoyable part to write. Exit logic is the part that determines the outcome.
Making both mandatory means it is not possible to deploy a strategy that can open a position it has no plan to close. The square-off is the backstop — a defined point at which the position ends regardless of whether the exit condition was met.
Stop-loss is available and optional. Exit and square-off are not.
One position, one entry
Fixed safeguards cap the strategy at one position at a time and one entry.
What this prevents. Runaway repetition. A rule whose condition remains true across consecutive bars, without this constraint, opens position after position. What was intended as one trade becomes ten, with ten times the exposure, in minutes.
This is not a hypothetical failure. It is the classic automation accident, and the constraint makes it structurally impossible rather than merely unlikely.
Evidence before activation
Before an exact-option strategy can be activated, it needs current proof: validation and a backtest attached to the saved strategy. Runtime capability gates remain authoritative. Cash strategy arming evaluates closed bars and creates alerts only; it does not place broker orders.
Why narrow beats expressive
The instinct on meeting these constraints is to want more: dynamic strikes, multiple legs, positional holds, multiple entries.
Consider what a fully expressive version would permit. A strategy that selects strikes at runtime, holds three legs, carries overnight, has no mandatory exit, and can open repeatedly while its condition holds. Every one of those is a genuine feature. Together they are a machine for turning a small logic error into a large loss without supervision.
The restricted specification cannot express that strategy. That is the feature.
A narrow language you fully understand is safer than a rich one you partly understand — particularly when the thing it controls is leveraged and unattended.
Working within it
- Write the exit first. It is mandatory, so treat it as the primary design decision rather than an afterthought.
- Pick the expiry and strike deliberately. They are fixed. Choose contracts with genuine liquidity, since you cannot adapt later.
- Expect one trade. One position, one entry. Design the rule around a single decisive event, not a pattern that repeats through the day.
- Read the backtest assumptions before the returns. What a backtest proves is the necessary companion.
- Understand the option itself first. Option greeks in plain English and implied volatility explain what will happen to the contract your rule selects. A rule that is right about direction and wrong about theta still loses.
Browse chains and expiries on the options surface, and build in the strategy workspace.
The constraints are not a preview of a freer version to come. They are what makes automating a leveraged instrument defensible at all.