tripolskypetr/jan_2026_financial_advice

Crypto Trading Signals, Risk Screening & OHLCV Candles (Jan 2026)

This dataset is a worked example of a pump-and-dump

The headline is +52.2% over 22 trades. Almost all of it is two low-cap pumps.

• —52% ≈ PUMP (+22.58) + FARTCOIN (+38.33) — ~61 п.п. on three trades. Everything else is in the red.
• —Sharpe 0.30, a real mark-to-market drawdown of ~21%, Recovery Factor 2.75 — on 22 trades over 27 days this is not statistics, it is the description of one lucky episode.
• —On the liquid instruments the expectation is negative: SOL profit factor 0.34, TRX 0.48, POL 0.75. These are the names a subscriber can actually trade at size — and they lose money.

Strip the two low-capitalization pumps (PUMP + FARTCOIN, three trades, +60.9 п.п.) and the remaining 19 trades net ≈ −8.7 п.п. The money is made by piggybacking pumps on thin-liquidity, low-cap assets; the liquid calls are a loss-making tail around them. That is the literal shape of a pump-and-dump.

The companion article explains why such a thing can carry positive expectation at all — paid subscribers are external capital inflow, which turns a fixed-sum game into a "growing-sum game" — and this dataset is the concrete instance behind it: *Escaping zero expectation — from a fixed-sum game to a growing-sum game*.

Numbers above are computed directly from the bundled symbol_heatmap / closed_signals files and are reproducible from the raw data below. This is an analytical characterization of the dataset's economics, not financial advice and not a legal claim about any specific person or channel.

Source tool: backtest-kit · Signals: January 2026, crypto_yoda_channel Telegram · Candles: 2025-11-26 → 2026-04-27 · Quote: USDT

This is a raw export from a backtest-kit pipeline capturing the full lifecycle of a discretionary crypto-signal strategy: the raw Telegram calls, a rule-based risk screen, the OHLCV history, a bar-by-bar backtest of the followed calls, and the per-trade and portfolio results. Everything needed to reproduce the analysis above is included.

The per-symbol breakdown (where the +52.2% comes from)

Portfolio: 22 trades, total +52.22, Sharpe 0.302, std dev 7.86, recovery factor 2.75. Two symbols (PUMP, FARTCOIN) on three trades produce more than the entire book; the three highest-volume names a subscriber would actually trade (SOL, TRX, POL) all have profit factor below 1 and negative expectancy.

How the article explains it

The companion article's thesis is about expectation, and these are its literal claims (quoted):

• —A long-lived edge decays to zero. In "a game with a finite sum the capital on the market is constant and only migrates between participants: your earnings are someone's losses" — so once an edge is known, expectation collapses to zero minus fees.
• —The escape is outside capital. "The guarantee of a growing-sum game is a direct recommendation to the public, if its size tends to infinity." Subscribers acting on a call are fresh inflow, not redistribution — so the value of a call is not whether it is correct but whether real inflow sits under it.
• —Following every call raw is not the edge. The channel's calls are "successful in 68% of cases", but with average trade +2.37% against std dev ±7.86% and Sharpe 0.3, "risk management does not insure against the black swan scenario at all" — one or two big losses eat the profit of ten small wins while the winrate still looks pretty. This Sharpe 0.3 is exactly the `portfolioSharpeRatio` 0.302 in this dataset.
• —The edge is a momentum filter. Reading the 24h before publication and rejecting calls with no inflow behind them, "Sharpe Ratio grew 2.67x (0.302 → 0.807)" and "the average trade became almost 3x more profitable."

So the pump-and-dump and the article are the same story from two ends: the article shows the mechanism (subscriber inflow makes low-cap pumps payable), and this dataset shows the footprint (the entire return concentrated in two low-cap pumps, liquid names negative).

The mechanism, step by step

Step 1 — the raw calls (parser_items)

Telegram posts parsed by regex into structured orders: symbol (e.g. #BTC/USDT), direction (LONG/SHORT in Russian text), entry zone, targets ladder, stoploss.

Step 2 — the risk screen and its two rules (screen_items)

Before a call is followed, the engine reads the 24h of 1-minute candles before publication (PRE_CANDLES_LIMIT = 1440) and computes:

• —`avgRangePct` — average per-candle range; a liquidity proxy (is the asset awake or sleeping).
• —`momentum24hPct` — total price change over the prior 24h (positive = a pump already underway, negative = falling).

It applies the two rules from the article, present verbatim in each row's riskReasoning:

Calls tripping neither rule are followed. In this export: 20 follow / 12 skip out of 32; of the 12 skips, 9 fire rule 1 (stop-hunt) and 3 are momentum-driven. Each row also carries riskConfidence, riskSureLevel, and Russian riskDescription / riskReasoning rule traces.

Step 3 — the backtest of the followed calls (*_report, position_log)

The 20 followed calls are replayed bar-by-bar against candle_items, each opened at notional cost = 100 and tracked until take-profit, stop-loss, or time expiry. This produces the per-minute action stream, per-trade outcomes, partial/break-even snapshots, running peak-profit and max-drawdown series, engine timing, and the position active event log.

Step 4 — the bottom line (closed_signals, symbol_heatmap)

Each followed call collapses to one resolved trade in closed_signals (22), and the whole book rolls up into symbol_heatmap — the per-symbol table above, whose portfolio Sharpe is 0.302 (the article's unfiltered baseline).

Configurations

Thirteen HuggingFace configs. Default is screen_items. The three input collections and the two analysis files are single JSON-array / JSON-object files; the eight execution-result collections are line-delimited JSONL. Each config loads as one split.

from datasets import load_dataset

# Inputs
screen  = load_dataset("<repo>", "screen_items",  split="screen")    # risk-screened signals (default)
parser  = load_dataset("<repo>", "parser_items",  split="parser")    # raw parsed signals
candles = load_dataset("<repo>", "candle_items",  split="candles")   # OHLCV (~929k rows)

# Backtest of the followed calls
heat    = load_dataset("<repo>", "heat_report",     split="heat")        # per-trade outcomes
bt      = load_dataset("<repo>", "backtest_report", split="backtest")    # per-minute action stream
# also: breakeven_report, partial_report, highest_profit_report,
#       max_drawdown_report, performance_report, position_log

# Bottom line
signals = load_dataset("<repo>", "closed_signals", split="signals")  # 22 resolved trades
heatmap = load_dataset("<repo>", "symbol_heatmap", split="heatmap")  # per-symbol + portfolio stats

Format. Inputs are top-level JSON arrays; the eight result files are JSONL; closed_signals is a JSON array and symbol_heatmap is a single JSON object. The json builder loads them all. Input files use MongoDB Extended JSON ({"$oid": ...}, {"$date": ...}); result / analysis files use plain Unix-ms timestamp and plain signalId / id strings.

Schemas

parser_items — raw parsed signals

{
  "_id": { "$oid": "6a19c607f20d896ad6188c21" },
  "channel": "crypto_yoda_channel", "messageId": 4998,
  "symbol": "SOLUSDT", "direction": "long",
  "entry": { "from": 134.7, "to": 136.2 },
  "targets": [137.3, 137.9, 139.1, 140.4, 142.5], "stoploss": 130.3,
  "note": "СИГНАЛ #SOL/USDT ...",
  "publishedAt": { "$date": "2026-01-05T07:12:10.000Z" }, "visited": true
}

Symbols seen: BTCUSDT, ENAUSDT, ETHUSDT, FARTCOINUSDT, HYPEUSDT, NEARUSDT, POLUSDT, PUMPUSDT, SOLUSDT, TRXUSDT.

screen_items — risk-screened signals (default config)

The same calls after the two-rule screen of Step 2.

{
  "_id": { "$oid": "6a1b23cff20d896ad61d54b8" },
  "parserItemId": "6a19c607f20d896ad6188c21",
  "symbol": "SOLUSDT", "direction": "long",
  "entryFrom": 134.7, "entryTo": 136.2,
  "targets": [137.3, 137.9, 139.1, 140.4, 142.5], "stoploss": 130.3,
  "riskAction": "follow", "riskConfidence": "reliable", "riskSureLevel": "medium",
  "riskDescription": "Action follow. LONG без срабатывания правил (momentum24hPct 1.06% > -1%) ...",
  "riskReasoning": "Шаг 1: avgRangePct=0.0862%, momentum24hPct=1.06% ...",
  "publishedAt": { "$date": "2026-01-05T07:12:10.000Z" }
}

Labels (32 rows): riskAction → follow 20 / skip 12 (skips: ~9 stop-hunt, 3 momentum) · riskSureLevel → low 11 / lowmedium 11 / medium 7 / mediumhigh 3 · direction → long 16 / short 16.

candle_items — multi-timeframe OHLCV

928 886 bars from ccxt-exchange — what the screen reads and the backtest replays.

{
  "_id": { "$oid": "6a0d87f2b70c3074780f8b22" }, "exchangeName": "ccxt-exchange",
  "symbol": "BTCUSDT", "interval": "1m", "timestamp": 1775001600000,
  "open": 68284.49, "high": 68284.49, "low": 68218.35, "close": 68218.35, "volume": 14.7537
}

Rows by interval: 1m 921 050 · 15m 4 512 · 1h 1 920 · 30m 1 248 · 4h 156. The 1m series feeds PRE_CANDLES_LIMIT = 1440 (24h) for avgRangePct / momentum24hPct. Symbols (14): BTCUSDT, DOGEUSDT, ETHUSDT, FARTCOINUSDT, HBARUSDT, HYPEUSDT, NEARUSDT, PENGUUSDT, POLUSDT, PUMPUSDT, SOLUSDT, TRXUSDT, XAUTUSDT, ZECUSDT. Time range: 2025-11-26T08:00:00Z → 2026-04-27T16:31:00Z.

Backtest reports — common shape

Every *_report line has a reportName, a nested data payload, and routing fields hoisted to the top level (symbol, strategyName=jan_2026_strategy, frameName=jan_2026_frame, exchangeName=ccxt-exchange, timestamp, and where applicable signalId). Shared data fields: timestamp (Unix ms), symbol, signalId (→ parser_items._id.$oid), backtest (true), position, priceOpen, priceTakeProfit/priceStopLoss, cost (100), and the peakProfit* / maxDrawdown* excursion fields.

• —`heat_report` (22) — one row per closed trade: realized pnl/pnlCost, closeReason (take_profit/stop_loss/time_expired), openTime/closeTime, excursions, totalPartials. Outcomes: TP 14 / SL 7 / time-expired 1; wins 15 / losses 7.
• —`backtest_report` (506 534) — per-minute ticks; action ∈ idle (506 425) / active (65) / opened (22) / closed (22), with currentPrice.
• —`breakeven_report` (17) — snapshot at first break-even (full open-state fields).
• —`partial_report` (248) — partial fills; action ∈ profit (138) / loss (110), level 10–90.
• —`highest_profit_report` (1 473) / `max_drawdown_report` (1 889) — running peak-profit and worst-drawdown snapshots while open (same schema).
• —`performance_report` (506 482) — engine timing; metricType ∈ backtest_timeframe (506 447) / backtest_signal (22) / backtest_total (13), with duration ms.
• —`position_log` (73 874) — event log; every entry is a position active heartbeat with args[0] = { symbol, signalId, priceOpen, takeProfit, stopLoss, currentPrice, peakProfitDistance, peakMaxDrawdown, currentPnl }, plus id, type, timestamp/createdAt, methodContext, executionContext, topic.

closed_signals — followed calls as resolved trades

The 22 followed calls, each one fully-resolved trade. id = parser_items._id.$oid.

{
  "id": "6a19c607f20d896ad6188c2c", "symbol": "PUMPUSDT", "position": "long", "cost": 100,
  "priceOpen": 0.002381, "priceTakeProfit": 0.00293, "priceStopLoss": 0.00215,
  "peakProfit":  { "pnlPercentage": 21.0972, "price": 0.0028945, "timestamp": 1768407120000 },
  "maxDrawdown": { "pnlPercentage": -5.4165, "price": 0.0022613, "timestamp": 1768086000000 },
  "pnl": { "pnlPercentage": 22.5848, "priceClose": 0.00293, "pnlEntries": 100 },
  "status": "closed", "createdAt": 1768054380000, "updatedAt": 1768407180000
}

symbol_heatmap — per-symbol & portfolio statistics

A single JSON object: a symbols[] array plus portfolio* aggregates. Fields are null where a symbol has too few trades to estimate them.

{
  "symbols": [
    { "symbol": "SOLUSDT", "totalPnl": -8.6256, "totalTrades": 5, "winRate": 40,
      "profitFactor": 0.3370, "expectancy": -1.7251, "avgWin": 2.1925, "avgLoss": -4.3369 }
  ],
  "totalSymbols": 8, "portfolioTotalTrades": 22, "portfolioTotalPnl": 52.2200,
  "portfolioSharpeRatio": 0.3021, "portfolioSortinoRatio": 0.9774,
  "portfolioRecoveryFactor": 2.7523, "portfolioStdDev": 7.8565, "portfolioExpectancy": 2.3736
}

Per-symbol keys: totalPnl, totalTrades, winCount/lossCount, winRate, avgPnl, profitFactor, expectancy, avgWin/avgLoss, streaks, peakProfitPnl/maxDrawdownPnl, avgDuration (min), and risk ratios where computable. portfolio* keys mirror these at book level.

How the pipeline fits together

Telegram channel ──parse──▶ parser_items
                                 │
                                 ▼
            screen (avgRangePct, momentum24hPct + 2 rules) ──▶ screen_items
                                 │ follow (20) / skip (12)
                                 ▼ follow
        candle_items (OHLCV) ──▶ backtest-kit replay
                                     ├─▶ backtest_report   (per-minute actions)
                                     ├─▶ heat_report       (per-trade outcomes)
                                     ├─▶ breakeven_report / partial_report
                                     ├─▶ highest_profit_report / max_drawdown_report
                                     ├─▶ performance_report (engine timing)
                                     ├─▶ position_log       (event log)
                                     │
                                     └─▶ closed_signals ──▶ symbol_heatmap
                                         (22 resolved trades) (portfolio Sharpe 0.302)

Join keys: screen_items.parserItemId → parser_items._id.$oid; every report and closed_signals carry the same signalId / id; timestamp aligns with the 1m candle_items bars.

Use Cases

• —Reproduce the pump-and-dump analysis. From closed_signals + symbol_heatmap, confirm the return is concentrated in two low-cap pumps and that the liquid names (SOL/TRX/POL) are negative.
• —Reproduce the article. Recompute avgRangePct / momentum24hPct from candle_items, apply the two screen rules, and check the Sharpe 0.302 → 0.807 improvement on the filtered trade set.
• —Risk-screening models. Learn the follow / skip decision from order geometry + pre-publication momentum features.
• —Trade-outcome modelling. Predict closeReason or realized PnL from the open-position excursion series (highest_profit_report / max_drawdown_report / position_log).
• —Execution analytics. Reconstruct each trade's bar-by-bar lifecycle by joining backtest_report, the partial/breakeven snapshots, and the candles on signalId + timestamp.

License

Apache-2.0