Skip to main content
Back to Projects

options-gex

GEX-driven options trading research engine

PythonAlpaca APIPostgreSQLSQLiteSOPS / ageFernetDockerJupyter

Private Repository

Problem

Dealer gamma positioning shapes intraday price behaviour around key strike levels — the call wall, the put wall, and the gamma flip. Retail tools either don't expose GEX at all or compute it opaquely behind a paywall, with values you can neither audit nor backtest. There is no self-hosted pipeline that pulls raw option chains, computes GEX transparently, and rigorously tests whether GEX-derived rules beat naive baselines — before any capital is at risk.

Approach

A Python research stack built on a falsification-first premise: pull historical option chains (Alpaca), compute GEX locally (with a risk-free rate from FRED), reconstruct point-in-time snapshots, evaluate level-driven entry and exit rules, backtest against baseline controls, run single-parameter sweeps for stability — and a six-condition gate that must pass on every target ticker before Phase 2 (live execution) is even unlocked.

Option Chains Alpaca · historical OI Risk-Free Rate FRED GEX COMPUTATION Call wall · Put wall · Gamma flip · Normalized GEX SIGNAL RULES Level-driven entries · level-driven exits BACKTEST ENGINE vs Baseline controls · single-parameter sweep 6-CONDITION GO-LIVE GATE Expectancy CI · cost multiple · drawdown · stability research- only all tickers pass PHASE 2 (GATED) Live execution Compose · observ. Phase 2 — live order routing (dual-signal gated) STORAGE SQLite (research) PostgreSQL (Phase 2)

Architecture

The system is split into two phases with a hard gate between them. Phase 1 is research-only — a library and CLI surface with no live execution, dashboard, or Compose stack. Phase 2 (live order routing, observability, Compose) does not exist operationally until Phase 1's evidence clears the gate.

Pipeline

Option chains and the risk-free rate feed snapshot reconstruction, then GEX computation, then signal rules, then the backtest engine with baselines and a parameter sweep — and finally the go-live gate, which emits a per-condition verdict.

Storage

  • SQLite — local research store for Phase 1 snapshots and runs
  • PostgreSQL — Phase 2 operational store; schema managed with Alembic (no auto-migrate)

Key Technical Decisions

Falsification-first go-live gate

The decision to ever route a live order is delegated to a six-condition evaluator: expectancy confidence interval, cost multiple, drawdown ceiling, risk-adjusted return versus baselines, sweep stability, and temporal stability. A passing verdict on every target ticker is the only go signal.

Transparent local GEX computation

Call wall, put wall, gamma flip, and normalized GEX are computed locally from open interest — no opaque vendor numbers. A calibration step compares against external reference observations and warns on drift.

Dual-signal live gate

Live execution requires both ALPACA_ENV=live and an explicit --live flag; either signal alone resolves to paper. A non-suppressible banner names the active environment before any API call.

Credentials encrypted at rest

Phase 2 stores credentials encrypted with a master key that itself lives in an age-encrypted file managed through SOPS — with a paper-backed DR recipient. A logging filter masks loaded credentials, and pre-commit hooks block committing secrets, databases, or notebook outputs.