Skip to main content

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.

Alpha Leak uses LightGBM gradient boosting models compiled to ONNX format and executed in-process via onnxruntime-node. There is no separate inference server — models run inside the same Node.js process as the pipeline, which eliminates a network hop and keeps inference latency in the low milliseconds even at high signal throughput.

​
Model families

Two families of models operate concurrently, each answering a different question about token price trajectory.

Standard models

Score signals from tracked wallet buys using a 68-feature vector. Answer: given what we know about this wallet, this token, and the current market, what is the probability that price reaches X× within Y minutes?

Genesis models

Score newly created tokens based on their first-60-second behaviour using a 75-feature vector. Answer: given the launch dynamics of this token, what is the probability it reaches X× within Y minutes?
Both families use LightGBM binary classification, compiled to ONNX and calibrated with Platt scaling before deployment.

​
Standard model targets

The four standard models each target a distinct prediction horizon and are consumed independently by different trading strategies.
Model fileTargetUse case
reach_2x_1h.onnxProbability of 2× in 1 hourPrimary strategy: reach_2x_1h
reach_3x_30m.onnxProbability of 3× in 30 minutesPhase 2+ strategy: reach_3x_30m
reach_2x_10m.onnxProbability of 2× in 10 minutesPhase 3 strategy: reach_2x_10m
is_dead_soon.onnxProbability of imminent deathVeto signal, combined with others

​
ONNX deployment

Each model is stored as a file pair in src/ml/models/. The .onnx file contains the compiled model weights; the _metadata.json sidecar contains everything the inference code needs to use it correctly. 
src/ml/models/
  reach_2x_1h.onnx              # Compiled model weights
  reach_2x_1h_metadata.json     # Feature list, calibration params, PR-AUC
The metadata file determines the order in which features are assembled into the input tensor. A mismatch between the metadata feature list and the order used at inference time will silently corrupt every prediction — the model will produce numerically valid but meaningless outputs with no runtime error.

​
Metadata format

The _metadata.json file follows this schema: 
{
  "model_id": "reach_2x_1h_v3",
  "model_type": "classification",
  "target": "reach_2x_1h",
  "version": 3,
  "feature_names": ["alpha_score", "wallet_graduation_rate", ...],
  "feature_count": 68,
  "calibration": {
    "method": "platt",
    "platt_a": 1.42,
    "platt_b": -0.31
  },
  "pr_auc": 0.34
}
The feature_names array is the canonical ordered feature list for that model version. The inference code reads this array and assembles the Float32Array input tensor in exactly that order, substituting default values for any missing features.

​
Hot reloading

The model directory is scanned every 5 minutes. If a new .onnx file appears that is not already loaded, it is immediately loaded into an ONNX session and added to the active model set. ONNX sessions from previous model versions are released to free memory.
This means you can deploy a new model version simply by copying the .onnx and _metadata.json pair into the models directory. The pipeline picks it up within 5 minutes without any restart required.

​
Calibration

Raw LightGBM outputs are probability-like but often miscalibrated — the model may output 0.70 for signals where the actual hit rate at that probability level is only 0.50. This makes raw scores unreliable as thresholds in strategy configs. Every model is calibrated post-training using Platt scaling: a sigmoid function fitted on a held-out calibration set. The transformation applied at inference time is: 
calibrated_prob = σ(platt_a × raw_prob + platt_b)
                = 1 / (1 + exp(-(platt_a × raw_prob + platt_b)))
The platt_a and platt_b parameters come from the model’s _metadata.json. After calibration, a model output of 0.80 means approximately 80% of signals at that score level actually hit the target — which is what makes the threshold values in strategy configuration meaningful rather than arbitrary.

​
Inference pipeline

Every 5 seconds, MlInference fetches unscored signals from the database and runs them through all loaded models. Each signal goes through the same five steps:
1

Assemble the feature vector

The 68-feature vector is assembled in the canonical order defined by the model’s feature_names metadata. Default values are substituted for any features that are unavailable for this signal.
2

Create the input tensor

Each model’s input is a Float32Array of shape [1, 68], one row per signal. For genesis models the shape is [1, 75].
3

Run the ONNX session

The ONNX runtime executes the model graph. For binary classification models the output is a [1, 2] probability tensor; the second element — P(class=1) — is extracted as the raw score.
4

Apply Platt calibration

The raw probability is passed through the sigmoid transform using the platt_a and platt_b parameters from the model’s metadata file.
5

Write scores to the database

The calibrated score is written back to the signals table in the appropriate score column. Scores are immediately available to the live trader via Redis PubSub.

​
Composite scoring

When multiple models are loaded, all four are run against every signal and their scores are stored independently. The live trader reads the score that corresponds to its configured strategy target.
ColumnSource model
ml_score_1hreach_2x_1h.onnx
ml_score_30mreach_3x_30m.onnx
ml_score_10mreach_2x_10m.onnx
dead_probis_dead_soon.onnx
The dead_prob score acts as a veto across all strategies. A signal with ml_score_1h = 0.85 and dead_prob = 0.03 is a strong candidate for the reach_2x_1h strategy. The same signal with dead_prob = 0.40 would be rejected regardless of its primary score.

​
Fallback behaviour

If onnxruntime-node is not installed, or if no model files are present in the models directory, the pipeline degrades gracefully rather than failing.
This means the pipeline can be run from day one without any trained models. It will collect signals and wallet data, which can later be used to train the first model.
  • MlInference logs a warning at startup and disables itself
  • All signals receive ml_score = NULL
  • The live trader falls back to COALESCE(ml_score_1h, rule_score, 0), using the rule-based composite signal score as its primary decision metric
  • All other pipeline phases — ingestion, scoring, intelligence — continue operating normally

Feature reference

Complete documentation for all 68 features in the standard model vector.

Training methodology

How models are trained, calibrated, exported, and hot-reloaded.

Build docs developers (and LLMs) love

Get started for freeTalk to us