Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/0xW1re/solvedocs/llms.txt

Use this file to discover all available pages before exploring further.

The live trader is a standalone process that subscribes to the signal channel, scores incoming signals using ONNX models loaded directly in-process, and executes buys and sells on the Pump.fun bonding curve. It runs alongside the main pipeline independently — it can be restarted, upgraded, or paused without affecting data collection or intelligence processing.

​
How it works

Signals arrive on a real-time channel. Each signal type routes to a different handler, then flows through portfolio management, execution, and exit monitoring: 
Signal channel (real time)
         │
         ├── type: signal         → InlineScorer → strategy selection → buy
         ├── type: genesis_signal → InlineScorer → strategy selection → buy
         └── type: anti_signal    → force-exit any open position in that token
                  │
                  ▼
         PortfolioManager
         (phase check, concurrent position limit, circuit breakers, sizing)
                  │
                  ▼
         TradeExecutor
         (Bonding curve execution, atomic bundles)
                  │
                  ▼
         ExitMonitor (3s poll)
         (take-profit, stop-loss, timeout, anti-signal force exit)

​
Inline scoring

Rather than waiting for the main pipeline’s MlInference 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 includes all the fields needed to build the feature vector, so no database round-trip is required. A decision is made within milliseconds of the signal arriving.
Inline scoring uses the same ONNX model files and calibration parameters as the main pipeline’s MlInference service. The outputs are numerically identical — the only difference is where the computation runs.

​
Strategy selection

When a signal arrives, the trader evaluates all strategies that are eligible given the current phase and balance. A strategy must pass all six criteria to be considered:
  1. The ML model’s calibrated probability must meet or exceed the strategy’s score_threshold
  2. The dead_prob must be below the strategy’s dead_threshold
  3. The current phase must be ≥ the strategy’s min_phase
  4. A concurrent position slot must be available
  5. No position must already be open in that token
  6. The token must not be in per-token cooldown (30 minutes after a close)
If multiple strategies qualify, the highest-priority one is selected. Priority is defined in the strategy configuration, not inferred at runtime.

​
Execution

The TradeExecutor handles all on-chain execution:
1

Derive bonding curve account

The bonding curve account address is derived deterministically from the token mint, with no RPC lookup required.
2

Calculate expected output

The exact expected token output is calculated from the bonding curve math before the transaction is sent, so slippage is known in advance.
3

Submit atomic bundle

The transaction is constructed and submitted as an atomic bundle. It either lands exactly as constructed or not at all — there is no partial fill or unexpected slippage. Execution is prioritised for fast landing during high-congestion periods.

​
Exit monitoring

An exit monitor polls every 3 seconds for each open position, checking against real-time price data maintained in the cache layer by the pipeline’s CurveManager. Four exit conditions are checked in order:
ConditionTriggerLog reason
Take profitCurrent price ≥ entry × take_profit_multipletake_profit
Trailing stopPrice dropped >15% from peak multipletrailing_stop
Stop lossCurrent price ≤ entry × stop_loss_multiplestop_loss
TimeoutHold time exceeded strategy’s max_hold_minutestimeout
Additionally, if an anti_signal arrives for a token with an open position, the position is force-exited immediately regardless of current price, profit, or hold time. The anti-signal response takes priority over all other exit logic.

​
Simulation mode

The live trader can be run in simulation mode where every decision — score evaluation, strategy selection, position sizing, exit logic — executes exactly as in live mode, but no transactions are submitted on-chain. All decisions are logged in full detail.
Run in simulation mode before deploying capital to validate a new model or strategy configuration. Simulation mode exercises the entire decision path, including circuit breakers and sizing, so the output is directly comparable to live behaviour.

​
Persistence

Every trade is fully persisted to the database. On restart, the trader loads all open positions from the database and resumes monitoring them. No positions are lost across restarts. The live_portfolio table tracks the overall portfolio — current balance, total P&L, win count, loss count, and streak data — and is the single source of truth for performance reporting.

Build docs developers (and LLMs) love

Get started for freeTalk to us