Execution Layer
The execution layer is responsible for routing approved trade intents to the correct venue at the best available price, then recording fills and feeding outcomes back into the performance measurement pipeline.
Trade path overview
A trade reaches execution after passing through the full feasibility gate sequence. By the time an intent arrives at the execution service, it has been verified for:
- Signal confidence above the active profile threshold
- Drawdown and exposure limits within bounds
- Kelly-sized position size computed and approved
- All circuit breakers cleared
- All opposing signals resolved
The execution service's job is to take that approved intent and place the order at the best available venue.
Smart Order Router
TRADEOS.tech uses a Smart Order Router (SOR) rather than a static venue priority list. When an approved intent arrives, the SOR evaluates all eligible venues in real time and selects the one with the lowest total cost of execution — not just the lowest headline fee.
Total execution cost has two components:
Fill cost — the actual price paid for the order, which depends on order book depth at the required size. A venue with a lower headline ask price may produce a worse actual fill if the order book is thin. The SOR simulates the fill by walking the order book at the order size to get a realistic fill price.
Cost of carry — for perpetual futures positions, the holder pays or receives a funding rate every 8 hours. For a long position held for 48 hours, the funding rate can easily exceed the fill price difference between venues. The SOR incorporates the expected cumulative funding cost over the strategy's estimated hold period into the total cost calculation.
The venue with the lowest combined fill cost + fee + carry cost wins the order.
Data sources
The SOR reads from Redis keys populated by the ingestion service:
- Order book snapshots — per-venue, per-instrument; updated continuously from live WebSocket feeds
- Funding rates — current and predicted next-settlement values from perpetual futures feeds
Order book snapshots older than a configurable staleness threshold are treated as unavailable. If all snapshots are stale, the SOR falls back to the static priority list. This graceful degradation ensures execution always completes, even during a brief ingestion hiccup.
US market routing
For US customers where Binance and Bybit are geo-blocked, the eligible venue set is:
- Longs (spot): Kraken Spot, Coinbase, Gemini
- Longs (futures): Kraken Futures perpetuals
- Shorts: Kraken Futures only
The SOR is aware of this constraint and only routes to eligible venues based on the deployment's configured region.
Paper trading execution
In paper mode, the SOR still selects the best venue based on real live order book data. The paper adapter then simulates the fill at that venue's real mid-price with ATR-scaled slippage. This means paper trading results reflect real venue pricing and depth conditions — not a simplified theoretical price.
Fill recording and feedback
Every fill — paper or live — is recorded in the audit ledger and published to the fills stream. The TCA monitor consumes this stream to compute:
- Transaction cost analysis (slippage vs. expected fill)
- Win rate and P&L attribution per signal type
- Sharpe, Sortino, and drawdown metrics for the active session
These metrics flow to the metrics API and dashboard, and also feed the autonomous agent's performance monitoring loop.
Position state management
The execution service maintains authoritative position state in PostgreSQL. Redis holds a hot cache for low-latency reads during the trade path. On reconnect, the PostgreSQL state is always the authority — Redis is reloaded from the database, not the other way around.
If the system cannot confirm a position's state (e.g., a network interruption during order confirmation), it defaults to treating the position as open and reconciles against the exchange API before proceeding. This conservative assumption prevents double-entry into an already-open position.