Tesser Project Roadmap

[EwigMidori]

Tesser Project Roadmap: 2025 - 2027

Vision: The Industrial-Grade Execution Infrastructure

Tesser is the operating system for professional quantitative trading teams ($10M - $100M AUM). These teams have outgrown fragile Python scripts but cannot justify the immense cost of proprietary C++ systems.

Our Core Philosophy:

1. Reliability First: We prioritize system uptime, state recovery, and atomic safety checks. We build systems that let traders sleep at night.
2. Execution Over Prediction: We focus on the "how" of trading—smart order splitting and lifecycle management—where PnL is often lost.
3. Unified Workflow: We bridge the gap between research and production, ensuring that the logic validated in Python is identical to what executes in Rust.

Anti-Goals:

• No GUI Configuration: Tesser is configured via code and TOML. We do not build drag-and-drop strategy builders.
• No "Get Rich Quick": Tesser is infrastructure, not a money printer. We provide the rails; you build the train.
• No Closed-Source Core: The runtime will always be open.

Phase 1: The "Immortal" Core & Connectivity (Months 1-4)

Goal: Deliver a production-ready Rust execution engine immediately. It must connect to real exchanges and survive process crashes from Day 1.

1.1 The Resilient Runtime

• Objective: Solve the No.1 pain point of current open-source bots: fragility.
• Key Deliverables:
  • In-Memory State Machine + WAL: A high-throughput architecture using a Write-Ahead Log (WAL) for persistence.
  • Crash Recovery Protocol: Logic that reads the WAL on startup to reconstruct the exact state of every order.
  • Auto-Reconciliation: Upon restart, the engine automatically fetches open orders from the exchange, compares them with local state, and resolves discrepancies (adopt/cancel) without human intervention.

1.2 Standardized Connectivity (Binance & Bybit)

• Objective: Give the community immediate access to major liquidity pools.
• Key Deliverables:
  • Unified Connectivity SDK: Production-grade connectors for Binance Futures and Bybit.
  • Resilient WebSocket Manager: Handles silent disconnects, heartbeats, and automatic re-subscription logic.
  • Smart Rate Limiter: Local token buckets that strictly adhere to complex exchange weight rules to prevent IP bans.

1.3 The Data Flight Recorder

• Objective: "If it isn't logged, it didn't happen."
• Key Deliverables:
  • Parquet Logging: Write market ticks and execution events directly to local Apache Parquet files. This builds the foundation for future analysis.
  • Atomic Risk Gate: Hard limits (Fat Finger protection) checked before any network request.

Phase 2: The Research Bridge (Months 5-9)

Goal: Break the "Rust Island" isolation. Bring Python users into the ecosystem early by enabling them to analyze Tesser's data and state.

2.1 tesser-py Alpha: Data & State Access

• Objective: Enable quants to use their favorite tools (Pandas/Jupyter) with Tesser.
• Key Deliverables:
  • Parquet Reader Bindings: Efficiently load Tesser's "Flight Recorder" data into Pandas/Polars frames for analysis.
  • Live State Inspector: A Python client that can query the running Rust engine (via IPC/gRPC) to fetch real-time PnL, positions, and active orders. No strategy control yet, just observability.

2.2 Data Lake Foundation

• Objective: Standardize historical data management.
• Key Deliverables:
  • Data Cleaning CLI: Tools to scan downloaded Parquet files for gaps and anomalies.
  • Normalization Layer: Ensure historical data schema perfectly matches live data schema.

Phase 3: The "Smart Executor" (Months 10-14)

Goal: Elevate Tesser from an "Order Sender" to an "Order Manager." This phase delivers the complex execution logic that defines professional systems.

3.1 Complex Order State Machines

• Objective: Native support for long-running algorithms that must survive restarts.
• Key Deliverables:
  • Robust TWAP/VWAP: Execution algos that persist their progress (e.g., "30% filled").
  • Pegged Orders (Maker Logic): State machines for maintaining passive liquidity, including "chase" and "retreat" logic.
  • Iceberg Orders: Logic to hide large order sizes.

3.2 Hot-Swappable Strategy Architecture

• Objective: Accelerate developer iteration speed.
• Key Deliverables:
  • Dynamic Module Loading: Refactor the OrderOrchestrator to load execution logic from dynamically linked libraries.
  • Benefit: Developers can recompile and reload a strategy module in seconds without restarting the main engine or dropping network connections.

3.3 TCA Lite (Transaction Cost Analysis)

• Objective: Quantify the value of Smart Execution.
• Deliverables:
  • Slippage Reporting: Automated reports comparing "Arrival Price" vs. "Average Fill Price."

Phase 4: Simulation & Parity (Months 15-19)

Goal: Close the loop. Enable "True" backtesting and full Python strategy control.

4.1 High-Fidelity Streaming Backtester

• Objective: Simulate months of tick data on standard hardware.
• Key Deliverables:
  • Streaming Engine: Stream tick data directly from disk (Parquet) through the strategy logic, bypassing RAM limits.
  • Exchange Simulator: Simulates latency, partial fills, and queue position (mocking the matching engine) for realistic results.

4.2 Full Python Strategy Control

• Objective: Allow strategies to be written entirely in Python if desired.
• Key Deliverables:
  • tesser-py Strategy API: Expose the full Strategy trait to Python. Users can write on_tick in Python, while the Rust engine handles the heavy lifting of networking, state management, and risk checks.

(Note: Pure Rust strategies will always be supported and recommended for <1ms latency requirements. Python control is an optional layer for ease of use.)

Phase 5: Institutional Scale (Months 20-24)

Goal: Introduce features required by larger organizations and complex multi-strategy setups.

5.1 Multi-Tenancy & Isolation

• Objective: Support funds running multiple independent strategies.
• Key Deliverables:
  • Sub-Account Isolation: Logically segregate PnL and positions for different strategies sharing one master exchange account.
  • Global Risk Manager: Hierarchical risk limits (Strategy Level vs. Firm Level).

5.2 The "Commander's Dashboard"

• Objective: Visual control for operations.
• Key Deliverables:
  • Real-time Web UI: Live view of aggregate PnL and exposure.
  • Manual Intervention: GUI to manually cancel orders or flatten positions during emergencies.

5.3 Smart Routing Foundation

• Objective: Aggregating liquidity.
• Key Deliverables:
  • Unified Order Book: Real-time aggregation of depth from multiple exchanges.
  • Best Execution Router: Framework for routing orders to the venue with the best price.

Join the Discussion

This roadmap represents our current hypothesis on how to solve the "Fragility Problem" in quantitative infrastructure. But we know that the best systems are built with community feedback.

We want your brutal honesty:

1. Are we prioritizing correctly? Should Phase 2 (Data) come before Phase 1.2 (Connectivity)?
2. The Python/Rust Bridge: How do you prefer to interact with Rust cores? gRPC? FFI? Shared Memory?
3. Missing Features: What is the one "deal-breaker" feature that keeps you on your current stack?

Next Steps:

• Watch this repo: We will be releasing the Phase 1.1 Alpha (Crash Recovery Demo) in the coming weeks.
• Comment below: Tear this roadmap apart. We are here to build something that lasts, not something that looks good on paper.

Let's build the infrastructure we actually want to use.