The live trader (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/alphaleaks60-maker/docs2/llms.txt
Use this file to discover all available pages before exploring further.
src/live/live-trader.ts) is a standalone process that subscribes to the trade:signals Redis channel, scores incoming signals using ONNX models loaded directly into its own runtime, and executes buys and sells on the Pump.fun bonding curve via Jito bundles. It runs alongside the main pipeline — not as part of it — which means it can be restarted, upgraded, or paused independently without affecting data collection or intelligence processing.
How it works
The following diagram shows the full execution flow from signal arrival to position exit:Strategies
Phase-gated strategies, position sizing, and signal priority.
Circuit breakers
Hard stops for drawdown, consecutive losses, and minimum balance.
Monitoring
PostgreSQL tables, pipeline stats, and key log patterns.
Architecture
How the live trader fits into the full pipeline.
Inline scoring
Rather than waiting for the main pipeline’sMlInference service to score a signal and write it back to the database, the live trader runs ONNX inference inline — loading the same models and assembling the same feature vector independently.
This eliminates the 5-second lag between signal emission and ML score availability. The signal payload published on Redis includes all the fields needed to build the feature vector, so no database round-trip is required for scoring. A decision is made within milliseconds of the signal arriving.
The same ONNX model files used by the pipeline’s
MlInference service are loaded by the live trader. Hot-reloading every 5 minutes keeps both in sync when a new model is deployed.Strategy selection
When a signal arrives, the trader evaluates all strategies that are eligible given the current phase and portfolio state. Six conditions are checked in order before a position is opened:ML score threshold
The model’s calibrated probability must meet or exceed the strategy’s
score_threshold (typically 80% for standard strategies, 90% for genesis strategies).Dead probability veto
The
dead_prob output must be below the strategy’s dead_threshold. Strategies with no dead threshold skip this check.Phase eligibility
The current portfolio phase (determined by available balance) must be greater than or equal to the strategy’s
min_phase.Concurrent position slot
The number of currently open positions must be below the phase’s maximum concurrent position limit.
priority value in the strategy configuration is selected. Only one position is opened per signal event.
Execution
TheTradeExecutor handles all on-chain execution and follows four steps for every buy:
Derive bonding curve account
The bonding curve program-derived address is computed from the token mint using the Pump.fun program address. No RPC lookup is required.
Calculate expected output
The exact expected token output is calculated from bonding curve math before the transaction is built, avoiding slippage surprises at submission time.
Construct transaction
A transaction is constructed with a compute unit price (priority fee) and a Jito tip instruction added to the tip account.
Why Jito bundles
Submitting as a Jito bundle provides two concrete advantages over standard transaction submission:- Atomicity — the buy either lands exactly as constructed or not at all. There is no partial execution or unexpected state.
- Priority during congestion — validators running the Jito client service the bundle ahead of non-tipped transactions, reducing the chance of expiry during high-traffic periods on Pump.fun.
Exit monitoring
An exit monitor polls every 3 seconds for each open position, checking real-time price data from thetoken:<mint> Redis key maintained by the main pipeline’s CurveManager. Four exit conditions are evaluated in order:
| Condition | Trigger | Log reason |
|---|---|---|
| Take profit | Current price ≥ entry price × take profit multiple | take_profit |
| Trailing stop | Price has dropped more than 15% from its peak multiple | trailing_stop |
| Stop loss | Current price ≤ entry price × stop loss multiple | stop_loss |
| Timeout | Hold time has exceeded the strategy’s max_hold_minutes | timeout |
anti_signal arrives for a token with an open position, the position is force-exited immediately — the anti-signal response takes priority over all other exit logic regardless of current price, profit, or hold time.
Dry run mode
SetLIVE_DRY_RUN=true to run the trader in simulation mode. Every decision — score evaluation, strategy selection, position sizing, exit logic — executes exactly as in live mode, but no transactions are submitted to Solana.
Persistence and recovery
Every trade is fully persisted to PostgreSQL in thelive_trades table before any transaction is submitted, and updated on exit. On restart, the trader loads all open positions from the database and immediately resumes monitoring them. No positions are lost across restarts.
The live_portfolio table is the single source of truth for performance reporting:
| Table | Purpose |
|---|---|
live_trades | One row per trade: entry price, exit price, strategy, exit reason, net P&L |
live_portfolio | Running portfolio state: balance, total P&L, win count, loss count, streak |
The circuit breaker
halted flag and cooldownUntil timestamp are in-memory only and reset on process restart. This is intentional — a restart is a deliberate action that acknowledges the halt condition.