AlphaFeed

What users see

A subscriber connects on Telegram, picks a noise level, and starts receiving alerts the second a sharp move shows up. Every alert is scored, contextualised in plain language, and includes the data the score was built from. Subscribers can act on them manually — or not act at all. The auto-trader behind the same pipeline is a separate, internal experiment.

Architecture

┌─────────────────────┐    ┌──────────────┐    ┌──────────────────┐
│ on-chain ingestion  │ →  │ scoring +    │ →  │ telegram alert   │
│ (mempool + DEX +    │    │ enrichment   │    │ (subscribers)    │
│  CEX feeds)         │    │ (model + LM) │    └──────────────────┘
└─────────────────────┘    └──────┬───────┘             │
                                  │                     │ (high-conviction
                                  ▼                     │  subset only)
                           ┌──────────────┐             ▼
                           │ trade-event  │     ┌──────────────────┐
                           │ table        │     │ paper-trader     │
                           └──────────────┘     │ → live-trader    │
                                                │ (gated)          │
                                                └──────────────────┘

Every alert passes through scoring before it ever reaches a subscriber. A subset of alerts that clear a conservative score gate and a minimum liquidity floor get forwarded to the trader pipeline. Both stages are deliberately strict — most signals never become trades.

The auto-trader, in two stages

The most operationally interesting part of the system is the trader, because real money is involved and the cost of being wrong compounds. Two stages:

1. Paper-trader. Mirrors every qualifying signal at a fixed notional, marks to live mid-prices, and records the would-be P&L over the lifecycle of each position. Runs continuously, costs nothing.
2. Live-trader. Only unlocked once the paper window has accumulated enough closed positions to be statistically meaningful AND the cohort actually shows positive expectancy at the chosen TP/SL multiples. Until then, the live side stays in shadow mode — code paths exercised, capital not deployed.

TP and SL multiples sit deliberately wider than typical retail bots — the goal is to capture asymmetric outcomes, not to scalp. Position sizing is constant per trade; no Martingale, no scaling-in.

The gate-tightening case study

Mid-experiment I tightened the score and liquidity gates by a meaningful amount. Trade volume across a five-day window dropped roughly 35% — fewer signals made the cut — but the effect on quality was sharp:

• Win rate roughly tripled.
• Cumulative P&L flipped from negative to clearly positive.
• The trailing-stop exit became the workhorse: most of the wins came from riding winners, not catching turnarounds.

The takeaway wasn't "tightening always helps" — it was that the original gate had let through too many low-conviction signals that ate the edge. The right answer for an experiment is to keep moving the gate until you can see what's actually load- bearing, not to lock in a single guess up front.

Operational discipline

A real-money trader running unattended needs more than a working strategy; it needs to fail safely. Some of what's wired in:

• Kill-switch on losing streaks. A configurable consecutive-loss counter flips trading to halted state automatically. The counter is derived from the canonical positions table on every check, not an incremented cache, so it can't drift through restarts or bugs.
• Approval-mode warmup. The first N intentions after any restart go through a manual /yes / /no approval prompt before a live order is placed. Catches "the model decided something weird" before it's expensive.
• Idempotent state. Position resolution, P&L computation, key expiration — all derived from canonical tables on demand, never from cached counters. Restart safety is a property, not a hope.
• Daily heartbeat. One Telegram message a day to the operator with pipeline health: alerts sent, unprocessed events, last ingest, last score. If anything is stale, it shows up in the morning, not after a week of silent failure.

Stack

• Backend: Python 3.11, FastAPI, SQLite (WAL mode), Docker Compose
• Workers: separate containers for ingestion, scoring, alerting, execution, monitoring, bot — each independently restartable
• Delivery: Telegram bot (paid + free tiers); on-chain payment verification before alerts unlock
• Hosting: single VPS, nginx in front, automated cert renewal
• Tests: ~150 tests covering the safety-critical paths (gating, kill-switch, idempotency, key validation, intention lifecycle)

What's next

Live-trader unlock is gated on the paper window accumulating enough closed positions with positive expectancy. The current focus is iterating on the gating thresholds and growing the score model with more sources, not on rushing the live side. The auto-trader exists to validate that the underlying signal has real edge — if it does, capital follows; if it doesn't, the user-facing product still has value as curated alerts, and the live side stays off.