Vigil.
Most trading automation systems are either too simple to be useful or too complex to be maintainable by a lean team. Vigil was designed around one constraint: if something breaks at 3 AM, you need to find and fix it in minutes. The entire system is a single Python process. No microservices. No message queues. No distributed systems. Five modular signal strategies feed a central orchestrator that runs every 60 seconds and decides what to do with what they return.
The Design Problem
Complexity is the
enemy of lean operations.
Most algorithmic trading frameworks are built for large teams. They use microservices, distributed message queues, and container orchestration that requires specialist knowledge to debug under pressure. For a boutique trading desk or agile team, this complexity is not a feature. It is a liability.
The guiding principle for Vigil was: every file has one job, you should be able to describe what any file does in one sentence, and if you cannot, it is doing too much and needs splitting.
The result is a system that a lean team can fully understand, modify, and debug from memory, because the entire architecture fits in working memory at once.
Three Design Rules
Every module is a Python file
No Django. No FastAPI. No microservices. No Kubernetes. Each module is a .py file with a class. If you can read Python, you can understand the entire system.
All modules speak dictionaries
Every piece of data flowing through the system is a Python dictionary with a defined schema. No custom objects, no protobuf, no serialisation layers. A trade proposal in is a trade proposal out.
Skills never talk to each other
Signal strategies only communicate with the orchestrator. You can delete, add, or completely rewrite any strategy without touching any other file in the system.
Architecture
Brain, eyes, hands.
Cleanly separated.
The Main Loop
The orchestrator runs one complete cycle every 60 seconds. Each cycle follows the same sequence: classify market state, collect data from all feeds, run all five strategies, collect their proposals, pass each to the risk manager, execute approved proposals, track open positions, log everything. Then wait 60 seconds and repeat. This is the heartbeat of the entire system and it never changes.
The market state module classifies current conditions as trending, ranging, or volatile. This classification is passed to all five strategies so each can adjust its behaviour to current conditions without running its own market analysis.
Exchange feeds pull OHLCV data via WebSocket streams. Funding rates are collected from multiple exchanges simultaneously. On-chain monitoring tracks whale wallet movements and exchange inflows. Sentiment feeds pull Fear and Greed index, social volume, and liquidation data.
All five strategies run with the current market state and fresh data. Each returns a TradeProposal dictionary or None. Strategies do not know about each other. The orchestrator collects all proposals and decides what to do with them.
Each proposal passes through the risk manager before any execution. Position sizing, exposure limits, and current open positions are evaluated. The sentiment veto strategy can block any proposal regardless of signal strength. Only approved proposals become ApprovedTrade dictionaries.
Approved trades execute via ccxt on Binance or Bybit. Every trade is logged with full context: which strategy proposed it, what the market state was, what the risk manager evaluated, and the outcome. Performance is tracked per strategy with win rate and Sharpe ratio.
The Five Strategies
Strategy 1
Funding Rate Arbitrage
Identifies funding rate differentials across exchanges. When one exchange pays significantly higher funding than another, the delta is capturable with neutral market exposure.
Strategy 2
Smart Money Tracking
Monitors on-chain whale wallet movements and exchange inflow and outflow data. Large coordinated movements from tracked wallets generate directional signals.
Strategy 3
Momentum and Breakout
Detects breakouts from consolidation ranges using volume confirmation. Only activates in trending market states. Sits idle during ranging and volatile conditions.
Strategy 4
Mean Reversion
Identifies overextension from moving averages in ranging conditions. Trades the return to mean. Only activates in ranging market states, the inverse of strategy 3.
Strategy 5 (Veto)
Sentiment Filter
Not a trading strategy. A blocking layer. When Fear and Greed or liquidation data hits extreme thresholds, this module vetoes all proposals from all other strategies regardless of their signal strength.
Technology
25 files.
One job each.
Vigil runs as a single Python process on a single VPS. This is a deliberate constraint, not a limitation. No inter-process communication. No network calls between modules. No distributed systems. When something fails, you look in one place.
The Telegram bot is the entire control interface. Status commands, position queries, and a kill switch that halts the orchestrator mid-cycle are all accessible from a phone. The system can be fully managed without SSH access during normal operation, making it practical for lean teams who need reliable automation without dedicated infrastructure staff.
Full Stack
Why no framework?
FastAPI, Django, or any web framework would add complexity with no benefit for a single-process system. Frameworks are for teams and APIs. Vigil has one operator and no external API surface. Every framework you add is another thing to learn, maintain, and debug under pressure.
What We Learned
Architecture decisions
have long shadows.
Simplicity is a competitive advantage for lean operations. Every framework and abstraction layer you add is technical debt that arrives without warning at the worst possible time. Vigil was designed to be the simplest thing that could possibly work correctly.
Independent modules are worth the extra planning upfront. The strict rule that strategies never communicate directly meant that adding a new strategy or removing a broken one took under an hour. Without that separation, every change would have required tracing dependencies across the system.
A veto layer is more valuable than another signal layer. Adding a sixth signal strategy would increase noise. Adding a blocking filter that prevents all execution under specific adverse conditions is a meaningful risk reduction. Strategy 5 exists because the marginal value of an additional signal is lower than the marginal value of a reliable stop.
Mobile control matters more than a dashboard. A terminal dashboard inaccessible without a laptop is not a real control interface. The Telegram kill switch means the system can be halted from anywhere with a phone signal. For a boutique desk running lean, that is the only control surface that actually matters during an adverse event.