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 is structured as a single Node.js process running 30+ concurrent background services, coordinated through PostgreSQL and Redis. There is no message queue between ingestion and processing — events are handled inline, which keeps latency minimal and eliminates the operational complexity of a separate queue tier. The system is divided into four named phases. Each phase builds on the data produced by the one before it.

​
Pipeline overview

The diagram below shows every service in the system and how data flows through them, from raw WebSocket events to live on-chain execution. 
Solana Mainnet (WebSocket)
        │
        ▼
┌───────────────────┐
│   WsSubscriber    │  Subscribes to the Pump.fun program account.
│  (stream-consumer)│  Decodes raw log data into typed events.
└────────┬──────────┘
         │  PumpfunEvent (trade | create | complete)
         ▼
┌───────────────────┐
│  EventProcessor   │  Fan-out: routes each event to CurveManager,
│                   │  TradeWriter, VelocityTracker, SignalEmitter,
│                   │  CandleAggregator, GenesisWatcher.
└────────┬──────────┘
         │
         ├──────────────────────────────────────────────────┐
         │                                                  │
         ▼                                                  ▼
┌─────────────────────┐                        ┌─────────────────────┐
│   CORE SERVICES     │                        │   GENESIS WATCHER   │
│                     │                        │                     │
│  CurveManager       │                        │  60s observation    │
│  TradeWriter        │                        │  75-feature vector  │
│  VelocityTracker    │                        │  ONNX inference     │
│  CandleAggregator   │                        │  genesis_signal →   │
│  WalletDiscovery    │                        │  Redis PubSub       │
│  WalletEnrichment   │                        └─────────────────────┘
│  OutcomeTracker     │
│  CreatorTracker     │
│  BotDetector        │
│  RiskScorer         │
│  DataArchiver       │
│  MaintenanceService │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────────┐
│   PHASE 1 — SCORING     │
│                         │
│  PeakTracker            │  Tracks 1h/4h/24h price peaks per signal.
│  PnlCalculator          │  Realised PnL, win rate, hold times.
│  FeatureComputer        │  30-min feature roll-up per active wallet.
│  WalletScorer           │  7-component alpha score (0–100).
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│  PHASE 2 — INTELLIGENCE │
│                         │
│  SignalScorer           │  Composite signal quality score.
│  TokenLifecycle         │  8-state lifecycle classifier (60s cadence).
│  BundleDetector         │  5s time-bucket cluster detection.
│  CreatorRiskScorer      │  Rug rate, insider pct, serial detection.
│  CoOccurrence           │  Wallet pair co-buy frequency graph.
│  GraphBuilder           │  Python graph analysis (hourly).
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────────────────┐
│  PHASE 3 — ML & ADVANCED INTEL      │
│                                     │
│  MlInference         (5s cadence)   │  68-feature ONNX scoring.
│  AntiSignalEmitter   (30s cadence)  │  Multi-trigger rug/fraud detection.
│  DeepDiveWorker                     │  Enriched wallet analysis.
│  CopyTradeDetector   (15m cadence)  │  3-type copy-trade classification.
│  OperatorDetector                   │  Coordinated operator identification.
│  AlphaDecayTracker   (60m cadence)  │  Per-wallet signal decay curves.
│  SignalCrowdingDetector (60s)       │  Crowding ratio → score penalty.
│  MarketRegimeDetector (10m)         │  4-state regime classification.
│  ModelMonitor                       │  Live model drift detection.
└─────────┬───────────────────────────┘
          │
          │  trade:signals  (Redis PubSub)
          ▼
┌─────────────────────────┐
│     LIVE TRADER         │
│                         │
│  InlineScorer           │  ONNX inference inline (no DB round-trip).
│  PortfolioManager       │  Phase-gated positions + circuit breakers.
│  TradeExecutor          │  Pump.fun bonding curve + Jito bundles.
│  ExitMonitor            │  3s poll: TP / SL / timeout / anti-signal.
└─────────────────────────┘

​
Data stores

Each store has a distinct role. The system does not use a general-purpose cache layer — every store is chosen specifically for the access pattern it serves.
StoreRole
PostgreSQLPrimary store for all trades, signals, wallet profiles, ML scores, detected bundles, copy-trade pairs, regime snapshots, and live trade history. Trades table is monthly-partitioned for query performance.
RedisPub/Sub channel (trade:signals) for signal fan-out to the live trader; key-value cache for wallet stats (wcache:), crowding ratios (crowding:), market regime (market:regime), and bonding curve state (token:<mint>). Also maintains the tracked_wallets and known_bots sets.
GCSLong-term archive of raw trade data older than 60 days.
ONNX model filesLoaded from disk at startup and hot-reloaded every 5 minutes if updated. Stored alongside _metadata.json files describing features, calibration parameters, and PR-AUC.

​
Concurrency model

Every background service follows the same pattern: a setInterval loop that checks a running flag before each execution, skipping the cycle if the previous run hasn’t finished. This prevents overlapping database queries under load without requiring a separate job queue. Memory usage is monitored and logged after every run.
The WebSocket subscriber maintains a backlog counter. If pending events exceed 10, a warning is emitted and the metrics interval logs it. This acts as a natural pressure valve for burst periods.

​
Inter-service communication

Services communicate in two ways: through shared database state, and through a real-time Redis Pub/Sub channel.
Most intelligence services read each other’s output from PostgreSQL. For example, MlInference reads WalletScorer alpha scores, and AntiSignalEmitter reads BundleDetector results. This keeps services decoupled — each service owns its writes and reads only the columns it needs.
The InlineScorer inside the live trader runs ONNX inference directly in the subscription callback — there is no database round-trip between receiving a signal and computing the final execution score.

Build docs developers (and LLMs) love

Get started for freeTalk to us