Iron Condor Builder — Q1 / Q2 / Q5 Research Recommendations

Prepared for: Kristerpher (operator) — #1382 acceptance gate
Date: 2026-05-14 UTC
Scope: Operator delegated three of five IC builder pre-productization decisions to data-scientist recommendation. This brief covers Q1 (wing geometry), Q2 (IVR source), and Q5 (Phase 3 MVP scope — default for the configurable time-exit vs. roll toggle). Q3 and Q4 were answered directly by the operator.

Status: Pending operator acceptance. IC builder series (defer:post-launch) does not move to ready-for-dev until Kristerpher accepts or amends these recommendations via a comment on #1382.

Framing constraint: All backtest evidence cited describes what happened in specific historical periods on historical data. Nothing here predicts future outcomes. These are defaults for a rule-based deterministic engine — they are research-informed starting points, not advice to users.

Q1 — Wing Geometry: Symmetric vs. Asymmetric

The question

Should the iron condor builder default to symmetric wings (equal width on call side and put side) or asymmetric wings (wider put wing to absorb equity index downside skew)?

Affects: #IC-03 (payoff calc wing-width assertion), #IC-05 (score endpoint validation),

IC-08 (entry rule delta selection per wing).

Research background

Equity index options (SPX, SPY) exhibit persistent implied volatility skew: out-of-the-money puts are priced at higher implied volatility than equidistant OTM calls. This skew reflects the market's assessment of left-tail risk and has been stable across multiple regimes.

Several sources document the behavioral consequences for iron condors:

• The call side of a short SPX iron condor has been found to be systematically unprofitable in large-sample backtests (spintwig, 18 backtests, 51,600+ 45-DTE trades). The put side drives the strategy's edge in most environments. Source:

https://spintwig.com/short-spx-iron-condor-45-dte-s1-signal-options-backtest/

• Alberic de Saint-Cyr (SSRN 2023) analyzed 32 years of SPX/VIX data and found that market and volatility conditions significantly affect IC outcomes, with skew being a primary structural factor. Source:

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4643378

• A stochastic optimal control treatment (arXiv 2501.12397, January 2025) found that left-biased asymmetric IC structures (deeper OTM put spread) produce superior risk-adjusted outcomes in SPX-like skewed processes, and that such structures should be held to expiration rather than managed early. The paper proves that for bounded underlying price processes with appropriate strike geometry, left-biased structures reduce downside tail exposure while preserving profitability in sideways markets. Source:

https://arxiv.org/html/2501.12397v1

• The DTR Trading 96,624-trade SPX backtest (2007–2016) found that wider wings consistently produced lower absolute losses but did not specifically compare symmetric vs. asymmetric configurations. Source:

http://dtr-trading.blogspot.com/p/spx.html

Practical asymmetric IC mechanics: An unbalanced IC widens the put spread (e.g., 5-wide call spread / 7.5-wide put spread at equal short-strike deltas) to collect more premium on the put side while the short call spread is tighter. The margin requirement is governed by the wider side. The net effect on risk-adjusted return depends on whether the incremental premium collected exceeds the incremental expected loss from the tail risk accepted.

Synthetic illustration: A parameterized Python simulation at research/iron-condor/q1_symmetric_vs_asymmetric_demo.py (50,000 paths, skew-normal SPX-like return distribution, seed=42) shows that under fixed-skew assumptions:

• The asymmetric configuration consistently produces higher mean P&L due to incremental put-side credit.
• The asymmetric configuration has a larger worst-case loss (wider put wing means the tail loss ceiling is higher when the spread is fully breached).
• The net Sharpe improvement is modest and sensitive to the credit model. The linear credit model in the script overstates incremental put-side premium because the real vol surface is concave — wider OTM put wings collect less additional credit per unit of additional risk than the linear approximation implies.

The simulation is an illustration, not a backtest. Its value is showing the sensitivity of the tradeoff to the credit assumption, which is the variable that requires real options chain data to pin down.

Implementation cost comparison

Option A: Symmetric only (simpler) - One wing-width parameter per IC. - Payoff calculator (#IC-03) has a single path: max_loss = wing_width - credit. - Score endpoint validation (#IC-05) asserts long_call - short_call == long_put - short_put. - Delta selection (#IC-08): one delta target applies to both short strikes. - No additional complexity in the rule engine. - Data schema: two integers (call_wing_width, put_wing_width) are equal by constraint; can be expressed as one parameter.

Option B: Asymmetric only (not recommended) Locks users into asymmetric without symmetric option. Imposes wider wings always, which are harder to fill at tight bid/ask in lower-liquidity underlyings (not SPX/SPY).

Option C: Support both, default to symmetric (recommended) - Two independent wing-width parameters in the data schema. - Score endpoint (#IC-05) validates each wing independently. - Rule engine (#IC-08) applies the same delta target to the short strike but uses per-side wing widths. - Incremental implementation cost vs. symmetric-only: low — the payoff calculator already needs to handle independent leg widths; the only change is removing the equality assertion and storing two parameters instead of one. - UI cost: one extra input field in the builder (#IC-06).

Recommendation

Default: symmetric wings.

Rationale: 1. Symmetric is simpler to explain, test, and validate. For a first implementation of an IC builder serving users who may not be familiar with vol surface mechanics, symmetric is the lower-friction default. 2. Asymmetric is meaningfully useful only on index underlyings (SPX, SPY, QQQ) where persistent put skew is structurally present. On individual equities, skew direction and magnitude vary by name; a blanket asymmetric default would be incorrect for much of the universe. 3. The incremental Sharpe improvement from wider put wings in the research literature is real but small under standard management rules (50% profit take, 2x stop). The risk of a user being surprised by a larger tail loss from the wider put wing outweighs the modest expected-return benefit as a default. 4. Supporting both configurations at low implementation cost (see Option C above) means asymmetric remains available as an override without locking the default to the more complex case.

When to override (user guidance): - Asymmetric (wider put wing) is appropriate when the underlying is a broad equity index (SPX, SPY, QQQ) and the user explicitly understands the vol skew motivation. It is the correct structural choice for a premium-seller who has studied the CBOE/spintwig literature and accepts the higher tail-loss ceiling in exchange for additional credit. - Symmetric is appropriate as the default for individual equities and for users who want the simplest risk profile.

Downstream card impact: - #IC-03: remove the equality assertion between call_wing and put_wing; allow independent values; default both to the same value at construction. - #IC-05: validate each wing independently in rule_validation; add put_wing_width and call_wing_width to the score endpoint input schema. - #IC-08: store call_wing_width and put_wing_width as separate rule-engine parameters; default both to the same value at strategy creation.

Q2 — IVR Source: Compute, Display-Only, or Manual

The question

Should IVR (Implied Volatility Rank, a.k.a. IV Rank) be: (a) computed from historical IV data — which requires a licensed data source; (b) display-only, surfaced from a live market data feed but not used as an entry gate; or (c) manually entered by the user?

Affects: #IC-04 (risk characterization), #IC-05 (rule_validation.ivr_gte_50), #IC-08 (entry IVR gate in the rule engine).

ORATS license card status

Issue #1384 ("Operator decision: ORATS enterprise license for IC backtest validation") is OPEN, labeled needs-grooming, type:business, priority:medium. The operator has not yet made the ORATS licensing decision. The enterprise vs. retail licensing distinction is unresolved, and the existing docs/data-science/historical-options-data-vendors.md documents that ORATS's retail API prohibits SaaS redistribution — an enterprise agreement is required before Raxx can use ORATS as a backend computation source.

This means the "compute from ORATS" path is blocked by #1384 and cannot be adopted as a default until the operator makes the ORATS licensing decision.

Option analysis

Option A: Compute from ORATS (blocked by #1384) - Definition: IVR = (current IV - 52wk IV low) / (52wk IV high - 52wk IV low) Source:

https://insights.deribit.com/education/iv-rank-and-iv-percentile/

• Requires: ORATS historical IV data API ($199/mo retail; enterprise pricing unknown). Retail terms prohibit SaaS redistribution. Source:

https://orats.com/terms-conditions

• Accuracy: high. ORATS provides cleaned, point-in-time EOD IV snapshots going back to 2007. IVR computed from ORATS is the industry-standard reference used by spintwig and documented in the CBOE iron condor whitepapers.
• Build complexity: moderate. A daily cron job fetches the prior 252-session IV values for each configured symbol and computes IVR. Celery task fits the existing architecture.
• Hard gate: #1384 must be resolved first. Do not adopt as the default until licensing is confirmed.

Option B: Compute from Alpaca live IV (current subscription) - Alpaca Algo Trader Plus ($90.75/mo, already subscribed) provides live IV for options chains, but historical options data only goes back to February 2024 — roughly 26 months of history as of today. 52-week IVR requires exactly 52 weeks of history, which Alpaca can provide, but only going back to early 2025 effectively. Source:

https://docs.alpaca.markets/docs/historical-option-data

• Accuracy: acceptable for a 52-week lookback once the history window is long enough (after ~February 2025). Before that, IVR computed from Alpaca data would have a compressed lookback window and could be miscalibrated.
• Current state: as of May 2026 (today), Alpaca's history window covers approximately 26 months — sufficient for a 52-week IVR calculation.
• Limitation: IVR computed from Alpaca's 26-month window does not capture the 2020 COVID vol spike or the 2022 bear-market vol expansion as anchoring reference points. A 2022 high-IV period would register as IVR ~100 under ORATS's 20-year window but might register as IVR ~60 against Alpaca's 26-month window if recent vol is moderate.
• License risk: Alpaca's support documentation states redistribution for business purposes is prohibited. Using Alpaca IV data to compute a backend IVR signal that triggers order entry (rather than displaying raw chain data) may qualify as "internal non-display use" — but this requires attorney review per #1384 and docs/data-science/historical-options-data-vendors.md §4. Source:

https://alpaca.markets/support/redistribute-alpaca-api

Option C: Compute from yfinance (free, unofficial) - yfinance provides access to Yahoo Finance options data including an IV estimate per contract. This data can be used to compute a rough IVR over a 52-week window by collecting ATM IV snapshots daily. Source:

https://dev.to/dm8ry/pulling-options-data-with-python-and-yfinance-and-saving-it-like-a-pro-45l9

• Accuracy: low-to-moderate. Yahoo Finance's IV figures are known to have inaccuracies (particularly outside market hours). The data is not cleaned, not point-in-time, and not guaranteed to be consistent across sessions. Using yfinance-derived IVR as a production entry gate would introduce unpredictable signal noise.
• License: Yahoo Finance Terms of Service prohibit commercial use of scraped data. This path is disqualified for a SaaS product.

Option D: Manual input (user enters IVR) - User types in an IVR value at strategy setup. No computation required. - Accuracy: entirely dependent on the user's source (their broker UI, thinkorswim, etc.). - Build complexity: trivial — one input field, no backend computation. - Risk: user may misremember or mismatch the IVR definition (rank vs. percentile; 1-year lookback vs. other). Silent miscalibration. - Suitable for: a v1 interim state where the computation path is not yet built.

Option E: Display-only (surface IVR from a live feed, not used as gate) - IVR is shown in the builder UI as informational context but rule_validation.ivr_gte_50 returns null — the gate is skipped. This is exactly the state the codebase is already designed for per #IC-05's AC (ivr_gte_50 returns null, not false, until IVR source is resolved). - Accuracy: not applicable as a gate. - User impact: the user sees IV context but the automated rule engine does not enforce the IVR >= 50 gate. Positions can be entered in low-IV environments where the IC edge is weaker. - This is already the Phase 2 shipping state.

Recommendation

Default for Phase 3 MVP: manual input, with display-only as the fallback UI state.

Rationale:

1. ORATS path is blocked. #1384 has not been resolved. Adopting "compute from ORATS" as the default would make the IC rule engine non-functional for Phase 3 until a licensing decision is reached. That is an unacceptable dependency for a post-launch feature.

2. Alpaca path is technically viable but legally uncertain. Alpaca's 26-month history is now sufficient for a 52-week IVR window. However, attorney review is required before relying on Alpaca data for an automated entry gate in a commercial SaaS product. This review should happen as part of resolving #1384, not as a blocker for Phase 3 shipping.

3. Manual input unblocks Phase 3 shipping. The user can enter their own IVR from their broker's platform. The rule engine enforces the gate deterministically against the entered value. This matches the product's "structure enforcement" thesis — the user decides the rule; Raxx enforces it. A user who does not know their IVR can leave the gate at null (display-only) and proceed without it.

4. Migration path is clean. The ivr_gte_50 field in the score endpoint already returns null when no source is configured. The rule engine already has a "log and proceed" fallback when IVR is not configured. Adding manual input is an AC update on #IC-08, not a redesign. When ORATS (or Alpaca internal-use) is confirmed, the source can be switched to "compute" without changing the gate logic.

Recommended default UX: The IVR gate is opt-in at strategy setup. Default state is "IVR gate: off (no source configured)." User can enable it and choose between: - Manual entry (enter IVR value when opening a position) - Compute from available source (shown as "data source not configured" until #1384 resolves)

When to override: - Once #1384 resolves and ORATS enterprise terms are confirmed, switch the default computation path to ORATS for users who enable the IVR gate. No changes to the gate logic itself — only the data-source wiring. - Alpaca-computed IVR can be adopted as an interim "compute" option once the attorney review on redistribution is complete, with a documented caveat that the 26-month window may miscalibrate IVR during high-vol regime transitions.

Downstream card impact: - #IC-05: no change — ivr_gte_50: null is already the specified Phase 2 behavior. - #IC-08: add ivr_source config field with values ["off", "manual", "alpaca", "orats"]; default "off". When "manual", rule engine requires ivr_at_entry in the position creation payload. When "off", log "IVR gate skipped: source not configured" (already in the current AC). - #1384: this recommendation does not resolve #1384. The operator must still make the ORATS licensing decision for the long-term compute path. This recommendation only unblocks Phase 3 shipping without waiting for that decision.

Q5 — Phase 3 MVP Scope: Default for the Time-Exit vs. Roll Toggle

The question

The operator decided Q5 is configurable. The data-scientist is asked to recommend the default value of that configurable setting: should the default be "time-exit only (close position at 21 DTE)" or "include roll (re-enter at next expiration if conditions pass)"?

Affects: #IC-09 (roll logic card) — if the default is "time-exit only," #IC-09 can remain deferred and the card can be explicitly labeled "Phase 3.5 optional, not a Phase 3 blocker." If the default is "include roll," #IC-09 must ship before Phase 3 completes.

Research background

How often do IC trades reach the roll trigger (21 DTE) without hitting profit or stop?

The tastytrade 4,872-trade study (2005–2019) found that managing at 50% profit takes an average of 14 days for a 45-DTE IC — well before the 21 DTE roll trigger. In that study, 82% of trades were closed at the profit target before reaching 21 DTE. Source:

https://tastytrade.com/learn/trading-products/options/iron-condor/

The projectfinance 71,417-trade study found that 50–75% profit targets produce the highest P&L expectancy across the tested universe (SPX and liquid equities). The study tested time-exit and profit/stop-loss exits but did not study rolling specifically. Source:

https://www.projectfinance.com/iron-condor-management/

The DTR Trading 96,624-trade SPX backtest (2007–2016) found that the best-performing configurations reached their stop-loss or profit target well before expiration in the majority of cases. Source:

http://dtr-trading.blogspot.com/p/spx.html

What do these results imply about roll frequency? If ~82% of well-managed IC positions close at the profit target before 21 DTE (under tastytrade's 50% take-profit rule), then the roll trigger fires on at most ~18% of trades. Of those, some fraction will fail the entry conditions re-evaluation (IVR gate, credit gate, earnings guard), leaving a still-smaller fraction that actually roll to a new expiration. The population of trades where roll logic is exercised is a minority of total trades.

Does roll logic improve risk-adjusted return materially? The literature does not produce a clean "roll vs. no-roll Sharpe comparison" because rolling is an active management choice that changes the position identity. The arXiv stochastic control paper (arXiv 2501.12397) frames the exit decision as an optimal stopping problem and does not address rolling. Tastytrade's guidance on rolling is operational (how to roll a challenged strike) rather than statistical (does rolling improve Sharpe).

The Data Driven Options Trading practitioner analysis showed rolling can recover threatened positions, but their examples are cherry-picked and they explicitly note "not every trade fared this well." Source:

https://datadrivenoptions.com/rolling-iron-condors/

Implementation complexity of roll logic: As documented in #IC-09's card body, roll adds two sequential orders (close current + open new), requires full re-evaluation of all entry conditions, and introduces a "flat account" window between orders. The card is explicitly labeled Phase 3.5 optional and estimates size:m for implementation.

The time-exit path (close only at 21 DTE) is already fully specified in #IC-08 and has no additional complexity. Rolling re-uses the entry condition evaluator but adds order sequencing and audit branching.

Recommendation

Default: time-exit only (close position at 21 DTE, no roll).

Rationale:

1. Most trades never reach the roll trigger. Under 50% profit management, the tastytrade data suggests approximately 82% of trades exit before 21 DTE. Rolling logic is exercised on a minority of trades, making it a low-leverage feature for the MVP.

2. Roll logic is meaningful in specific scenarios, not universally. Rolling adds value when: (a) the position is profitable enough to warrant continuation, (b) the next expiration meets all entry conditions, and (c) the user wants continuous exposure. These conditions are user-specific. Making "no roll" the default aligns with the product thesis that the user has decided their structure — the default should be the simplest enforcement of that structure.

3. Phase 3 ships sooner without #IC-09. If the default is "time-exit only," #IC-09 is explicitly deferred to Phase 3.5 with no Phase 3 blocking dependency. This reduces the Phase 3 critical path by one size:m card.

4. The configurable toggle means roll is available when needed. Users who want continuous exposure can enable roll. Defaulting to off does not remove the feature; it ensures the simpler, better-tested path runs first.

5. Science: rolling does not clearly improve Sharpe in the backtest literature. The evidence for rolling improving risk-adjusted returns is practitioner-anecdotal, not statistically validated at scale. The projectfinance and DTR backtests — the two largest public SPX IC datasets — do not include roll scenarios. Defaulting to the strategy with stronger empirical support (time-exit) is the conservative and scientifically defensible choice.

When to override: - Users who run the IC rule engine on low-volatility underlyings where the 50% profit target is rarely hit before 21 DTE may find rolling more valuable than average. - Once Raxx has accumulated sufficient paper-trade history to compute an internal roll-vs-no-roll Sharpe comparison on its own user population, that data should inform whether the default should change.

Downstream card impact: - #IC-08: ROLL_ENABLED defaults to false in the iron_condor_paper_trade flag configuration payload. The time-exit behavior (close-only at 21 DTE) ships as the complete MVP. - #IC-09: label this card explicitly as "Phase 3.5 follow-up — default is time-exit only; this card unblocks roll for users who enable it. Does NOT block Phase 3 launch." Move to defer:post-launch-3.5 or equivalent.

Cross-card dependency map

The three recommendations interact as follows:

Open questions for operator review

1. Q2 — Is "manual IVR input" acceptable UX for v1 IC users? The recommendation assumes Raxx's initial IC user population is self-directed and will know their IVR from their existing broker platform. If Kristerpher's target user does not track IVR, defaulting to "gate off" (display-only) may be preferable to manual input. The distinction only matters for the rule engine: "gate off" means no IVR enforcement; "manual input" means the user must provide a value or the entry skips.

2. Q1 — Symbol scope for asymmetric default. The recommendation is "symmetric by default, asymmetric available as override." If the IC builder is initially scoped to SPX/SPY only (broad index), the case for asymmetric-as-default is stronger, since put skew is structural and persistent on indices. Clarify in #IC-08 grooming whether the Phase 3 MVP is index-only or includes equities.

3. Q5 — Paper-trade history gate for roll. Before enabling roll in production, Raxx should accumulate sufficient paper-trade history to validate that the re-entry conditions (IVR gate, credit gate, earnings guard) function correctly at the roll trigger. Recommend gating the roll feature behind a "minimum X paper trades completed" threshold in the iron_condor_paper_trade flag configuration, rather than making it immediately available to all users on Phase 3.5 ship.

Pending operator acceptance

This brief is complete. The three recommendations:

Kristerpher: to accept these recommendations and unblock the IC Phase 3 cards, post a comment on #1382 with your decision. Once accepted, #IC-08 and the roll decision on

IC-09 can move to ready-for-dev.

Primary sources

All research claims describe historical data observations. No claim in this brief constitutes a prediction of future performance or advice to users. The IC builder is a rule-based automation tool; this brief informs the defaults of that tool.