Phase 3: ML inference and advanced intelligence

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.

Phase 3 is where the system’s analysis converges. Every data point produced by Phases 1 and 2 — wallet features, token lifecycle states, bundle detections, creator risk scores, co-occurrence graphs, and market regime — is assembled into a feature vector and scored by a LightGBM model in real time. Simultaneously, a set of advanced detectors scan for structural risks that the ML model cannot catch alone: copy trading, coordinated operators, signal crowding, and alpha decay.

​

MlInference

The MlInference service scores every unscored signal on a 5-second cycle. At startup it loads all .onnx model files from src/ml/models/ and hot-reloads them every 5 minutes, so new models can be deployed without restarting the pipeline.

​

Models and targets

The pipeline can run multiple models simultaneously, each targeting a specific outcome: Each model is stored alongside a _metadata.json sidecar containing the model ID, target name, ordered feature list (68 features), calibration parameters, and the PR-AUC achieved on held-out evaluation data.

​

Probability calibration

Raw LightGBM output probabilities tend to be systematically under- or over-confident relative to empirical hit rates. Every model is calibrated using Platt scaling, which applies a learned sigmoid transformation σ(a·x + b) where a and b are fitted on held-out data. The calibrated probability is what gets written to the database and what strategy thresholds are set against.

​

Composite scoring

When multiple models are loaded, the inference service computes a composite score per signal. Rather than averaging all model outputs, the composite logic weights each model by how well its context matches the signal being scored — considering token age, lifecycle state, and which features are populated. This conservative weighting prevents a high score on an irrelevant target from inflating the composite.

​

AntiSignalEmitter

The AntiSignalEmitter runs every 30 seconds and scans all tokens that have received buy signals in the last 15 minutes. For each token it evaluates six independent risk triggers simultaneously: An anti-signal is only emitted if 2 or more triggers fire simultaneously. This multi-trigger requirement substantially reduces false positives: a high creator risk score alone could reflect a one-time bad launch; combined with a high bot buyer percentage, the picture changes. Anti-signals are published to the trade:signals Redis channel with type anti_signal. The live trader handles anti-signals by force-exiting any open position in the flagged token, bypassing normal take-profit and stop-loss logic.

​

DeepDiveWorker

The DeepDiveWorker performs enriched on-demand wallet analysis for wallets that meet escalation criteria — typically wallets that have just generated their first high-confidence signal. Rather than running on a fixed interval, it processes a queue of wallets flagged for deep analysis. A deep dive goes beyond the 30-minute feature computation cycle, pulling full trade history, computing extended behavioural profiles, and cross-referencing against known bot signatures and operator clusters. Results are merged back into wallet_features and may trigger an immediate alpha score update.

​

CopyTradeDetector

The CopyTradeDetector runs every 15 minutes and analyses wallet_co_occurrence for pairs exhibiting directional consistency. A wallet pair is a copy-trade candidate when all three conditions hold:

• The pair shares at least 5 tokens in common
• One wallet buys first more than 75% of the time
• The standard deviation of the time delay between their buys is under 120 seconds

Candidate pairs are classified into one of three types based on their average delay and delay consistency: Each detected pair is assigned a confidence score (0–1) based on consistency, sample size, and directional ratio. Pairs below 0.3 confidence are discarded. The remaining pairs are used to distinguish between originator signals (high value) and follower signals (lower value — acting on information already acted upon by the leader).

​

OperatorDetector

The OperatorDetector identifies coordinated operator clusters: groups of wallets that act together across multiple tokens in patterns that suggest shared infrastructure or control. Unlike the BundleDetector (which focuses on short time windows on a single token), the OperatorDetector looks for long-horizon coordination across many tokens. Wallets identified as belonging to an operator cluster have this relationship recorded in wallet_features, and the information is available as a feature in the ML model. A signal from a wallet inside a known operator cluster is interpreted differently depending on the cluster’s historical quality score.

​

AlphaDecayTracker

The AlphaDecayTracker answers a question that most signal systems ignore: if you see this wallet buy a token, how long do you have before the edge disappears? It runs hourly and computes a decay curve for every wallet with at least 15 signals in the last 30 days. For 8 delay buckets (1s, 5s, 10s, 30s, 60s, 120s, 300s, 600s), it calculates the average return achievable if you bought N seconds after this wallet’s signal. From the decay curve, two summary statistics are derived: Both values are stored in wallet_features and are available as features in downstream systems. The live trader can use a wallet’s half-life to set execution urgency — a 5-second half-life wallet triggers a Jito-bundled submission; a 5-minute half-life wallet can use standard submission.

​

SignalCrowdingDetector

The SignalCrowdingDetector runs every 60 seconds and detects tokens where the system’s tracked wallets collectively represent a significant fraction of the bonding curve’s current SOL reserves. When tracked wallets own a large share of the curve, there are fewer independent buyers available to purchase from them — the signal’s actionability is structurally compromised. Results are cached in Redis at crowding:<mint> with a 2-minute TTL. The live trader checks this cache before entering any position and can refuse entry when crowding is at the SEVERE level.

​

MarketRegimeDetector

The MarketRegimeDetector classifies the overall Pump.fun market state every 10 minutes using four observable signals: token creation rate (per hour), graduation rate over 2-hour and 24-hour windows, total SOL volume, and active unique wallet count. It also incorporates recent signal hit rates from live trading history to adjust for lagged market changes. Four regime states are defined: The current regime is cached in Redis at market:regime and included as a feature in both the standard and genesis ML models. The live trader and signal scorer can read this value directly to adjust position sizing thresholds — for example, reducing maximum position size during bear conditions.

​

ModelMonitor

The ModelMonitor tracks the live performance of every loaded ML model by comparing calibrated output probabilities against observed signal outcomes. It maintains a running record of predicted probability vs. actual hit rate, binned by probability decile. When the calibrated probabilities diverge significantly from observed hit rates — indicating that the model’s understanding of the world no longer matches reality — the ModelMonitor logs a drift warning. This is a signal that the model should be retrained on more recent data before the miscalibration propagates into live trading decisions.