86f7f1fa76
Codebase audit identified 23 findings across 4 dimensions (production safety, code health, deployment readiness, test quality). This commit fixes all of them. Broker execution layer (was entirely stubbed): - Real IBKR TWS client via ibapi crate (950+ lines, feature-gated) - ICMarkets ctrader-openapi now always-on (removed feature flag) - Real broker routing with health monitoring and exponential backoff reconnect - Validated against live IB Gateway Docker (6/6 connectivity tests pass) Deployment blockers: - Fixed 6 broken Dockerfiles (removed COPY foxhunt-deploy) - Created foxhunt K8s namespace, secret templates, migration job - Added liveness probes to all 7 K8s services - IB Gateway manifest (ghcr.io/gnzsnz/ib-gateway:stable) - IBKR credentials in Scaleway Secret Manager via Terragrunt - Fixed port collisions and mismatches across services Production safety (9 critical + 6 high/medium fixes): - Asset-class-specific VaR volatility (not flat 2%) - Real parametric VaR with z-score 95th percentile - Kyle's lambda regression (100-bar rolling window) - Per-feature running statistics from historical data - VWAP-based slippage reference, regime duration tracking - Real Databento JSON parsing for OHLCV/Trade/Quote Code health: - Removed #![allow(dead_code)] from ml, data, config - Fixed log:: → tracing:: in 4 production files - Removed dead workspace deps (ratatui, crossterm) Verified: cargo check --workspace (0 errors), trading_engine 330 tests pass. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Trading Service
Overview
The trading_service is the core execution engine for the Foxhunt HFT platform. It manages the entire lifecycle of trading operations, from order placement and execution to real-time position keeping and risk management. This service is critical for high-frequency, low-latency trading activities, ensuring compliance and optimal performance.
Features
- Order Execution: Handles high-throughput order placement, modification, and cancellation across various exchanges.
- Position Management: Maintains real-time tracking of all open positions, including P&L calculations and exposure.
- Risk Integration: Integrates with upstream risk systems to enforce pre-trade and post-trade compliance checks.
- Compliance Checks: Automatically applies regulatory and internal compliance rules to all trading activities.
- Market Data Subscriptions: Subscribes to and processes real-time market data feeds for informed decision-making.
- Real-time P&L Tracking: Provides immediate profit and loss updates for active strategies and overall portfolio.
- Health Checks and Metrics: Exposes endpoints for monitoring service health and operational metrics.
gRPC API
The trading_service exposes a gRPC API for interacting with its core functionalities. Key endpoints include:
PlaceOrder- Submit new ordersCancelOrder- Cancel existing ordersGetPosition- Query current positionsSubscribeMarketData- Subscribe to market data feedsGetPnlUpdates- Retrieve real-time P&L updates
Running the service
To run the trading_service binary:
cargo run --bin trading_service
Configuration
The service is configured via the central config crate with PostgreSQL backend. Key configuration includes:
- Database connection strings
- Risk parameters and limits
- Broker connection settings
- gRPC server port and TLS settings
TLS Configuration (Agent S3)
The Trading Service supports TLS 1.3 with optional mutual TLS (mTLS) for secure gRPC communications.
Environment Variables:
TLS_ENABLED=false # Enable TLS (default: false)
TLS_CERT_PATH=/app/certs/trading_service/server.crt # Server certificate
TLS_KEY_PATH=/app/certs/trading_service/server.key # Server private key
TLS_CA_PATH=/app/certs/trading_service/ca.crt # CA certificate
TLS_REQUIRE_CLIENT_CERT=false # Require client certs (default: false)
Certificate Directory Structure:
/app/certs/trading_service/
├── server.crt # Server certificate
├── server.key # Server private key
└── ca.crt # CA certificate for client verification
Features:
- TLS 1.3 encryption for all gRPC traffic
- Mutual TLS (mTLS) support for client certificate authentication
- 6-layer certificate validation (expiration, purpose, constraints, extensions, SANs, revocation)
- Role-based access control (RBAC) via certificate Organizational Unit (OU)
- CRL (Certificate Revocation List) support
Security Note: TLS is disabled by default for development. Enable TLS_ENABLED=true for production deployments.
Testing
To run the tests for the trading_service crate:
cargo test --package trading_service
Documentation
Comprehensive API documentation is available at docs.rs/trading_service.