Fomo Agent

FOMO Robinhood Radar

Reads the SQLite database the pipeline builds and runs its CLI. Everything below is research output about public on-chain activity: what other wallets have already done, and how well they have done it.

When to trigger

• "покажи топ-трейдеров" / "who are the good traders"
• "кого добавили в active" / "who dropped and why"
• "что покупают прямо сейчас" / "what is the cohort buying"
• "разбери токен X" / "analyze this token" / "who holds this"
• "разбери трейдера X" / "what is this trader doing"
• "проскорь кошельки" / "пересчитай баллы" / "score the pending wallets"
• "что сломалось" / "is the pipeline healthy"

Where the data lives

Two databases, and picking the wrong one is the most common mistake:

Anything that answers a question about current traders or tokens must run on the server:

ssh -i ~/.ssh/fomoradar root@<server> 'cd /opt/fomoradar/app && /opt/fomoradar/venv/bin/python -m fomo_agent.cli <command>'

The same data is already published, so prefer reading it over re-deriving it: the site at https://fomoradar.app (/, /fresh, /leaderboard, /search, /trader/<who>, /token/<mint>), the API at /api/* (leaderboard, signals, fresh, tape, activity, stats, distribution, search, token/{mint}, token/{mint}/chart, trader/{who}, health), and the bot @fomoradarRH_bot (/status, /health, /signals, /fresh, /token, /trader, /subscribe).

Commands

Run from the repo root with the venv python (.venv/Scripts/python on Windows).

Direct SQL is fine (tables: traders, tokens, trades, holdings, fomo_users, fomo_swaps, fomo_positions, score_history, bot_subscribers, bot_sent, runs). Schema version lives in PRAGMA user_version.

There is no cli fresh — the fresh-launch feed is a site route and a bot command, and its data comes from /api/fresh.

Scoring in chat

The pipeline's most-used job, because ANTHROPIC_API_KEY is deliberately not on the server. The export carries the same context and the same instructions the API path would send.

cli score --export pending.json              # every wallet due for a verdict
cli score --export pending.json --unscored   # only wallets that have never been scored
cli score --export pending.json --force      # the whole roster, schedule ignored
cli score --import scored.json --model-label 'claude-opus-5 (in-chat)'

--export selects by the rescore schedule, not by "everything": active after 24h, watch after 72h, dropped after 14 days, anything untracked immediately. So an empty export means the roster is current, not that something failed.

The loop that works at scale

A context is about 2 KB, so a 300-wallet export runs to two thirds of a megabyte — too much to read whole. Do this instead:

1. Digest it. Write a throwaway script that prints one line per wallet: address, handle, fomo PnL at 24h/7d/30d, trade count, volume, the 30-day on-chain aggregates (trades, unique tokens, bought, sold, median hold, early buys) and the open book as SYM:pnl/cost×multiple. One line per wallet is enough to judge; the full contexts stay in the file for the ones that need a closer look.
2. Score in batches of ~60, writing each to its own batchN.json.
3. Validate before sending. Merge the batches and check: every exported address covered exactly once, no extras, score inside its status band, style and red_flags from the allowed vocabulary, confidence in [0,1]. A silent mismatch here is worse than a wrong score — it looks like a successful import.
4. Import, then confirm the queue drained with another --export.

Output format

A JSON array, or {"results": [...]}. One object per wallet — docs/example_scores.json is the reference:

{
  "address": "0x0a6ebed0155edb4b21d92ad02897a626cd90119e",
  "score": 96,
  "status": "active",
  "style": ["swing", "holder", "sniper"],
  "red_flags": [],
  "summary": "19.5M 30d PnL is the largest on the board and it is not one lucky ticket: PONS at 115x on a 68k basis, USELESS at 5x on 830k, MarsCoin at 3x on 965k. 3239 fills across 290 tokens with 88 early entries means the entries are systematic.",
  "confidence": 0.95
}

• status must agree with score: ≥70 active, 40–69 watch, <40 dropped.
• style ⊆ sniper, swing, scalper, holder, copy-follower.
• red_flags ⊆ bot, bundler, insider-like, wash, one-hit.
• summary is 2–3 sentences that cite the specific numbers behind the verdict. "Strong trader with good PnL" is useless; it appears verbatim on the public trader page and in /api/leaderboard.
• Unknown addresses and invalid objects are counted and skipped, never guessed at.

How to weigh the evidence

fomo's PnL is the primary signal, and it includes open positions. A wallet showing millions on a few thousand of on-chain outlay is not a glitch — the position ran and was never sold. Negative on-chain cash flow is what accumulating looks like, not what losing looks like.

The cost basis is what separates skill from a ticket. A 780x on a 2k entry and a 2.1x on a 3.7M entry can show the same PnL; only the second is evidence that someone can deploy size. Prefer several independent winners over one, and a real basis over a large multiple on dust.

Read the losses too. The open book shows them, and they are the half that used to be invisible: 48 early entries mean nothing if the same book has one position written off entirely and another down two thirds. Score the net, not the highlight.

Flags are for unambiguous shapes only — a 6-minute median hold across 282 tokens in dust size is a bot; 46M of volume against a 54k book is wash; one unresolvable bag explaining the whole number is one-hit. Few trades means low confidence, not a low score.