How it works

Pulse is a loop and a stream writing to one archive. This page states every rule and threshold the code actually uses, so you can predict what a token's status or a wallet's score will be and change the rule if you disagree.

The two inputs#

Everything in the archive arrives by one of two paths.

• The collection cycle runs every SNAPSHOT_EVERY_MIN minutes (default 5). It reads discovery lists and prices from Jupiter, DexScreener and GeckoTerminal, plus pump.fun's own feed, and reads Robinhood Chain launchpad factory logs over JSON-RPC. It writes one snapshot per token seen, updates each token's latest state, writes chain-wide totals, then runs lifecycle status and classification.
• The firehose is a WebSocket log subscription on Solana RPC. It decodes every pump.fun bonding-curve trade, PumpSwap trade, token creation, graduation and pool creation as it happens. It writes launches and graduations immediately, keeps rolling per-token trade heat in memory, and persists a selective subset of trades.

One process runs both, plus the API, the dashboard and the scheduled jobs. See the diagram on the home page.

A collection cycle, step by step#

1. Refresh native prices (SOL and ETH in USD).
2. Fetch observations: Jupiter lists (recent and the toptrending, toptraded and toporganicscore categories over 5m, 1h, 6h and 24h), DexScreener boosts, latest boosts, profiles and takeovers, GeckoTerminal trending and new pools, pump.fun lists, and Robinhood Chain tokens.
3. Merge observations of the same token. Several providers describing one token in a cycle become one snapshot, later providers filling gaps, with the source names joined by +.
4. Upsert tokens, write token_snapshots, list_appearances and pairs, and track each token's all-time high market cap.
5. Write market_snapshots per chain.
6. Recompute lifecycle status.
7. Classify tokens that are new or changed.
8. Run due jobs: wallet label import, wallet scoring, the newsletter.

A source that fails is logged and skipped. The rest of the cycle still completes, and the failure count is stored in collector:last-cycle.

Token lifecycle#

Every token has a status: new, running, graduated, dying or dead. Status is recomputed in SQL each cycle with these exact rules. When more than one rule matches, the higher row wins.

• Precedence is dead, then dying, then running, then graduated.
• dead is terminal. A token never leaves it.
• Tokens with no market cap yet are skipped, not marked.
• Every change is a transition. When a token becomes running, the firehose flushes its early buyers (see below).
• The thresholds live in src/intel/status.ts, and the API returns them as rules in /api/overview.

Tech versus meme classification#

Pulse is built for a reader who cares about technology more than memes, so every token gets a category and a tech_score between 0 and 1. It is a transparent keyword and signal scorer, not a model, so a result can always be explained.

Scoring#

1. Start at 0.4.
2. Add 0.2 for each technology category the token's name, symbol and description match, capped at three matches. The vocabulary has 13 technology categories.
3. Subtract 0.2 for each meme category matched, capped at three. The meme categories are meme, animal, culture, politics and celebrity.
4. Add signals of substance: +0.15 for a website, +0.1 for a description over 120 characters (+0.05 more over 300), +0.1 if the token is verified, +0.15 for documentation-style words, +0.05 for a verified, strict, liquid-staking or community tag.
5. Clamp to the range 0 to 1.

Category#

If the score is at least 0.5 the category is the best-matching technology category. Otherwise it is the best-matching meme category. With no match at all, the category is tools when the score is at least 0.6, else unclassified. Filtering with tech=1 in the API means score at least 0.6 and a category outside the meme set (and not unclassified).

Tokens are classified when they have never been classified, or when they were seen more than six hours after their last classification, up to 2000 per cycle. Classification looks only at text the token published about itself, which can be wrong or deceptive. It is a first filter for human judgement, not a verdict.

Wallet scoring#

Pulse imports public KOL and smart-money wallet labels once a day. It scores wallets hourly from the positions it has recorded for them over a rolling 30 days. Scoring is Solana only, with profit measured in SOL.

The Pulse score combines them:

score = win_rate * 40
      + 15 * log10(1 + max(pnl, 0))
      + min(early_hits, 10) * 5
      + min(tokens_traded, 20)

where pnl is realized plus unrealized profit in SOL. Win rate is worth up to 40 points, profit has diminishing returns through the logarithm, early hits are worth 5 each up to 10, and breadth of at least 20 tokens adds up to 20. Scores are stored in wallet_scores with the win rate, early hits, best multiple and USD profit.

Promotion to smart money#

A wallet that has at least 3 early hits and a win rate of at least 50% is inserted into wallets as kind smart with source pulse:discovered, whether or not it appeared on any public list. The set of smart wallets therefore grows from evidence in your own archive.

Trade persistence#

The firehose sees every pump.fun and PumpSwap trade, but storing all of them would bury the signal. Pulse keeps the trades that carry information, tagged with a reason:

• Early buyers are tracked for up to 6000 recent mints. Tokens that never graduate or run are forgotten, which is what keeps the archive small.
• Everything else only feeds the rolling heat: 12 buckets of 5 minutes per token, exposed as heat in the token API and as hot in the overview. Heat is not stored.
• Writes are batched every 5 seconds, and wallet_positions are updated in the same flush.
• If the stream goes quiet for 45 seconds, a watchdog reconnects. The public Solana endpoint drops connections often, so a dedicated SOLANA_WS_URLS endpoint is worth setting.

Robinhood Chain#

Robinhood Chain (chain id 4663, an Arbitrum Orbit chain) is read over JSON-RPC. Pulse walks the factory logs of its launchpads (pons, noxa, odyssey) from a saved block cursor, records launch events, and refreshes market data for the tokens it has found. The same lifecycle and classification rules apply. There is no firehose or wallet scoring on this chain yet.

Dashboard and API#

The dashboard is a static single-page app served by the same process. Every view is backed by the public JSON API, so anything you see you can also fetch, and the MCP server exposes the same data to agents.