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.

The ingestion layer is the system’s entry point to the chain. Every trade, token creation, and graduation event is decoded into a strongly-typed struct the moment it lands — nothing is polled, nothing is batched at the network level. The EventProcessor then fans each event out simultaneously to every downstream service that needs it, so no single service can delay another. This zero-wait dispatch model is what keeps signal latency low even when dozens of events arrive per second.

Event types

Every piece of activity on Pump.fun produces one of three event types. The pipeline processes all three:
Event typeTriggerKey fields
tradeAny buy or sell on a bonding curvemint, wallet, solAmount, tokenAmount, isBuy, virtual reserves
createA new token is launchedmint, name, symbol, uri, bondingCurve, creator
completeA token graduates to Raydiummint, bondingCurve

Event routing

The EventProcessor is the fan-out hub. Every decoded event is dispatched simultaneously to the services that need it — nothing waits for anything else.
When a create event arrives, three services are notified in parallel:
  • CurveManager initialises the in-memory bonding curve state for the new token, ready to receive trade updates immediately.
  • TradeWriter persists the token record to the database so it is available for historical queries.
  • GenesisWatcher opens a 60-second observation window for the token, tracking its earliest buyer behaviour.

CurveManager

The CurveManager maintains a live state object for every active token, updated with each incoming trade. This in-memory state is the source of truth for real-time price and market data — reading it never requires a database query. Each state object tracks:

Reserve data

Real and virtual SOL and token reserves, updated on every trade. Used to compute the current price at any moment.

Activity counters

Total buy and sell counts, unique buyer count, and cumulative SOL volume since launch.

Timeline

First buyer wallet and timestamp. Graduation status and the timestamp at which graduation occurred.

Cache mirror

State is mirrored to the cache layer in real time so the live trader’s exit monitor can read current prices for open positions without touching the database.
When a token crosses 85 SOL in reserves, CurveManager emits a graduation event. This triggers wallet discovery and promotion to enhanced price tracking automatically.

Trade batching

Rather than writing each trade to the database individually, TradeWriter accumulates events in memory and flushes them in batches:
Batch size:  200 trades
Max latency: 1 second between flushes
This design keeps write throughput high during burst periods — when a viral token generates dozens of trades per second — without adding measurable latency from the signal pipeline’s perspective. The signal path reads from the in-memory CurveManager state, not from the database, so batching has no effect on signal speed.

Velocity tracking

VelocityTracker maintains rolling buy counts updated on every trade event. These values are attached to every signal payload and are key features in both the ML models and the rule-based scorer.
MetricWindowDescription
buysLast60s60 secondsNumber of distinct buys in the last 60 seconds
buysLast300s300 secondsNumber of distinct buys in the last 5 minutes
solLast60s60 secondsSOL volume bought in the last 60 seconds
A spike in buysLast60s is typically the first observable indicator that a token is gaining momentum. The ML model uses velocity as one of its highest-weight features when predicting short-term price moves.

Build docs developers (and LLMs) love