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.

The Genesis Watcher is a dedicated sub-pipeline that operates on the hardest possible signal: predicting a token’s outcome from its launch dynamics alone, before any tracked wallet has bought. Standard ML signals are reactive — they fire when a known good wallet acts. Genesis signals are predictive — they fire based on what the token’s first 60 seconds reveal about the quality of demand behind it. This is also the hardest signal to fake. A token’s first minute is a chaotic mix of bots, insiders, random retail, and occasionally genuine organic interest. The genesis models are trained on thousands of token launches to distinguish the patterns that survive from the ones that die within minutes.

60-second window

Every new token gets a 60-second observation window from its create event. Trades accumulate in memory and are scored at window close.

75-feature vector

The genesis vector captures 7 more features than the standard 68-feature model input, covering creator history, launch dynamics, buyer quality, and market context.

Dedicated model families

Separate ONNX model families target 2×, 3×, and 5× outcomes at timeframes from 5 minutes to 2 hours, each with its own score threshold.

​
How the observation window works

When a create event arrives from the Pump.fun program, the Genesis Watcher immediately opens an in-memory observation window for that token. Every trade event for that token over the next 60 seconds is accumulated in that window.
1

Window opens on create

The create event fires the moment the token is deployed to the Pump.fun program. The Genesis Watcher registers the token and starts accumulating trades. The clock starts immediately.
2

Early check at 30 seconds

At 30 seconds, an early evaluation runs. If the token shows signs of being already dead — no buys, curve not moving — the observation is aborted and the window is cleared from memory. No signal is wasted on a dead token.If the token shows exceptionally high conviction early (genesis score well above the strategy threshold), an early signal can be emitted before the full 60 seconds elapse, capturing the opportunity sooner.
3

Batch buyer lookup every 10 seconds

Every 10 seconds during active observation, the watcher performs a batch database lookup to resolve which current buyers are in the wallet database. This populates the buyer quality features and uses a Redis cache (wcache:<wallet>) with a 5-minute TTL to minimise redundant queries during burst periods.
4

Full scoring at 60 seconds

At window close, the complete 75-feature vector is assembled and passed through the genesis ONNX models. If any enabled strategy’s score exceeds its threshold and the dead-token veto does not apply, a genesis_signal is published to the trade:signals Redis channel.
The system handles up to 500 active observation windows simultaneously in memory. When this limit is reached, the oldest windows begin to be evicted to prevent unbounded memory growth during high-creation-rate periods.

​
The 75-feature genesis vector

Genesis features describe the token and its launch context, not a specific wallet. They are fundamentally different from the 68-feature standard vector used by wallet-based signals.
The creator’s track record is among the most predictive features available at launch time. The genesis vector captures:
  • Graduation rate across all prior tokens
  • Rug rate (tokens with last trade within 10 minutes of launch, never graduated)
  • Creator risk score (0–100 composite)
  • Serial velocity (tokens per day over the last 30 days)
  • Average insider wallet percentage across prior tokens
  • Average bot buyer percentage across prior tokens
  • Days since the creator’s last token launch
  • Whether the creator has ever had a token that graduated

​
Genesis model families and strategy targets

The genesis models are organised into strategy families, each targeting a different outcome at a specific timeframe. Each strategy has an independently calibrated ONNX model with its own score threshold.
StrategyTargetScore thresholdTake profitHold limit
genesis_2x_5m2× within 5 minutes90%2×5 minutes
genesis_3x_30m3× within 30 minutes90%3×30 minutes
genesis_3x_1h3× within 1 hour90%3×60 minutes
genesis_5x_2h5× within 2 hours80%5×2 hours
The watcher evaluates each enabled strategy in priority order and emits the highest-priority signal that exceeds its threshold. A token generates at most one genesis signal per observation window — the first strategy whose threshold is exceeded wins. The is_dead_5m probability acts as a universal veto: if the model predicts the token is likely dead within 5 minutes, the genesis signal is suppressed regardless of any target model’s score. This prevents high-conviction entries into tokens that are already dying.

​
Signal emission

When a genesis signal is confirmed, it is published to the trade:signals Redis channel in the following format:
Genesis signal payload
{
  "type": "genesis_signal",
  "data": {
    "tokenMint": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU",
    "symbol": "TOKEN",
    "creator": "9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM",
    "selectedStrategy": "genesis_3x_30m",
    "genesisScore": 0.93,
    "deadProb": 0.04,
    "aliveProb": 0.88,
    "predPeak": 4.2,
    "entryPrice": 0.000001234,
    "features": { }
  }
}
The full feature dictionary is included in the signal for logging and post-hoc analysis. The live trader uses selectedStrategy to look up the correct take-profit, stop-loss, and hold-time configuration from the strategy registry.
The predPeak value is the model’s predicted peak multiple within the strategy timeframe. It is informational and is not used directly for position sizing — only the selectedStrategy configuration governs execution parameters.

​
Key differences from standard wallet-based signals

DimensionStandard signalGenesis signal
TriggerKnown tracked wallet buysToken launch dynamics
Feature inputWallet history + token stateLaunch behaviour + creator history
Feature count68 features75 features
TimingReactive (after wallet buys)Predictive (within first 60s of launch)
Model families2×, 3×, 5× at 1h/4h/24h2×, 3×, 5× at 5m/30m/1h/2h
Dead-token vetoNoYes (is_dead_5m probability)
Entry advantageDetermined by wallet’s entry rankNear-genesis entry

ML models

How genesis ONNX models are trained, calibrated, and hot-reloaded alongside standard models.

Adversarial detection

How creator risk scoring and bundle detection feed into genesis feature computation.

Live trader strategies

How genesis strategies differ from standard strategies in take-profit, stop-loss, and hold-time configuration.

Market regime

How the market regime is encoded as a genesis feature and affects model predictions.

Build docs developers (and LLMs) love

Get started for freeTalk to us