Phase 2 transforms raw trade and signal data into structured intelligence about tokens, creators, and the relationships between wallets. While Phase 1 asks how good is this wallet, Phase 2 asks what is happening around this token right now — and is that activity organic. The outputs of Phase 2 flow into both the ML feature vector and the anti-signal system in Phase 3, providing the context needed to distinguish genuine momentum from coordinated manipulation.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.
Overview
TokenLifecycle
Classifies every active token into one of 8 lifecycle states every 60 seconds using real-time velocity and age data.
BundleDetector
Identifies groups of wallets buying in coordinated 5-second windows, a key indicator of sniping or pump-and-dump operations.
CreatorRiskScorer
Builds a 0–100 risk profile for every token creator, measuring rug rate, insider presence, bot buyer share, and serial launch velocity.
CoOccurrence & GraphBuilder
Tracks which wallets buy the same tokens together and runs hourly graph analysis to identify high-quality wallet clusters.
TokenLifecycle
TheTokenLifecycle classifier assigns every active, non-graduated token a lifecycle state, updated every 60 seconds. It uses real-time velocity data — buys and sells in the last 60 and 300 seconds — alongside token age to determine the current state.
| State | Description |
|---|---|
launch | Token is under 60 seconds old |
early_accumulation | Under 5 minutes old with rising buy pressure |
momentum | Sustained buy velocity with new unique buyers |
euphoria | High velocity, strong SOL inflow, aggressive price action |
distribution | Smart wallets selling into retail buying — a key exit signal |
decline | Falling velocity, sell pressure increasing |
dead | No trades for 5 or more minutes |
graduated | Token has crossed 85 SOL and moved to Raydium |
distribution state is a strong negative signal; early_accumulation on a high-alpha wallet buy is one of the strongest positive ones.
BundleDetector
TheBundleDetector identifies coordinated buy activity: groups of wallets entering a token together within the same 5-second time window, a pattern consistent with sniping bots or organised pump-and-dump operations.
Scan schedule: every 10 minutes, covering the last 15 minutes of trades. On startup, a historical scan covers the last 24 hours in 2-hour chunks.
Detection logic: trades are grouped into 5-second time buckets per token. Any bucket with 3 or more distinct wallets becomes a cluster candidate. Each candidate is then scored:
| Signal | Confidence boost |
|---|---|
| Amount coefficient of variation < 0.3 (similar buy sizes) | +25% |
| Buy rank span ≤ wallet count (consecutive entries) | +20% |
| Cluster size ≥ 5 wallets | +15% |
| Cluster size ≥ 10 wallets | +10% |
detected_bundles. The detection method is recorded as one of time_window, similar_amounts, or same_slot_coordinated, depending on which signals are most prominent.
For every detected bundle, all wallet pairs in the cluster are written to
wallet_co_occurrence with an incremented overlap count. This data feeds both the co-occurrence analysis and the CopyTradeDetector in Phase 3.CreatorRiskScorer
TheCreatorRiskScorer builds a risk profile for every token creator with 2 or more tokens, updated every 30 minutes. The output is a 0–100 risk score that feeds directly into the ML feature vector and the AntiSignalEmitter in Phase 3.
The scorer computes five underlying metrics:
| Metric | Description |
|---|---|
| Rug rate | Share of tokens that died within 10 minutes of launch (last trade within 600s of creation, never graduated) |
| Avg insider presence | Average insider wallet count across this creator’s tokens |
| Avg bot buyer pct | Average share of buyers classified as bots across all tokens |
| Serial velocity | Rate of token creation — tokens per day over the last 30 days |
| Risk score | Weighted composite of the above, 0–100 |
CoOccurrence
TheCoOccurrence service builds and maintains a wallet-pair co-occurrence matrix in the wallet_co_occurrence table. Every time two tracked wallets buy the same token within a short window, their pair’s buy_overlap_count is incremented.
Additional metrics tracked per wallet pair:
| Field | Description |
|---|---|
avg_buy_delta_seconds | Average time between wallet A’s buy and wallet B’s buy |
buy_delta_stddev | Consistency of the delay — low stddev suggests systematic copying |
a_buys_first_ratio | How often wallet A buys before wallet B — a directional indicator |
CopyTradeDetector in Phase 3, which uses them to identify leader-follower relationships between wallets.
GraphBuilder
TheGraphBuilder runs every hour and spawns a Python subprocess (src/ml/graph_builder.py) to perform graph-level analysis on the wallet_co_occurrence data. Standard graph algorithms identify wallet clusters — groups of wallets that co-buy frequently.
For each identified cluster, it computes:
| Feature | Description |
|---|---|
cluster_size | Number of wallets in the cluster |
cluster_avg_grad_rate | Average graduation rate across wallets in the cluster |
co_occurrence_max_score | Highest co-occurrence score for the signal’s wallet within its cluster |
SignalScorer
TheSignalScorer computes a composite rule-based score for each signal. This score is stored as rule_score and serves as a fallback when ML inference is unavailable or disabled. It combines five inputs:
Wallet alpha score
The 0–100 wallet score from Phase 1 at the time the signal was emitted. The single strongest component.
Token lifecycle state
The numeric lifecycle state from
TokenLifecycle. launch and early_accumulation boost the score; distribution and decline suppress it.