The ingestion layer is Alpha Leak’s entry point for all on-chain data. A persistent WebSocket connection to the Solana network subscribes to the Pump.fun program account, decodes every log into one of three typed event shapes, and fans each event out to the relevant downstream services — all without a message queue or intermediate store between receipt and processing.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.
WebSocket subscription
Chainstack RPC pool with automatic failover and per-key rate limits.
Event processing
EventProcessor fan-out routing for trade, create, and complete events.
Velocity tracking
Rolling Redis counters for 60s and 300s buy velocity per token.
WebSocket subscription
TheWsSubscriber connects to a pool of Chainstack RPC endpoints and subscribes to the Pump.fun program at address 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P. Each key in the pool carries its own rate limit budget, and connections are automatically rotated when a key is exhausted or an endpoint becomes unhealthy.
| Parameter | Value |
|---|---|
| Program address | 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P |
| Rate limit per key | 3,000,000 RU / key |
| Max requests per second per key | 25 RPS |
| Failover behaviour | Automatic rotation to next healthy endpoint |
| Proxy support | Per-key geographic proxy layering |
Event types
| Event type | Trigger | Key fields |
|---|---|---|
trade | Any buy or sell on a bonding curve | mint, wallet, solAmount, tokenAmount, isBuy, virtual reserves |
create | A new token is launched | mint, name, symbol, uri, bondingCurve, creator |
complete | A token graduates to Raydium or PumpSwap | mint, bondingCurve |
If the
pending backpressure counter exceeds 10, the subscriber logs a backlog warning and records the event in pipeline_stats. The metrics interval reports the current pending count every 30 seconds, making sustained throughput pressure easy to observe.Event processing
TheEventProcessor is the fan-out hub. Every decoded event passes through it, and it dispatches to the relevant services based on event type. There is no queue between the subscriber and the processor — dispatch happens inline.
- On create
- On trade
- On complete
When a new token is launched, three services are notified:
CurveManager initialises curve state
An in-memory bonding curve state object is created for the new mint address, ready to accept trade updates.
TradeWriter persists the token record
The token metadata (
name, symbol, uri, creator, bondingCurve) is written to PostgreSQL immediately.CurveManager
TheCurveManager maintains a real-time in-memory state object for every active bonding curve token, keyed by mint address. This state is the authoritative source of truth for bonding curve prices during the pre-graduation phase — no database query is needed.
Each state object tracks the following fields:
| Field | Description |
|---|---|
| Real SOL reserves | Actual SOL held in the bonding curve |
| Virtual SOL reserves | Virtual reserve used for price calculation |
| Real token reserves | Actual tokens remaining in the curve |
| Virtual token reserves | Virtual reserve used for price calculation |
| Buy / sell counts | Running totals of buy and sell transactions |
| Unique buyer count | Number of distinct buyer wallets |
| Total SOL volume | Cumulative SOL traded |
| First buy wallet | Wallet address of the earliest buyer |
| First buy timestamp | Block time of the first buy |
| Graduation status | Whether the token has crossed the 85 SOL threshold |
Curve state is mirrored into Redis at
token:<mint> so the live trader’s exit monitor can read real-time prices without a database round-trip. The exit monitor polls every 3 seconds, so this mirror must stay current.CurveManager emits a graduation event, which triggers wallet discovery and, optionally, Birdeye token promotion.
Trade batching
TheTradeWriter accumulates trades in an in-memory buffer rather than writing each one individually. The buffer is flushed to PostgreSQL when either condition is met:
- The buffer reaches 200 events, or
- 1 second has elapsed since the last flush
Backpressure handling
TheWsSubscriber tracks a pending counter representing the number of events that have been received from the WebSocket but not yet fully processed by EventProcessor. If this counter exceeds 10, a backlog warning is logged and the event is recorded in pipeline_stats.
The metrics reporting interval fires every 30 seconds and includes the current pending value, making it straightforward to identify whether the pipeline is keeping up with on-chain event volume or whether the processing chain has a bottleneck.
Velocity tracking
TheVelocityTracker maintains rolling counters in Redis, updated on every trade event. These counters are attached to every signal payload and are among the most important features in both the rule-based signal scorer and the ML models.
| Redis key | Description |
|---|---|
buysLast60s | Number of distinct buy transactions in the last 60 seconds |
buysLast300s | Number of distinct buy transactions in the last 300 seconds |
solLast60s | SOL volume bought in the last 60 seconds |
buysLast60s combined with a rising solLast60s is frequently the first observable signal that a token is gaining momentum. The TokenLifecycle classifier in Phase 2 uses these same counters to assign lifecycle states such as momentum and euphoria.
Phase 1: Wallet scoring
See how trade data feeds into feature computation and the 7-component alpha score.
Architecture overview
Full pipeline map from WebSocket ingestion to live on-chain execution.