Unified Trading Platform
Architecture combining multiple trading strategies under one dashboard with unified monitoring, risk management, cross-strategy capital allocation, and real-time DeFi portfolio analytics on Solana.
The Unified Trading Platform is the meta-project that ties together all of my individual trading bots and strategies into a single coherent system. Rather than running each bot as an isolated process with its own monitoring, the platform provides a unified dashboard, shared risk management layer, cross-strategy capital allocation, and centralized logging and alerting. It is the evolution from running a collection of scripts to operating a proper trading operation.
The motivation came from the growing pain of managing multiple bots independently. When you have capital deployed across a delta-neutral LP strategy, a conservative rebalancer, and a memecoin trading bot simultaneously, understanding your total risk exposure and aggregated PnL requires a unified view that no individual bot can provide. The existing tools for tracking Solana DeFi positions are fragmented -- each protocol has its own UI, and none give you a cross-protocol picture.
System Architecture
The platform follows a microservices-inspired architecture where each trading strategy runs as an independent worker process that communicates with a central orchestrator via a message bus. The orchestrator manages capital allocation, enforces portfolio-level risk limits, and serves the web dashboard. All communication happens over Redis streams, which provides both the pub/sub messaging pattern and durable message storage for replay.
interface StrategyWorker {
id: string
name: string
status: 'running' | 'paused' | 'error'
allocatedCapital: number
currentPositions: Position[]
metrics: StrategyMetrics
}
interface OrchestratorConfig {
strategies: StrategyWorker[]
totalCapital: number
maxDrawdown: number
allocationModel: 'equal' | 'risk-parity' | 'manual'
riskLimits: {
maxTotalExposure: number
maxSingleStrategyAllocation: number
correlationThreshold: number
}
}Portfolio Data Layer
The backend uses a combination of direct RPC calls and protocol-specific SDK integrations to fetch position data across Meteora, Jupiter, Orca, and Drift. Each protocol adapter implements a common interface that normalizes data into a unified position format. A background worker periodically refreshes all positions and caches the results in Redis, so the dashboard loads instantly even when on-chain queries are slow.
interface DeFiPosition {
protocol: 'meteora' | 'jupiter' | 'orca' | 'drift'
type: 'lp' | 'perp' | 'limit_order' | 'stake'
tokens: TokenAmount[]
valueUsd: number
unrealizedPnl: number
fees: { earned: number; paid: number }
}
interface ProtocolAdapter {
name: string
fetchPositions(wallet: PublicKey): Promise<DeFiPosition[]>
fetchHistoricalData(
wallet: PublicKey,
days: number
): Promise<HistoricalDataPoint[]>
}Historical snapshots are stored in PostgreSQL, enabling time-series analysis of portfolio performance across custom date ranges, cross-protocol yield comparisons, and a simple backtesting feature that replays allocation strategies against past market conditions.
Dashboard and Monitoring
The web dashboard is built with React and connects to the backend via WebSocket for real-time updates. It displays aggregated portfolio metrics at the top level and allows drilling down into individual strategy performance. Key views include a real-time PnL chart with strategy-level decomposition, a risk exposure heatmap, a yield tracker showing cumulative and rolling APY per protocol, an impermanent loss calculator comparing LP positions against a simple hold strategy, and a transaction log with filtering and search.
type DashboardEvent =
| { type: 'portfolio_update'; data: PortfolioSnapshot }
| { type: 'strategy_update'; data: StrategyUpdate }
| { type: 'trade_executed'; data: TradeExecution }
| { type: 'alert'; data: AlertNotification }
| { type: 'risk_breach'; data: RiskBreachEvent }Capital Allocation Engine
The capital allocation engine dynamically distributes capital across strategies based on their recent risk-adjusted performance. It supports multiple allocation models: equal-weight for simplicity, risk-parity for balancing volatility contributions, and manual overrides for when I want to tilt toward a particular strategy based on market conditions. Reallocation happens on a configurable schedule, with guardrails to prevent excessive turnover.
The engine also enforces portfolio-level constraints that no individual strategy can override. For example, the total portfolio drawdown limit will automatically pause strategies and reduce allocations if the aggregate loss exceeds a threshold, even if individual strategies are within their own limits. This prevents the scenario where multiple strategies experience correlated losses simultaneously without any single one triggering its own stop.
Infrastructure and Deployment
The entire platform runs on a single dedicated server with Docker Compose managing the individual services. Each strategy worker, the orchestrator, Redis, and the dashboard are all containerized and can be independently restarted without affecting the rest of the system. Logs are aggregated into a central store and alerts are routed through a notification service that supports Telegram, Discord, and email. A daily automated report summarizes portfolio performance, risk metrics, and any operational issues.
This project taught me that the operational infrastructure around a trading system is just as important as the strategies themselves. Reliable monitoring, fast alerting, and clean capital management are what separate a hobbyist setup from something you can trust with meaningful capital.