Zurück zu Projekte

options-gex

GEX-getriebene Research-Engine für den Optionshandel

PythonAlpaca APIPostgreSQLSQLiteSOPS / ageFernetDockerJupyter

Privates Repository

Problem

Die Gamma-Positionierung der Händler prägt das Intraday-Preisverhalten rund um zentrale Strike-Level — die Call Wall, die Put Wall und den Gamma Flip. Retail-Werkzeuge legen GEX entweder gar nicht offen oder berechnen es undurchsichtig hinter einer Bezahlschranke, mit Werten, die sich weder auditieren noch backtesten lassen. Es existiert keine selbstgehostete Pipeline, die rohe Optionsketten lädt, GEX transparent berechnet und rigoros prüft, ob GEX-basierte Regeln naive Baselines schlagen — bevor Kapital im Risiko steht.

Ansatz

Ein Python-Research-Stack nach dem Prinzip Falsifikation zuerst: historische Optionsketten laden (Alpaca), GEX lokal berechnen (mit Risk-Free Rate von FRED), Point-in-Time-Snapshots rekonstruieren, level-basierte Ein- und Ausstiegsregeln evaluieren, gegen Baseline-Kontrollen backtesten, Single-Parameter-Sweeps für Stabilität fahren — und ein Sechs-Bedingungen-Gate, das auf jedem Ziel-Ticker bestehen muss, bevor Phase 2 (Live- Ausführung) überhaupt freigeschaltet wird.

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)

Architektur

Das System ist in zwei Phasen mit einem harten Gate dazwischen geteilt. Phase 1 ist research-only — eine Library- und CLI-Oberfläche ohne Live-Ausführung, Dashboard oder Compose-Stack. Phase 2 (Live-Order-Routing, Observability, Compose) existiert operativ nicht, bis die Evidenz aus Phase 1 das Gate passiert.

Pipeline

Optionsketten und Risk-Free Rate fliessen in die Snapshot-Rekonstruktion, dann in die GEX-Berechnung, dann in die Signal-Regeln, dann in die Backtest-Engine mit Baselines und Parameter-Sweep — und schliesslich in das Go-Live-Gate, das ein Per-Bedingung-Urteil ausgibt.

Speicher

  • SQLite — lokaler Research-Store für Phase-1-Snapshots und -Läufe
  • PostgreSQL — Phase-2-Operativ-Store; Schema mit Alembic verwaltet (kein Auto-Migrate)

Technische Schlüsselentscheidungen

Falsifikations-orientiertes Go-Live-Gate

Die Entscheidung, jemals eine Live-Order zu routen, ist an einen Sechs-Bedingungen- Evaluator delegiert: Expectancy-Konfidenzintervall, Kosten-Vielfaches, Drawdown- Obergrenze, risikoadjustierte Rendite gegen Baselines, Sweep-Stabilität und temporale Stabilität. Ein bestandenes Urteil auf jedem Ziel-Ticker ist das einzige Go-Signal.

Transparente lokale GEX-Berechnung

Call Wall, Put Wall, Gamma Flip und normalisiertes GEX werden lokal aus dem Open Interest berechnet — keine undurchsichtigen Vendor-Werte. Ein Kalibrierungsschritt vergleicht gegen externe Referenzbeobachtungen und warnt bei Drift.

Dual-Signal-Live-Gate

Live-Ausführung erfordert sowohl ALPACA_ENV=live als auch ein explizites --live-Flag; jedes Signal allein löst zu Paper auf. Ein nicht unterdrückbares Banner benennt die aktive Umgebung vor jedem API-Aufruf.

Credentials verschlüsselt at rest

Phase 2 speichert Credentials verschlüsselt mit einem Master Key, der selbst in einer age-verschlüsselten Datei über SOPS liegt — mit papiergesichertem DR-Empfänger. Ein Logging-Filter maskiert geladene Credentials, und Pre-Commit-Hooks verhindern das Committen von Secrets, Datenbanken oder Notebook-Outputs.