Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/alphaleaks60-maker/solvedocs2/llms.txt

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

Standard ML signals fire when a tracked wallet buys — they are, by definition, reactive. The Genesis Watcher is different: it attempts to predict a token’s outcome from its launch dynamics, before any tracked wallet has touched it. This is the hardest possible signal to get right, and the hardest 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 to distinguish the patterns that survive from the ones that die.

​
Observation Flow

1

Token creation detected

When a create event arrives from the Pump.fun program, the Genesis Watcher immediately opens an observation window for that token. Every subsequent trade event for that token is accumulated in memory. The system handles up to 500 active tokens simultaneously before the oldest windows begin to be evicted.
2

30-second early check

At 30 seconds, a preliminary assessment runs. If the token shows signs of being already dead — no buys, curve not moving — the observation is aborted immediately and no compute is wasted. If the token shows exceptionally high conviction already (score well above threshold), an early signal can be emitted before the full window elapses.
3

Buyer lookup (every 10 seconds)

Throughout the active window, a batch DB lookup runs every 10 seconds to resolve which current buyers are in the wallet database. This populates the buyer quality features and is the most I/O-intensive part of the genesis pipeline. Results are cached at wcache:<wallet> with a 5-minute TTL to minimise redundant queries during burst periods.
4

Full feature vector assembled at 60 seconds

At 60 seconds, the complete 75-feature vector is assembled and run through the genesis ONNX models. Each enabled strategy is evaluated in priority order.
5

Signal emitted (if threshold exceeded)

If a strategy’s score exceeds its threshold and the dead-probability veto does not apply, a genesis_signal is published to the trade:signals Redis channel for the live trader to consume. A token generates at most one genesis signal per observation window.

​
The 75-Feature Genesis Vector

Genesis features describe the token and its launch context, not a specific wallet. This is what distinguishes genesis signals from standard wallet-triggered signals — the unit of analysis is the launch event itself.
  • Graduation rate, rug rate, and overall risk score
  • Serial velocity (tokens launched per day over last 30 days)
  • Average insider presence and average bot buyer percentage across prior tokens
  • Days since last token launched
  • Whether the creator has ever had a graduated token

​
Genesis Strategies

The genesis models support multiple strategy configurations, each targeting a different return/time outcome. The watcher evaluates each enabled strategy in priority order and emits the highest-priority signal exceeding its threshold.
StrategyTargetScore ThresholdTake ProfitHold Limit
genesis_3x_30m3× in 30 minutes90%3×30 min
genesis_5x_2h5× in 2 hours80%5×2 hr
genesis_2x_5m2× in 5 minutes90%2×5 min
genesis_3x_1h3× in 1 hour90%3×60 min
The dead-probability model (is_dead_5m) acts as a veto: if the model predicts the token is likely dead within 5 minutes, the genesis signal is suppressed regardless of the target model’s score. No strategy threshold overrides this veto.

​
Signal Payload

The genesis signal published to Redis includes the full feature dictionary for logging and post-hoc analysis. The live trader uses selectedStrategy to look up the correct take-profit, stop-loss, and hold-time configuration. 
{
  "type": "genesis_signal",
  "data": {
    "tokenMint": "...",
    "symbol": "TOKEN",
    "creator": "...",
    "selectedStrategy": "genesis_3x_30m",
    "genesisScore": 0.93,
    "deadProb": 0.04,
    "aliveProb": 0.88,
    "predPeak": 4.2,
    "entryPrice": 0.000001234,
    "features": { "..." : "..." }
  }
}
The predPeak field represents the model’s predicted peak multiple, not a guaranteed return. It is useful for sizing decisions and post-trade analysis but should not be treated as a price target.

Build docs developers (and LLMs) love

Get started for freeTalk to us