Options OS: Build a crypto-options trading engine
Build a crypto-options trading engine without rebuilding the infrastructure around the strategy from scratch.
$ git clone git@github.com:LeanOS-Technologies/options-os.git
available after purchase · private source repository · no subscription
Mission
Options OS is built on three ideas.
-
Trading engine development should not require one person to master both options trading and software engineering.
Software engineers need access to the domain model: instruments, pricing, risk, execution, lifecycle, and venue behaviour. Traders and quantitative domain experts need access to an engineering system that can translate their trading definitions into structured specifications and working software.
-
Building with coding agents requires a different engineering system.
A prompt and an empty repository are not enough. Agents need authoritative specifications, reusable capabilities, controlled execution, specialised skills, mechanical constraints, and evidence that the implementation matches the intended system. Options OS is also an attempt to find the optimal way to build complex software with coding agents.
-
The route from trading idea to running engine should be considerably shorter.
Domain experts should be able to define the system in trading language without mastering every engineering discipline. Engineers should be able to build it without reconstructing the options domain from scratch. Options OS connects the two through a shared framework that can be composed, implemented, and verified.
Start with the trading system, not an empty repository.
Options OS gives Claude Code and Codex the options-domain model, reusable libraries, specifications, venue boundary, execution controls, and verification machinery required to build a crypto-options trading engine. You define the strategy. The repository supplies the engineering foundation.
The shift in starting point
| Without Options OS | With Options OS | Result |
|---|---|---|
| Rebuild options infrastructure around every strategy | Compose an existing options-native foundation | Less reinvention |
| Agents infer boundaries from scattered code | Specifications and contracts define the system | Less drift |
| Venue behaviour leaks into engine logic | A reference adapter demonstrates the normalized boundary | Cleaner composition |
| Generated code is accepted on appearance | Verification is part of the build path | Stronger evidence |
The reusable framework beneath the engine.
You receive implemented software, explicit contracts, and the build machinery around them. It is not an empty scaffold or a prompt collection.
- Canonical options-domain contracts
- Pricing, volatility-surface, portfolio, cost, and hedging libraries
- Trading, execution, messaging, reconciliation, and runtime boundaries
- Adapter contracts with Deribit as the reference implementation
- System and library specifications
- An engine scaffold and assembly path
- Claude Code and Codex build workflows
- Verification and deployment tooling
- Source you can inspect, extend, and operate
From trading intent to admitted implementation.
Describe the system in trading language. Options OS translates that intent into specifications, binds the required libraries and venue components, gives Claude Code or Codex bounded execution packets, and requires evidence before the implementation is admitted.
The repository-controlled build path
execution packets
The sophisticated control layer stays inside the repository. The user path remains simple: define the system, review the contracts, let the agent build, and inspect the evidence.
Options OS supplies the substrate. You define the engine.
| Area | Status | Responsibility |
|---|---|---|
| Options-native facts and contracts | PROVIDED | Reusable instrument, pricing, surface, portfolio, cost, hedging, messaging, and venue foundations. |
| Reference venue adapter | PROVIDED | Deribit implementation demonstrating the adapter contract and reconciliation boundary. |
| Specifications and engine scaffold | PROVIDED | The documented path for composing the framework into a buyer-owned engine. |
| Agentic build system | PROVIDED | Claude Code and Codex workflows, controls, and verification tooling. |
| Alpha and PnL mechanism | BUILDER-OWNED | Your thesis, signals, portfolio intent, and trading decisions. |
| Book, risk, and lifecycle policy | BUILDER-OWNED | Your runtime cycle, book model, limits, mandates, state transitions, and operating decisions. |
| Credentials, deployment, and live approval | BUILDER-OWNED | Your accounts, secrets, runtime configuration, monitoring, validation, and capital. |
The product is implemented code, specifications, and tooling.
The proof is in the repository itself: reusable options libraries, matching specifications, a working reference adapter, and an agentic build layer used by both Claude Code and Codex.
One framework. Any strategy.
These are examples, not a fixed catalogue. Options OS does not limit you to a predefined engine type. Define the trading system and use the same framework to build any crypto-options strategy around it. Your PnL logic remains private while the infrastructure beneath the engine stays reusable.
Example engine shapes
| Engine type | Framework support |
|---|---|
| Skew and surface-relative value | Options instruments, volatility facts, surface geometry, portfolio exposure, costs, and execution boundaries. |
| Calendar and term structure | Expiry-aware facts, multi-leg structures, portfolio aggregation, costs, and venue execution. |
| Market making | Normalized market facts, pricing, inventory exposure, orders, fills, and reconciliation. |
| Arbitrage and risk reduction | Comparable facts, portfolio state, cost-aware actions, hedge plans, and explicit commands. |
See how authors turn these engine shapes into actual systems.
The repository tells agents what to build and what counts as done.
Claude Code and Codex work from accepted specifications, explicit boundaries, and governed procedures. They do not have to reconstruct the architecture from scattered code or invent completion criteria during the build.
Describe the trading system and the decisions the engine must own.
Turn the accepted definition into explicit engineering contracts.
Implement against the supplied framework and reference boundaries.
Close the build with tests, audits, and conformance evidence.
Bring the alpha. Build on the framework underneath it.
Options OS is for software engineers, technical founders, and engineering-led trading teams that want inspectable source, options-native infrastructure, and a disciplined way to build with coding agents.
Options OS is probably a fit if
- You are building a crypto-options trading engine
- You can define the strategy and operating policy
- You want Claude Code or Codex working from specifications
- You want inspectable source and explicit system boundaries
Not the product
- A profitable strategy or signal service
- A one-click trading bot
- A hosted execution platform
- A substitute for operational validation and live approval
If all four are true, see how Options OS takes an engine from definition to verified implementation.