Files
arbitrade/docs/architecture/current-implementation.md

2.9 KiB

Current Implementation Snapshot

This document summarizes the code that exists now, not the original plan.

Runtime

Configuration Management

  • Complete configuration management system implemented with database-backed user settings.
  • Configuration service in src/arbitrade/config/service.py handles loading and applying settings.
  • Repository classes in src/arbitrade/storage/repositories.py provide database access.
  • Web UI for configuration at /dashboard/config/ with CRUD operations for:
    • Currency pairings
    • Fee configurations
    • Application settings
    • Backtesting parameters
  • Hot-reloading capabilities for runtime configuration changes.
  • Input validation and error handling for all configuration forms.
  • Audit logging for all configuration modifications.

Market Data and Detection

Execution and Risk

  • Multi-leg execution sequencer exists for triangular cycles.
  • Pre-trade validation and trade-limit guards are wired into execution flow.
  • Kill switch and stop conditions are supported.

Dashboard

  • Server-rendered dashboard uses FastAPI + Jinja2 + HTMX.
  • Live metrics, overview, controls, charts, and audit fragments are exposed as separate endpoints.
  • Dedicated backtesting page exists at /dashboard/backtesting.

Backtesting

Deployment

  • Dockerfile installs runtime dependencies from requirements/latest-runtime.in.
  • CI publishes git.allucanget.biz/allucanget/arbitrade:latest.
  • Coolify deploys the prebuilt image and owns runtime env vars and persistent storage.

Current Gaps

  • Cross-exchange arbitrage remains deferred.
  • Stat-arb is experimental, not part of default live strategy.
  • Backtesting UI is functional but still a single-run/report workflow, not a full job queue.