DEV Community: Petr Tripolsky

🤝 What insurance do I need as a solo trader?

Petr Tripolsky — Thu, 24 Sep 2026 12:04:52 +0000

The backtest validation engine source code is available here

I took two paid Telegram signal channels, read a month of their posts (August 2026) through an LLM, and replayed every signal on one-minute candles with commissions and slippage. The first channel produced +10.3% for the month, the second −18.1%. Both figures are without leverage. The difference comes down to the post format, and it's visible even before running the backtest.

Why bother

Imagine a trader who is about to pay for Telegram signals and follow them. What does he need insurance against?

A stop-loss by itself doesn't protect anything. You can set a stop that gets hit 100% of the time and lose your deposit while formally following risk management. Whether the author's rules actually work can only be shown by a replay on history: real posts, one-minute candles, commissions, slippage. The output is a number you can verify.

That's what I did. I picked channels with opposite formats:

Channel A publishes a complete trading plan in every post.
Channel B builds its pitch on personal discipline: "I take 1% of the deposit per trade", "I accept losses and move on."

Results

	Channel A	Channel B
Signal format	entry range + 5 targets + stop	"shorting BTC" + a screenshot
Trades per month	21	24
Result (no leverage, net of commissions)	+10.3%	−18.1%
Winning trades (win rate)	76% (16 of 21)	29% (7 of 24)
Profit factor	1.78	0.57
Average position duration	~17 hours	~44 hours
Worst trade	−4.6% (author's stop)	−7.9% (our stop; the author has none)

Same market, same month, same model in the pipeline — and a 28-percentage-point difference. Below I'll break down how it was computed and where the gap comes from.

The LLM parses the posts, the code makes the decisions

The key design decision in this project: the model makes no trading decisions. It got the task LLMs are actually good at — reading unstructured data.

A post like "Open LONG in the $78600 - $79400 range, targets..., stop $77400" is text with typos, emojis, and ad inserts. Sometimes the signal isn't text at all but a terminal screenshot with the word "Short" in the image. Turning that into typed JSON is the model's job. Deciding whether to enter a position and where to cut losses is the code's job.

import { generateObject, InferenceName, type FormatModel } from "json-inference";

const TradingPositionFormat = {
  type: "object",
  required: ["id", "symbol", "position", "entryRange", "targets", "stoploss", "reasoning"],
  properties: {
    id: {
      type: "number",
      description: "ID of the source message of the signal. If there is no signal, return -1",
    },
    position: {
      type: "string",
      enum: ["long", "short", "wait"],
      description: "Position type. If there is no position, return wait",
    },
    entryRange: {
      type: "object",
      required: ["from", "to"],
      properties: { from: { type: "number" }, to: { type: "number" } },
    },
    targets: {
      type: "array",
      description: "Position targets, 5 levels. If there is no signal, return []",
      items: { type: "number" },
    },
    stoploss: { type: "number" },
    reasoning: { type: "string", description: "Rationale - for debugging" },
  },
} satisfies FormatModel;

How reliable is this

I compared two generations of the cache on identical inputs. The verdicts and all numeric fields matched bit for bit. Only the free text in reasoning differed, down to the language of the response. The grammar holds the structure together; the model copies the prices straight from the post. For a parser, nothing more is needed.

The pipeline: post -> signal -> trade

The strategy ticks every minute on every symbol. Calling the LLM and Telegram on every tick would produce thousands of unnecessary requests and a flood ban. So signal retrieval is wrapped in Cache.file: for Channel A, the channel is checked once every 5 minutes per symbol.

The cache is stored in Mongo. There's a useful side effect: the measure-items collection becomes a dataset of all model responses for the month.

import { Cache } from "backtest-kit";
import { scrapeLookback } from "telegram-reader";

const getSignal = Cache.file(
  async (symbol: string, when: Date) => {
    const coin = `#${symbol.replace("USDT", "")}`;

    // a 15-minute window back from the backtest's "now".
    // A post published after `when` is invisible to the strategy
    let messages = await scrapeLookback({
      channel: "channel_a",
      limit: 15,
      dimension: "minute",
      when,
    });

    messages = messages.filter(({ content }) => content.includes(coin));
    if (!messages.length) return { entry: null }; // we don't call the LLM

    const entry = await generateObject(
      InferenceName.OllamaInference,
      {
        format: TradingPositionFormat,
        messages: [
          { role: "user", content: PARSER_PROMPT }, // prompt string with post-parsing rules
          ...messages.map(({ id, date, content }) => ({
            role: "user" as const,
            content: `ID ${id}\n\n${content}\n\n[${date.toISOString()}]`,
          })),
        ],
      },
      "gemma4:31b-cloud",
    );

    return { entry, message };
  },
  { interval: "5m", name: "channel_a_entry_v3" },
);

Channel A: discipline in the post structure

Every signal post is a complete trading plan:

SIGNAL #BTC/USDT
🔑 Open LONG in the $78600 - $79400 range - 6% of deposit, X15 leverage
🍒 Targets: $80300 / $80900 / $82000 / $83200 / $84500
❗️ STOP LOSS: $77400

The range, the five targets, and the stop are present in every post throughout the month. A signal like this can be executed by code with nothing left to guess. That's what discipline looks like in machine-readable form.

How the strategy executes it

Entry — at market on any post no older than 15 minutes. The signal's edge lives close to the moment of publication.
Take-profit — at the furthest target.
Stop-loss — from the post.
Position management — "level ratcheting". Every reached target becomes a floor. If price pulls back beyond the last reached level by more than 30% of the step between targets, the position is closed.

The step is computed from the target grid of the specific post, so the tolerance adjusts itself: PENGU has steps of roughly 0.3–0.9%, while BTC's are hundreds of dollars.

listenActivePing(async ({ data, currentPrice }) => {
  const levels = data.payload.levels as number[]; // targets from the post
  const currentLevel = getCurrentLevel(data.position, levels, currentPrice);
  const { lastLevel } = await LEVEL_STATE.getState(); // state of the specific position

  if (currentLevel > lastLevel) {
    await LEVEL_STATE.setState({ lastLevel: currentLevel }); // new floor
    return;
  }
  if (!lastLevel) return; // no target reached yet - waiting for stop or take

  const drift = getLevelDrift(data.position, levels, lastLevel, currentPrice);
  const step = getLevelStep(levels, lastLevel); // step between adjacent targets
  if (drift > step * LEVEL_DRIFT_RATIO) {
    await commitClosePending(data.symbol); // pulled back beyond a reached level - exit
  }
});

Outcome

21 trades, +10.3% without leverage net of commissions, 16 of 21 in profit.

The author's stop fired 3 times: from −3.8% to −4.6% — a reasonable size.
Price reached the furthest take-profit once.
The ratchet closed all the remaining trades.

Where the profit came from

I did not copy the author's own money management. His plan — scaling out across five targets with X15–25 leverage — is unprofitable on this very data. The distant targets are almost never reached, and a single stop at that leverage burns 60–100% of margin.

The profit emerged at the intersection: the author's structured signal plus our risk management. The author's direction makes money; his leverage burns the deposit.

Channel B: discipline in words only

Channel B's format is the opposite. There are no ranges, targets, or stops. There are posts like:

Opening a position

Working BTC - short, entered with a possible add-on in mind

Closing a position

So, we're shorting BTC, ETH, SOL at 1% of the deposit each,
BTC and ETH at 100x leverage, Solana at 50x.

The direction and ticker are often visible only in an image: a position screenshot, a TradingView chart, or an exchange trade card. So the model receives not just the post text but the image as well:

const signal = await generateObject(
  InferenceName.OllamaInference,
  {
    format: PositionOpenFormat, // { id, symbol, position: long|short|wait, reasoning }
    messages: [
      { role: "user", content: promptOpen },
      ...messages.map(({ id, date, content, photo }) => ({
        role: "user" as const,
        content: `ID ${id}\n\n${content}\n\n[${date.toISOString()}]`,
        ...(photo && { images: [photo] }), // the post's image in base64 - part of the signal
      })),
    ],
  },
  "gemma4:31b-cloud",
);

I only wrote the image-recognition rules after reviewing the channel's actual screenshots. There was one trap the model fell into regularly: a green P&L number on a short means profit, not "long". The direction is determined only by the word "Long/Short" or by the position of the take and stop zones on the chart. That rule is now spelled out explicitly in the prompt.

How the strategy executes it

The author publishes no stops, so the stop is ours: 7.5% from the entry price.

For this channel, entry and exit are separate decisions made at different times. So there are two pipelines:

while there is no position, the model searches the posts for an entry;
while a position is open, the model searches for the post where the author closes it.

addStrategySchema({ strategyName: "main_strategy" }); // empty schema, no getSignal

listenIdlePing(async ({ symbol, when, currentPrice }) => { // ticks while there is no position
  const { signal } = await getOpenSignal(symbol, when); // Cache.file, 4h
  if (!signal || signal.position === "wait") return;

  await commitCreateSignal(symbol, {
    id: `${signal.id}-${signal.symbol.toLowerCase()}`,
    symbol: signal.symbol,
    ...Position.moonbag({
      position: signal.position,
      currentPrice,
      percentStopLoss: 7.5, // our own stop - the author doesn't publish any
    }),
  });
});

listenActivePing(async ({ symbol, when }) => { // ticks while a position is open
  const { signal } = await getCloseSignal(symbol, when);
  if (signal?.action === "close") await commitClosePending(symbol);
});

Outcome: 24 trades, −18.1%, 7 of 24 in profit.

Conclusions

Run the numbers yourself!

Before paying for signals — let alone following them — verify the author on history. It's cheaper than any insurance. The entire analysis above is built on two backtest.jsonl files. Each line is one event in a position's lifecycle. The basic metrics take about ten lines to compute:

import { readFileSync } from "node:fs";

const trades = readFileSync("backtest_channel_a.jsonl", "utf8")
  .split("\n").filter(Boolean).map(JSON.parse)
  .filter((e) => e.data.action === "closed");

const pnl = trades.reduce((sum, e) => sum + e.data.pnl, 0);
const wins = trades.filter((e) => e.data.pnl > 0).length;
const grossProfit = trades.filter((e) => e.data.pnl > 0).reduce((s, e) => s + e.data.pnl, 0);
const grossLoss = trades.filter((e) => e.data.pnl <= 0).reduce((s, e) => s + e.data.pnl, 0);

console.log({
  trades: trades.length,
  totalPnl: pnl.toFixed(2),                                // +10.26
  winRate: (wins / trades.length * 100).toFixed(0) + "%",  // 76%
  profitFactor: (grossProfit / -grossLoss).toFixed(2),     // 1.78
});

Every closed event contains:

entry and exit prices;
the close reason: take_profit, stop_loss, closed, or time_expired;
the maximum profit and maximum drawdown of the position;
in the note field — the model's full response and the source post.

Any trade can be rewound to the specific Telegram post, and the model's reasoning can be read. The method ports to any other channel in an evening.

Tools

backtest-kit — a backtest and live-trading engine with look-ahead protection.
telegram-reader — reading Telegram channels via MTProto.
json-inference — structured output for ollama.
backtest-ollama-casual — the repository with both strategies and the analysis scripts.

💻 A Full-Fledged Trading Engine for the Node.js Ecosystem

Petr Tripolsky — Fri, 18 Sep 2026 18:05:41 +0000

You can check out the project repo here

Over the past five years the Node.js ecosystem has stabilized. Nothing fundamentally new shows up in it: we discuss why Fastify beats Express, choose between Prisma and Drizzle, argue about ESM versus CommonJS, and swap one bundler for another that does the same thing, only faster. The niches are taken, the tools are mature, the hype has moved to neighboring runtimes. That is good news for production and boring news for an engineer.

Which makes it all the more interesting when an entire new application domain opens up in the ecosystem.

Backtest as one of the execution modes

The library is a toolkit for algorithmic trading that extends Node.js into territory historically ruled by Python alone: Backtrader, VectorBT, Freqtrade. The very same trading strategy runs in both live and backtest without changes

backtest-kit dashboard

The difference is fundamental. A backtester answers the question: "What would have happened if I ran this strategy over history?" The backtest-kit architecture answers a broader one: "How does a strategy exist and execute inside a trading system - historically and in real time?"

Here is an entire strategy - three registrations and a launch. No bootstrap, no DI container, no loop over candles:

import ccxt from "ccxt";
import {
  addExchangeSchema, addFrameSchema, addStrategySchema,
  Position, Backtest, listenSignalBacktest,
} from "backtest-kit";

// Where candles come from
addExchangeSchema({
  exchangeName: "binance",
  getCandles: async (symbol, interval, since, limit) => {
    const ohlcv = await new ccxt.binance().fetchOHLCV(symbol, interval, since.getTime(), limit);
    return ohlcv.map(([timestamp, open, high, low, close, volume]) =>
      ({ timestamp, open, high, low, close, volume }));
  },
});

// Which period of history to replay
addFrameSchema({
  frameName: "feb-2026",
  interval: "1m",
  startDate: new Date("2026-02-01"),
  endDate: new Date("2026-02-28"),
});

// What to do: a pure function "market state -> signal or null"
addStrategySchema({
  strategyName: "my-strategy",
  interval: "15m",
  getSignal: async (symbol, when, currentPrice) => ({
    position: "long",
    ...Position.bracket({ position: "long", currentPrice, percentTakeProfit: 2, percentStopLoss: 1 }),
    minuteEstimatedTime: 60 * 24,
    cost: 100,
  }),
});

Backtest.background("BTCUSDT", {
  strategyName: "my-strategy", exchangeName: "binance", frameName: "feb-2026",
});
listenSignalBacktest(console.log);

Below is a point-by-point breakdown of why this is an engine and not just a backtester.

Backtest and Live share a single execution model

This is not a separate simulator bolted onto the side of a strategy. The system has one execution flow for both backtest and live modes. In backtest mode that flow is replayed over historical data; in live mode it works against the current market. The getSignal function you ran over history is, byte for byte, the same function that trades live. Only the clock source changes:

// Backtest - the clock is driven by a historical frame
Backtest.background("BTCUSDT", { strategyName, exchangeName, frameName });

// Live - the clock is wall-clock; the strategy file hasn't changed by a single line
Live.background("BTCUSDT", { strategyName, exchangeName });

// Paper - live prices, not a single real order, the same code path

The framework's tests (1030+ unit and integration tests) guard this property directly: signal validation, immediate and deferred activation, and TP/SL/timeout checks are identical in both modes, and if the paths ever diverge, a test fails before your deposit does. The practical consequence: the classic disease of "the strategy was profitable in the notebook, then it got rewritten for prod and became a different strategy" disappears. There is nothing to rewrite.

The engine manages the trade lifecycle, not just PnL

A signal in the system is not a row in a results table - it is a finite state machine. Each state carries only the fields that are meaningful in it:

listenSignal((event) => {
  switch (event.action) {
    case "idle":
      /* no signal - only price and context */
      break;
    case "scheduled":
      /* limit order waiting for price - priceOpen, scheduledAt are present */
      break;
    case "opened":
      /* just entered - entry is present, closeReason is not */
      break;
    case "active":
      /* position is alive - pnl, peakProfit, maxDrawdown */
      break;
    case "closed":
      /* exited - closeReason and final pnl; no live fields */
      break;
  }
});

Reading the "live PnL" of a closed position is not a bug that QA catches - it is a line that does not compile. The system models the actual trade lifecycle - entry, partial exit, DCA buys, activation, cancellation, duration - rather than the arithmetic of "entry price minus exit price".

Closed signals portfolio

Stateful execution and state recovery

The live engine persists pending signal state and persisted signal state atomically (write to a temp file + rename) and, after a restart, resumes from the last consistent point. Process killed while placing an order - internal state is unchanged, retry on the next tick. Network dropped - retry. Power cut mid-write - recovery from the last atomic write:

listenSignalLive(async (event) => {
  if (event.action === "closed") {
    await Live.dump(event.symbol, event.strategyName);    // atomic snapshot to disk
    await Partial.dump(event.symbol, event.strategyName);
  }
  if (event.action === "scheduled" || event.action === "cancelled") {
    await Schedule.dump(event.symbol, event.strategyName);
  }
});

For an ordinary backtester, crash recovery is not a concern at all: it crashed - rerun the calculation. For a trading runtime it is a matter of the position's survival, and here it is solved structurally, not with a config flag.

Persistence is part of the runtime architecture

Persistence here is not "save the test results to CSV". It is fifteen-plus separate IPersist*Instance contracts: candles, signals, schedules, risk state, partial closes, breakeven, intervals, measures, logs, LLM agent memory, sessions. Each one can be replaced with its own adapter, and moving from files to a production backend is a single call:

// config/setup.config.ts - loaded once, before the first access to persistence
import { setup } from "@backtest-kit/mongo"; // or @backtest-kit/pg, @backtest-kit/minio

setup(); // all 16 contracts have moved to MongoDB + a Redis O(1) cache.
         // Nothing changed in the strategy code.

@backtest-kit/pg (PostgreSQL + Pgpool-II) gives ~4× faster reads thanks to read replicas; @backtest-kit/minio uses S3 as the source of truth with a Redis time index. Choosing a backend is an infrastructure question, not a trading-logic one.

A real event-driven execution layer

The engine works through events and typed contracts, not through a single runBacktest() function. There is streaming progress, completion events, validation notifications, and a whole family of lifecycle events with *Once and *PerSignal variants. It is React's programming model applied to trading: getSignal is a pure render function, listen* is the effects layer, and the loop belongs to the engine. Behavior is composed by adding independent handlers, not by editing the loop:

// Effect #1: trailing take - close on a 1% pullback from peak profit
listenActivePing(async ({ symbol }) => {
  if (await getPositionPnlPercent(symbol) < 0) return;
  if (await getPositionHighestProfitDistancePnlPercentage(symbol) < 1.0) return;
  await commitClosePending(symbol, { id: "trailing", note: "# Closed by trailing take" });
});

// Effect #2: peak staleness - the peak was long ago, no movement, get out
listenActivePing(async ({ symbol }) => {
  if (await getPositionHighestPnlPercentage(symbol) < 1.0) return;
  if (await getPositionHighestProfitMinutes(symbol) < 240) return;
  await commitClosePending(symbol, { id: "staleness", note: "# Closed by peak staleness" });
});

// Effect #3: a single point for all errors
listenError((error) => Log.debug("error", { message: getErrorMessage(error) }));

Handlers run sequentially through a queue, so an async callback cannot cause a race.

Lifecycle event feed

A dedicated runtime for Live

Live execution is an infinite async loop with interval-based signal throttling, persisted state, scheduled signals, and graceful shutdown. When stopped, Live.background() does not kill the process - it waits until the open position reaches the closed state and only then emits the done event. A deploy never cuts a live trade in half. These are the traits of a production runtime, not of an analytics tool.

Backtest is an execution mode of the engine, not its essence

Historical data simply becomes the source of market events. The strategy mechanism, the execution context, validation, the risk layer - all of it stays the same. That is why the codebase does not split into a "backtest implementation" and a "production implementation" with their inevitable drift.

A proper execution context

A strategy does not work with bare candles passed in as an array. An ambient context flows through the entire await chain (including Promise.all) via AsyncLocalStorage: which strategy, which exchange, which symbol, and most importantly - "now". getCandles has no timestamp parameter that you could forget:

getSignal: async (symbol) => {
  // Not a single timestamp. The context flows even through Promise.all -
  // all four timeframes are automatically pinned to the same tick.
  const [c1h, c15m, c5m, c1m] = await Promise.all([
    getCandles(symbol, "1h", 24),
    getCandles(symbol, "15m", 48),
    getCandles(symbol, "5m", 60),
    getCandles(symbol, "1m", 60),
  ]);
  // You cannot get a candle from the future: the engine only returns [since, now),
  // and the current, not-yet-closed candle is excluded - its half-baked OHLC
  // will not poison your indicators.
};

Look-ahead bias is eliminated not by discipline but by the absence of any surface to make the mistake on.

Domain-level order and position management

Partial exits, DCA, average buy, deferred price-based activation, trailing stop/take, breakeven, profit-lock - the system describes not "bought -> sold" but the real mechanics of managing a position. Here is a complete DCA ladder from a production example (+67.85% for April 2026): open, buy the dips for up to 10 rungs, close on a blended target - about thirty lines, with all the dangerous math inside the engine:

// render: open a LONG with no fixed TP, hard stop at 25%
addStrategySchema({
  strategyName: "apr_2026_strategy",
  getSignal: async (symbol, when, currentPrice) => ({
    position: "long",
    ...Position.moonbag({ position: "long", currentPrice, percentStopLoss: 25 }),
    minuteEstimatedTime: Infinity,
    cost: 100,
  }),
});

// effect: the ladder - buy another $100 on a dip outside the ±1–5% corridor around entries
listenActivePing(async ({ symbol, currentPrice }) => {
  if ((await getPositionEntries(symbol)).length >= 10) return;
  if (await getPositionEntryOverlap(symbol, currentPrice, { upperPercent: 5, lowerPercent: 1 })) return;
  await commitAverageBuy(symbol, 100); // a buy ABOVE the effective price will be rejected by the engine
});

// effect: exit once the blended PnL of the whole ladder reaches +3%
listenActivePing(async ({ symbol }) => {
  if (await getPositionPnlPercent(symbol) < 3) return;
  await commitClosePending(symbol, { id: "target", note: "# Closed by target pnl" });
});

The key line is the comment next to commitAverageBuy: averaging up is structurally forbidden. The effective price is computed as a cost-weighted harmonic mean (which is correct for fixed-amount entries), every partial snapshots its own cost basis, and the final PnL reconciles when cross-checked by two independent methods.

Position details and manual control

The risk layer as part of the architecture

Risk profiles are registered and validated by a separate service, and at the portfolio level at that: ClientRisk sees every open position of every strategy at once, and checkSignalAndReserve atomically reserves a slot between "checked" and "order sent":

addRiskSchema({
  riskName: "demo",
  validations: [
    // TP no closer than 1% - otherwise fees eat the trade
    ({ pendingSignal, currentPrice }) => {
      const { priceOpen = currentPrice, priceTakeProfit, position } = pendingSignal;
      const tp = position === "long"
        ? ((priceTakeProfit - priceOpen) / priceOpen) * 100
        : ((priceOpen - priceTakeProfit) / priceOpen) * 100;
      if (tp < 1) throw new Error(`TP too close: ${tp.toFixed(2)}%`);
    },
    // Risk/Reward no worse than 2:1
    ({ pendingSignal, currentPrice }) => {
      const { priceOpen = currentPrice, priceTakeProfit, priceStopLoss, position } = pendingSignal;
      const reward = position === "long" ? priceTakeProfit - priceOpen : priceOpen - priceTakeProfit;
      const risk   = position === "long" ? priceOpen - priceStopLoss   : priceStopLoss - priceOpen;
      if (reward / risk < 2) throw new Error("Poor R/R");
    },
  ],
});

// Every rejection is an event, not a silent skip
listenRisk(async (event) => { await Risk.dump(event.symbol, event.strategyName); });

Ten strategies, each "risking 10%", no longer add up to an account at 100% exposure. Risk management is part of the engine architecture, not an external script wrapped around a run.

Cron is infrastructure, not an if inside a loop

Scheduled signals (a limit order waiting for its price), their cancellation, manual activation, wait-time statistics - this is a separate subsystem with its own persistence and reports. A signal exists in time before the moment of execution, just as in a real trading system. On top of that sits Cron, which runs on virtual time: in a backtest that replays a month in three seconds, jobs fire on candle boundaries:

Cron.register({ name: "tg-parser", interval: "1h",              // global, once an hour
  handler: async ({ when }) => { await parseTelegramSignals(when); } });

Cron.register({ name: "funding", interval: "1h",                // fan-out across symbols
  symbols: ["BTCUSDT", "ETHUSDT"],
  handler: async ({ symbol, when }) => { await fetchFundingRate(symbol, when); } });

Cron.enable(); // one call - from here on every engine tick is forwarded automatically

In live mode the same API drives real re-polling; parallel backtests hitting the same boundary are coordinated with mutex semantics - a single boundary never fires twice.

Market-data infrastructure

Candles are not loaded as one array just to compute an indicator. There is candle persistence (every candle is an immutable record, first write wins), cache warming, data completeness checks, request deduplication (nine strategies asking for the same BTCUSDT 1m candle produce one request to the exchange, not nine), and a TimeMetaService that tracks market-data freshness between ticks:

for (const symbol of ["BTCUSDT", "ETHUSDT", "SOLUSDT", "BNBUSDT", "XRPUSDT"]) {
  await warmCandles({ exchangeName: "binance", interval: "1m", symbol,
    from: new Date("2026-02-01T00:00:00Z"), to: new Date("2026-02-28T23:59:59Z") });
  Backtest.background(symbol, { strategyName, exchangeName: "binance", frameName: "feb-2026" });
}
// Five symbols in parallel in a single Node process - no forks, no IPC

The result on an ordinary laptop: nine symbols in parallel, ~703× real time per symbol, ~6300× in aggregate.

The research/optimization layer sits on top of the engine, not in place of it

Walker (A/B comparison of strategies over the same history with a ranked report) and Sweep (a grid search of parameters over a feed of crowdsourced trading ideas, with author grading) are not the engine itself. They are its consumers:

# Run three variants of a strategy over the same history and get a ranked report
npx @backtest-kit/cli --walker --symbol BTCUSDT --markdown --output feb_comparison \
  ./content/feb_v1.strategy.ts ./content/feb_v2.strategy.ts ./content/feb_v3.strategy.ts
# -> ./dump/feb_comparison.md

The research infrastructure is built on top of the execution model - exactly the way it is done in grown-up trading systems.

Per-symbol performance heatmap

Schema/registry architecture

Strategy, Exchange, Frame, Risk, Sizing, Walker, Sweep, Action, MCP - everything is registered through schema services with shallow validation and support for partial override*. The engine is a platform that different strategies and execution modules live on. An exchange is plugged in with a single schema - be it CCXT/Binance or a MongoDB holding parsed trades from a regional exchange that isn't on TradingView:

addExchangeSchema({
  exchangeName: "mongo-exchange", // Uzbekistan's stock exchange, Mongolia, Bangladesh - anything
  getCandles: async (symbol, interval, since, limit) =>
    CandleModel.find({ symbol, interval, timestamp: { $gte: since.getTime() } })
      .sort({ timestamp: 1 }).limit(limit).lean(),
});

Graceful shutdown

When the live runtime is stopped, the system does not kill the process: it waits for the last action to finish, brings the position to a terminal state, and only then emits the done event. The first Ctrl+C in the CLI stops all active runs through the regular stop path; the second one is a force-quit. A small detail that unmistakably separates a production runtime from an analytics tool.

Streaming execution

Async generators here are not API decoration. One engine, two ways to consume it - chosen by task, not by capability:

// Event-driven - for production bots and monitoring
Backtest.background("BTCUSDT", config);
listenSignalBacktest((e) => { /* … */ });

// Async iterator - for research, scripts and LLM agents
for await (const event of Backtest.run("BTCUSDT", config)) {
  // signal | progress | done - as the engine runs, with no accumulation in memory,
  // and with the option to break - stopping the run early
}

This is exactly what the @backtest-kit/ui web dashboard is built on: live charts with signal overlays, a KPI board, a portfolio heatmap, a notification feed, and manual position control - the Manual Control buttons call the same broker hooks that the strategy does.

KPI dashboard

Infrastructure is swapped out without rewriting trading logic

Persistence, exchange dependencies, notifications, the logger - all of it sits behind interfaces and adapters. The broker adapter intercepts every state mutation before it is applied: throw an exception and the state is unchanged, with a retry on the next tick. You never write a rollback by hand:

Broker.useBrokerAdapter(class implements Partial<IBroker> {
  async onOrderOpenCommit({ symbol, cost, priceOpen, priceTakeProfit, priceStopLoss }) {
    const ex = await getExchange();
    const qty = truncateQty(ex, symbol, cost / priceOpen);
    await createLimitOrderAndWait(ex, symbol, "buy", qty, priceOpen); // not filled -> throw -> retry
    await ex.createOrder(symbol, "limit", "sell", qty, priceTakeProfit); // protection right after entry
    await createStopLossOrder(ex, symbol, qty, priceStopLoss);
  }
  // onOrderCloseCommit · onPartialProfitCommit · onTrailingStopCommit
  // onBreakevenCommit · onAverageBuyCommit - all hooks are optional
});
Broker.enable(); // in backtest mode the adapter is never called at all

The adapter declares its intent through three typed errors: OrderTransientError ("temporary, try again"), OrderRejectedError ("the exchange refused for good, retrying is pointless"), OrderDeletedError ("the order no longer exists - close the position, cancel the limit order"). Retry counters are bounded and survive a process crash.

Try it

# A project with an example strategy
npx @backtest-kit/cli --init --output my-trading-bot
cd my-trading-bot && npm install && npm start

# Or "eject" - all the scaffolding as editable code in your own repository
npx -y @backtest-kit/sidekick my-trading-bot

Everything is MIT-licensed, the core has no hard dependencies on the additional packages, and persistence is plain files or your own database. The repository contains nine production-quality examples with recorded numbers: from a TensorFlow neural network and a Python indicator via WASM to inverting the signals of a Telegram channel (Sharpe 1.14) and DCA ladders - each with an honest description of the risks and a trade log.

Links:

GitHub: https://github.com/tripolskypetr/backtest-kit
npm: https://www.npmjs.com/package/backtest-kit
Documentation: https://backtest-kit.github.io
Strategy examples: https://github.com/tripolskypetr/backtest-kit/tree/master/example

👾 AI Agent for Scoring Trading Signals

Petr Tripolsky — Fri, 18 Sep 2026 17:59:16 +0000

The source code discussed in this article is published here

The internet is full of people telling you to buy or sell an asset, showing off their win rate and pretty equity curves. The problem is that their statistics belong to them: a bad signal can be deleted, a good one kept, and the result measured from whatever entry point is convenient. Looking at the final feed, there is no way to tell talent from a well-edited history.

Trading signals

Two things are unclear.

1. Does the author delete signals after the fact

A high win rate on its own means nothing: you get one just as easily with a tight TP as by retroactively deleting the losing posts. In the final feed these two cases are indistinguishable. The only thing you can count on is a feed captured at the moment of publication and stored on your own side.

2. How to parse it

Not everyone uses a rigid format with TP/SL stated up front. The free-form case is more interesting: the agent has to extract the trading intent from whatever the author actually wrote.

Automating the process

Using the Model Context Protocol, the agent connects to an external data source. Per the spec, the data source passes along not just text but images as well.

The /loop command hands the AI agent a task to be repeated on an interval. The account is a test one — trades are executed as a simulation inside the engine — and stating that in the prompt is consistent with safety policies.

The agent knows which positions are open, their peak profit, maximum drawdown, and current PnL. Constraints such as "only trade alts" and "never hold more than three positions at once" are written out in plain text.

The interval works. The exit condition is either written into the prompt as a pullback from peak profit, or programmed statically — more on that below.

Token cost

To optimize token consumption, generating the per-channel summary is delegated to a subagent. That way heavy images never reach the global context. Below are the numbers for the unoptimized variant on a $200 Claude Max subscription, measured against the weekly limit. The 5-hour window is not hit by any of the models.

Fable 5: 2 days of operation at a 15-minute polling interval, consumes the entire limit (on Max it is capped at half the weekly allowance)
Opus 5: 8 days at a 15-minute polling interval, weekly limit not exhausted
Sonnet 5: 20 days at a 15-minute polling interval, weekly limit not exhausted
Haiku 4.5: 40 days at a 15-minute polling interval, weekly limit not exhausted

So Sonnet — the Claude Code default, if you never switched it to Opus — lets you check the chat every 15 minutes with no context optimization whatsoever. Add prompt optimizations or widen the interval and you can cover more sources by opening several console chats in tmux.

Why the agent doesn't compute the returns

If you simply ask an AI chat to backtest a trading strategy, it will fit the result to expectations: it has no external check, and it doesn't want to finish the job on a bad number. But if an external tool computes the returns and the agent only has two buttons — buy or sell — then cheating with a close-to-close backtest is off the table.

Evaluation methodology

An author's final rating is assembled not from a single number but from a summary table across every ticker they recommended. That breakdown immediately exposes what aggregate returns hide: an author may run a couple of coins confidently and hand out everything else at random. The analysis is performed not by the AI agent but by its MCP execution engine. Everything is computed there: position drawdowns, Sharpe ratio, Calmar ratio. Separately from the agent.

The outcome

An author of trading signals always shows up with their own statistics: win rate, a streak of profits, a screenshot of the equity curve. Instead of taking their word for it, you can trade their entries yourself and derive a rating from that. Judged on substance, not on credentials. And you can do it automatically, handing the job to an AI in a way that keeps it from deceiving you either.

Local hosting

Architecturally, the AI agent makes a binary decision and never passes an exact entry size when opening or closing a position. All the arithmetic lives in the script, so a weak model can't break risk management. That makes local LLMs viable: ollama implements tool calling for them, and Claude Code connects to it through a proxy exposing an Anthropic-compatible endpoint, with no Anthropic cloud involved.

The exact TP/SL and trailing take are set by the script through lifecycle events. They are derived from current market volatility and are always different — a fixed window is inefficient.

On top of that, so the backtest isn't slowed down waiting on agent iterations, the signal history is dumped to disk and the strategy is verified in isolation, with no chat at all.

Minimal code, agent-only

import { addStrategySchema } from "backtest-kit";

addStrategySchema({
  strategyName: "main_strategy",
});

Everything else the agent does through MCP tools: the schema exists only so the engine knows what name to log trades under.

Manual early close

import {
  listenActivePing,
  commitClosePending,
  getPositionHighestProfitDistancePnlPercentage,
  getPositionHighestPnlPercentage,
  getPositionPnlPercent,
  getPositionHighestProfitMinutes,
} from "backtest-kit";

import { str } from "functools-kit";

const TRAILING_TAKE_DISTANCE = 1.0;
const PEAK_STALENESS_SINCE_PROFIT = 1.0;
const PEAK_STALENESS_SINCE_MINUTES = 240;

listenActivePing(async ({ symbol }) => {
  const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol);
  const currentProfit = await getPositionPnlPercent(symbol);
  if (currentProfit < 0) {
    return;
  }
  if (peakProfitDistance < TRAILING_TAKE_DISTANCE) {
    return;
  }
  await commitClosePending(symbol, {
    id: "trailing_take",
    note: str.newline(
      "# Position closed by trailing take",
    ),
  });
});

listenActivePing(async ({ symbol }) => {
  const peakProfitCost = await getPositionHighestPnlPercentage(symbol);
  const peakProfitMinutes = await getPositionHighestProfitMinutes(symbol);
  if (peakProfitCost < PEAK_STALENESS_SINCE_PROFIT) {
    return;
  }
  if (peakProfitMinutes < PEAK_STALENESS_SINCE_MINUTES) {
    return;
  }
  await commitClosePending(symbol, {
    id: "peak_staleness",
    note: str.newline(
      "# Position closed by peak staleness",
    ),
  });
});

The thresholds here are illustrative; production values depend on the ticker's volatility.

Dashboard

The backtest-kit library handles buying via a limit order on its own, waiting for a seller and rolling the transaction back if none is found. The agent's interface is identical in both modes: it doesn't know whether it's running paper or full live trading. This isn't just convenience, it's protection against behavior fitting — a safeguard won't break a flow like this. Charts and notifications are additionally provided for every position.

If something goes wrong, the agent documents what happened. For example, a trader may want to add to a position. That is accounted for in the math: the average entry price is computed as a volume-weighted average and PnL is recalculated from it rather than from the first order. And the agent writes a text comment on how the trader justified the decision.

Thanks for reading!

💾 MinIO, MongoDB, PostgreSQL for storing 25 years of stock price history

Petr Tripolsky — Fri, 18 Sep 2026 17:56:47 +0000

The MinIO binding source code is available at this link

A stock has no exact price, because for every buyer there must be a seller. Exchanges store stock prices as one-minute Japanese candles: the highest price of the minute, the lowest price of the minute, the opening price at the first moment the trading period opens, and the closing price at the last moment of the trading period. In total: 25 years of history × 20 tickers × 525,600 minutes per year ≈ 262.8 million records

[
  {
    "time": 1720958400,
    "open": 450.25,
    "high": 455.50,
    "low": 448.10,
    "close": 453.80,
    "volume": 12500.5
  },
  ...
]

To test an automated trading strategy, you need to create virtual time that iterates through this entire array of data one candle at a time. If you average it out and use hourly candles, you get close-to-close, an imprecise backtest. I tried several database options and want to tell you about it.

Load profile

class CandleAdapter implements IPersistCandleInstance {
  constructor(
    readonly symbol: string,
    readonly interval: CandleInterval,
    readonly exchangeName: string,
  ) {}
  async waitForInit(initial: boolean) { /* spin up infrastructure */ }
  async readCandlesData(limit: number, sinceTimestamp: number) { /* ... */ }
  async writeCandlesData(candles: CandleData[]) { /* ... */ }
}

Records are immutable. A candle for a specific minute never changes. That means we only need an idempotent upsert that applies only the missing records.
Reads dominate. Running a strategy is 99% reads: point lookups of a single candle by the key (exchange, symbol, interval, timestamp), many of them, in parallel.
A strict visibility contract is required (more on this below) — otherwise concurrent writes fall apart. We don't want to download all 525 million records at once; we need lazy loading.

Write visibility contract

The engine has a hard durability requirement for writes: once writeCandlesData returns control, the very next readCandlesData must see what was written. The file adapter satisfies this trivially (fs.writeFile → fs.readFile will see each other). But a naive implementation on top of any database — "read, and if it's not there, insert" — violates the contract under concurrent writes.

Both writers see "no record," both insert, the second one catches a duplicate key, and the engine goes into a retry. Exactly how each database closes this race without breaking the contract is what determines its place in this review.

Attempt 1. MinIO: object storage, moving away from files

The attempt didn't pay off: MinIO creates a new separate file on disk with metadata for every candle object.

The baseline implementation was saving files to disk. It's slow. I hypothesized that the data model wouldn't have to change at all: a JSON document stays a JSON document, it just moves from local disk to S3-compatible object storage. One bucket, the object key being a pure function of context:

backtest-kit/candle-items/ccxt_binance/TRXUSDT/1m/1767251220000  →  { open, high, low, close, volume, ... }

A deterministic key solves the durability contract for free: an upsert is a single idempotent PUT, there are no races by construction, and S3 guarantees read-after-write for individual objects. Candles are immutable, so a write is stat + PUT without downloading the body:

export class CandleDataService extends BaseMinioStorage("backtest-kit/candle-items") {

  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  public create = async (dto: ICandleDto): Promise<ICandleRow> => {
    this.loggerService.log("candleDataService create", { dto });
    const key = GET_STORAGE_KEY_FN(dto.symbol, dto.interval, dto.timestamp);
    const now = new Date();
    const row: ICandleRow = {
      id: key,
      exchangeName: EXCHANGE_NAME,
      symbol: dto.symbol,
      interval: dto.interval,
      timestamp: dto.timestamp,
      open: dto.open,
      high: dto.high,
      low: dto.low,
      close: dto.close,
      volume: dto.volume,
      createDate: now,
      updatedDate: now,
    };

S3 storage can't do range queries by key (there's no BETWEEN on timestamp). For that, an external index in Redis was used:

export class LogConnectionService extends BaseRedisMap(REDIS_KEY, -1) {

  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  public register = async (objectName: string): Promise<void> => {
    this.loggerService.log("logConnectionService register", { objectName });
    const redis = await getRedis();
    // One Redis SET per minute: SADD deduplicates repeated names, the floor
    // marker (first-ever minute) bounds the backwards walk in listNewest
    const minute = alignToInterval(new Date(), "1m").getTime();
    await redis
      .pipeline()
      .sadd(GET_MINUTE_KEY_FN(this.connectionKey, minute), objectName)
      .setnx(GET_FLOOR_KEY_FN(this.connectionKey), String(minute))
      .exec();
  };
  public listNewest = async (limit: number, prefix = ""): Promise<string[]> => {
    this.loggerService.log("logConnectionService listNewest", { limit, prefix });
    const redis = await getRedis();
    const floorRaw = await redis.get(GET_FLOOR_KEY_FN(this.connectionKey));
    if (!floorRaw) {
      return [];
    }
  ...

Attempt 2. MongoDB: document model without changing the schema

It works, but reading a single candle takes 40ms. In total: 31 days × 1440 minutes per day × 40ms per virtual minute ≈ 30 minutes. The business process breaks because people go off for a smoke break and come back an hour later.

I know that MongoDB is vendor lock-in on their Atlas cloud database, since there are few specialists for scaling it in the CIS. But the vendor Mongo Inc has an ecosystem: whereas for Postgres you need to install the pgAdmin 4 Docker image, which is basically a website ~~(and some people are on Mac),~~ here you can just download the MongoDB Compass application.

export class CandleDbService extends BaseMongoCRUD(CandleModel) {

  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  readonly candleCacheService = inject<CandleCacheService>(TYPES.candleCacheService);

  public upsert = async (dto: ICandleDto): Promise<ICandleRow> => {
    this.loggerService.log("candleDbService upsert", { dto });
    const filter = {
      exchangeName: dto.exchangeName,
      symbol: dto.symbol,
      interval: dto.interval,
      timestamp: dto.timestamp,
    };
    const insertOnly = {
      open: dto.open,
      high: dto.high,
      low: dto.low,
      close: dto.close,
      volume: dto.volume,
    };
    const document = await CandleModel.findOneAndUpdate(
      filter,
      { $setOnInsert: insertOnly },
      { upsert: true, new: true, setDefaultsOnInsert: true },
    );
    ...

To reduce the complexity from logarithmic to O(1), you can add a Redis Lookup; it costs 6GB of RAM and reduces CPU load because there's no memory traffic across the bus from pagination.

export class CandleCacheService extends BaseRedisMap(REDIS_KEY, -1) {

  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  private _cacheKey(symbol: string, interval: CandleInterval, exchangeName: string, timestamp: number): string {
    return `${exchangeName}:${symbol}:${interval}:${timestamp}`;
  }

  public async getCandleId(symbol: string, interval: CandleInterval, exchangeName: string, timestamp: number): Promise<string | null> {
    this.loggerService.log("candleCacheService getCandleId", {
        symbol,
        interval,
        exchangeName,
        timestamp,
    });
    const key = this._cacheKey(symbol, interval, exchangeName, timestamp);
    const id = <string>await super.get(key);
    return id ?? null;
  }

  public async setCandleId(row: ICandleRow): Promise<string> {
    this.loggerService.log(`candleCacheService setCandleId`, {
        symbol: row.symbol,
        interval: row.interval,
        timestamp: row.timestamp
    });
    const key = this._cacheKey(row.symbol, row.interval, row.exchangeName, row.timestamp);
    await super.set(key, row.id);
    return row.id;
  }
}

Attempt 3. PostgreSQL + Pgpool-II: the finale

In the end, I managed to build a PostgreSQL + Pgpool-II setup with four read replicas and one write node. Read speed grew from 40ms to 10ms; a month of virtual-time backtest costs 7 minutes of real time. The business process doesn't break — you can wait without leaving your desk.

What this article was written for — the cluster topology. The load is 99% reads, so pgpool-II sits in front of the database: one write node and three read replicas. pgpool distributes the stream of point SELECTs across the replicas, while transparently routing all DML to the primary.

In terms of capacity, a single table with such indexes holds billions of rows: 130 million candles is ~260 bytes per candle with all indexes, about 34 GB — not even a reason for partitioning. The maximum capacity of Postgres for a single table is 32 TB.

export class CandleDbService extends BasePostgresCRUD(CandleModel) {

  readonly loggerService = inject<LoggerService>(TYPES.loggerService);
  readonly candleCacheService = inject<CandleCacheService>(TYPES.candleCacheService);

  public create = async (dto: ICandleDto): Promise<ICandleRow> => {
    this.loggerService.log("candleDbService create", { dto });
    const repo = await super.repo<ICandleRow>();
    const { raw } = await repo
      .createQueryBuilder()
      .insert()
      .values({
        symbol: dto.symbol,
        interval: dto.interval,
        timestamp: dto.timestamp,
        exchangeName: dto.exchangeName,
        open: dto.open,
        high: dto.high,
        low: dto.low,
        close: dto.close,
        volume: dto.volume,
      })
      .orUpdate(["symbol"], ["exchangeName", "symbol", "interval", "timestamp"])
      .returning("*")
      .execute();
    const result = raw[0] as ICandleRow;
    await this.candleCacheService.setCandleId(result);
    return result;
  };

In all three variants, Redis sits in front of the storage. The popular explanation "O(1) instead of O(log n)" doesn't hold in practice: a b-tree traversal over a billion rows is 4–5 pages that have long been sitting in cache, i.e. microseconds. A network round-trip is an order of magnitude more expensive than the traversal itself. If it were about asymptotics, the cache could be thrown away.

A few words about Redis Lookup

The real win from Redis is in reducing memory traffic per lookup, i.e. offloading the database CPU. The scheme is two-step: Redis returns the id by the context key, and the database fetches the row by PK — the cheapest possible traversal; on a miss we go into the index and populate the cache.

Why this offloads the CPU for each database:

PostgreSQL. A point SELECT is a parser, planner, executor, buffer pins, a traversal of 4–5 pages of 8 KB each with random accesses within each: dozens of L1/L2 misses and noticeable memory bandwidth per query. A Redis GET by a short key is a hash bucket and a short string, one or two cache lines. On the same hardware Redis delivers 100–200k GET/s per core versus 20–50k point SELECT/s. The cache doesn't speed up an individual query — it triples to sextuples throughput and leaves the primary's and replicas' CPU for real work.
MongoDB. The pattern is twice as valuable: a miss on a composite index drags along decompression of a WiredTiger block — pure CPU, multiplied by memory bandwidth. A Redis cache of ctx → _id turns the hot path into GET + findById, removing both the decompression and the index traversal.
MinIO. Here a per-object cache isn't needed: the deterministic key is itself "O(1) addressing." Redis works differently — a minute-level index substitutes for the S3 LIST (which on the server reads meta-catalogs from disk), and the dedup set of written keys eliminates the avalanche of stat requests.

🕹️ How to Debug Your Bot's Exchange Connection in an Hour, Not Three Days

Petr Tripolsky — Fri, 18 Sep 2026 17:54:29 +0000

The source code discussed in this article is published in this repository

A surgeon isn't allowed into the operating room until they've practiced a suture a hundred times on a trainer. A pilot sits in a full-scale cockpit simulator — same switches, same inertia, same engine failure on takeoff — long before their first live flight. No one would think to teach a pilot to fly by sending them on an actual flight and waiting for something to break.

But in algotrading, that's exactly what we do.

The Pain Nobody Writes About in Tutorials

The backtest is green. Paper trading is green. The strategy is mathematically sound, look-ahead bias is scrubbed out, the metrics are honest. You write an exchange adapter — the very layer that turns a signal { position: 'long', priceOpen: 66817 } into a real order on the exchange. And you launch the bot in live.

And then begins what nobody writes about in competitors' READMEs.

To verify that the adapter even works — that the order goes through, leverage gets set, positionSide in hedge mode isn't mixed up, quantity rounding passes the exchange's filters, TP/SL land on the correct side — you need to wait for a trading signal.

And the signal may not come. A day. Two. Three days.

By its very nature, a strategy stays silent most of the time: it waits for conditions, waits for a breakout, waits for news. You sit and stare at a log where nothing is happening. The bot is alive, the bot is healthy, the bot is waiting. And then the moment comes. At 03:47 in the morning the conditions align, the bot forms a signal, pulls the adapter and... catches a bug.

ExchangeAPIException: -4061 Order's position side does not match user's setting.

Congratulations. You spent three days of waiting to learn that in hedge mode you need to send positionSide as LONG, not BOTH. You fix one line. And you wait another three days until the next signal to check that this time the quantity rounding under stepSize won't fall apart.

The integration debugging cycle is three days per iteration. And the fix itself is a single line.

Why You Can't Catch This by "Staring Hard"

The obvious counterargument: "read the adapter code by eye, find the bug before launch."

Doesn't work. Exchange integration isn't about logic, it's about a hundred micro-mismatches with reality that are impossible to see in code:

stepSize and tickSize differ for every pair, and the exchange will reject an order with one extra decimal place;
minimum notional (minNotional) — an order for $4 goes through, but $3.90 doesn't;
in hedge mode you need positionSide, in one-way mode you can't send it at all;
reduceOnly on close, otherwise you'll open a counter-position instead of exiting;
stop_loss_limit on spot vs STOP_MARKET on futures — different order types, different fields;
ghost position: the exchange shows a remainder of 0.0000001 coins, and closePosition goes into an infinite loop.

Each of these points is a separate trip to the exchange's documentation, which is verified only by a live call. You won't catch it by eye, because the bug isn't in your logic — the bug is in how your logic meets the specific settings of a specific account on a specific exchange.

The standard debugging path looks like this:

Write the adapter from the exchange docs
Launch live
Wait for a signal (hours — days)
Signal arrives -> catch -4061 / -1111 / -2010
Fix one line
GOTO 2

This isn't debugging. It's roulette with a spin interval of a day.

A Control Button for the Human

backtest-kit has a web dashboard (@backtest-kit/ui), and in it — a Manual Control section. This isn't "view the position state." These are physical buttons that pull the very same broker-adapter hooks as the real strategy:

OPEN POSITION — open a position by hand, right now;
COMMIT AVERAGING — average in (the same onAverageBuyCommit);
COMMIT BREAKEVEN — move the stop to breakeven;
CLOSE POSITION — close.

You're not verifying a line of code — you're verifying how the system works as a whole: adapter -> engine -> persistence -> opening a position -> protective orders. It's the difference between "read the function's code" and "watched the function run inside a living organism."

Not Just for Debugging

A button that pulls a real hook on a real account is a full-fledged trading instrument. And here's where it suddenly solves problems for which writing a dedicated strategy is impossible, since the conditions can't be reproduced in a backtest.

1. A manual hedge against insider info the strategy doesn't see.

Your strategy trades LONG on minute candles — it catches microstructure, local impulses, but by construction it's blind to the macro picture. And then you learn something before the market does: in an hour there's a rate decision / a delisting court ruling / a major exchange hack — something after which the market will collapse in panic. Rewriting the minute strategy for this is pointless: it's about something else. But you have an open LONG position, and it'll catch the whole crash.

You manually open a global SHORT on top — with the same OPEN POSITION, with minuteEstimatedTime: Infinity, like an umbrella over the entire portfolio. The minute strategy keeps doing its job as if nothing happened, while the manual short neutralizes the systemic risk exactly for the window until the news plays out. The dashboard meanwhile honestly shows both positions and the total PNL — you see net exposure rather than guessing. After the news, you close the short with a button and return to normal mode.

2. A way out when the strategy has lost its edge, but the bot is obligated to act.

The reality of a production deployment at a hedge fund or on a managed account: the bot has to show activity for reporting. And the strategy may go weeks without seeing an effective entry point — the market is ranging, conditions don't align, the edge has temporarily evaporated. Formally everything is correct: better not to trade than to trade garbage. But to an investor/compliance, "the bot did nothing for two weeks" looks like "the bot broke."

Manual control bridges this gap. You can manually open/close a controlled position for the reporting period, record a meaningful action in the JSONL logs (with a note explaining the reason), and not cripple the automated logic in the process. The strategy stays clean, and the reporting stays alive. This isn't a crutch in the code you'll have to clean up later — it's an operator's decision on top of an unchanged engine.

3. Grab a local pump by hand, one the strategy isn't built for.

A strategy is always a specialization. If it's tuned to catch reversions to the mean, by construction it doesn't enter a vertical pump — to it that's "too far from the entry point, the risk/reward doesn't add up." And it's right 95% of the time. But right now, specifically, you can see with your own eyes a coin flying on volume, and you understand the move is real.

Writing a dedicated pump detector for this (Hawkes, CUSUM, volume z-scores — I have a separate library for that) is overkill for a one-off case. It's easier to hit OPEN POSITION, enter by hand, and then hand the position over to the engine: the same commitBreakeven will drag the stop to breakeven, commitAveraging will average in on a pullback, the trailing will take the profit. You gave the system an entry point the strategy missed — but all position management after entry remained automated and battle-tested.

In all three cases the same property is at work: the manual action goes through the same engine as the automated one. A position opened by hand isn't an "external trade outside the system" — it's a full-fledged signal in persistent storage, with the same lifecycle, the same rendering, the same protective orders, and the same DCA/breakeven/trailing hooks. The operator and the algorithm work in a single circuit, not in two parallel universes that won't reconcile in the report later.

Bottom Line: What Replaces Three Days of Waiting

	Standard path	backtest-kit
How to launch an adapter check	Wait for a trading signal	Press a button
Time to first error	Hours — days	Seconds
What gets verified	A single call	The whole chain: adapter, engine, persistence, UI, protective orders
Fidelity	The real path, but you wait	The real path, right now

Thanks for reading!

💸 Escaping zero expectation: from a fixed-sum game to a growing-sum game

Petr Tripolsky — Fri, 18 Sep 2026 17:52:39 +0000

The source code discussed in the article is published in this repository.

Any trading strategy, on an infinite time horizon, tends toward zero expected value per trade: you earned nothing, you paid the exchange a commission. One might assume this is due to information leakage, that the strategy is being used by other market participants and they take the liquidity. But the reason is different: it is the fundamental law of large numbers. Market volume is forecastable, which means it is a finite sum. 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.

Look at the chart: portfolio return growth first increases, then runs into a plateau without any pronounced upward or downward movement. The nearest analogy: an object thrown upward, when acceleration and gravity balance out, stops at a point and then falls back down.

A game with a finite sum

Any effective quant strategy is an exploit of a market inefficiency. As soon as everyone uses the exploit — the inefficiency disappears, because what created it in the first place was precisely the fact that nobody was arbitraging it. The market comes into equilibrium. And equilibrium for a participant means a simple thing: the mathematical expectation of a trade becomes zero minus exchange commission. Not "a small profit", but a strictly negative number.

Escape into a game with a growing sum

There is only one way out of this trap: look at what brings money into the system from the outside, rather than redistributing what is already there. One might think this is the accounting reports of companies or funds, but no: the publication of accounting data does not guarantee deterministic behavior of market participants. Mathematically, the guarantee of a growing-sum game is a direct recommendation to the public, if its size tends to infinity.

Piggybacking to paradise

Earlier I covered the stop hunting pattern for liquidity harvesting: market participants get a post with panic sentiment published to them to trigger mass selling, and as a consequence the asset can be bought up all at once for cheaper. But you can also make money on euphoria.

Metric	Value
Total trades	22
Wins / Losses	15 / 7
Winrate	68%
Mean trade PNL	+2.374%
Std dev per trade	7.676%
Sharpe Ratio (per-trade)	+0.302

A Telegram channel publishes signals, they are successful in 68% of cases. The average retail investor will not look any further. And this is a trap: risk management does not insure against the black swan scenario at all.

Risks:

High volatility relative to average profit

The average trade is +2.37%, but the standard deviation is ±7.86%. One or two strong losses easily eat up the profit of ten small wins, while the winrate still looks "pretty".

Low Sharpe = weak risk compensation

Sharpe 0.3 indicates that the profit is not large enough compared to the risk being taken. Good trading aims for Sharpe > 1.0.

This is a different pattern of crowd liquidity usage: pump and dump. Let us verify the hypothesis by picking only those signals where the asset's price had already been rising over the previous N hours.

Metric	Value
Total trades	11
Wins / Losses	11 / 0
Winrate	100%
Mean trade PNL	+6.972%
Std dev per trade	8.642%
Sharpe Ratio (per-trade)	+0.807

What improved:

Sharpe Ratio grew 2.67x (0.302 → 0.807)

Profit now compensates the assumed risk much better.

The average trade became almost 3x more profitable (+2.37% → +6.97%)

Portfolio drawdowns went away: fewer losing trades.

The price growth over the last N hours is an empirical criterion. I knew where to look in advance, but I did not perform an analysis of the matrix of recommendation posts. If you take the top 100 channels, using publication time and recommendation direction you can identify a single author behind several anonymous accounts. Further, with the link to a single author, you can find out how many more channels he is potentially capable of using to continue the pump.

How to make money on this

Using a self enforcement runtime, a parser and a high-performance backtest one can update the empirical entry criteria automatically. The channel parser extracts the direction, entry zone, targets and stop from the text with simple regex rules:

const SIGNAL_FORMAT: ParseFormat<SignalFields> = {
    symbol: {
        pattern: /#([A-Z0-9]+)\/USDT/,
        group: 1,
    },
    direction: {
        pattern: /(ШОРТ|ЛОНГ)/i,
        transform: (raw) => (raw.toUpperCase() === "ШОРТ" ? "short" : "long"),
    },
    entry: {
        pattern: /зоне\s+\$?([\d.,]+)\s*[-–—]\s*(?:\$?[\d.,]+\s*[-–—]\s*)?\$?([\d.,]+)(?=\s)/i,
        transform: (_, m) => ({ from: num(m[1]), to: num(m[2]) }),
    },
    targets: {
        pattern: /Закрыть(?:\s+ордер)?\s+по(?:\s+цене)?\s+\$?([\d.,]+)/gi,
        transform: (_, m) => num(m[1]),
        multi: true,
    },
    stoploss: {
        pattern: /СТОП-?ЛОСС:\s*\$?([\d.,]+)/i,
        transform: (_, m) => num(m[1]),
    },
};

A high-performance backtest computes metrics on pre-publication data:

const PRE_CANDLES_LIMIT = 1440; // 24h of 1m candles for baseline

// the getCandles(.., 1440) window covers exactly the 24h BEFORE the signal publication
const preCandles = await getCandles(symbol, "1m", PRE_CANDLES_LIMIT);

// momentum24h — total price change over the 24h before publication.
// Positive = a pump is already in progress; negative = the market is falling.
const momentum24hPct =
  ((preCandles[preCandles.length - 1].close - preCandles[0].open) /
    preCandles[0].open) * 100;

Logger.log("pre-publication data", { momentum24hPct })

The AI agent programs the filters, changing them as code on each update:

const SHORT_MIN_AVG_RANGE_PCT = 0.07;
const LONG_MIN_MOMENTUM_24H_PCT = -1;

// Filter 1: SHORT on a "sleeping" asset (avgRange < 0.07% over the day, like TRX) —
// thin liquidity, an ideal target for a stop-hunt. This is the case of liquidity
// harvesting: the signal must not be followed.
if (signal.direction === "short" && avgRangePct < SHORT_MIN_AVG_RANGE_PCT) {
  return null;
}

// Filter 2: LONG when the price has fallen more than 1% over the day — "catching knives".
// There is no capital inflow, there is a decline; subscribers are being led against the trend.
if (signal.direction === "long" && momentum24hPct < LONG_MIN_MOMENTUM_24H_PCT) {
  return null;
}

Filter 1 catches the scam mode of liquidity harvesting (zero inflow, stop manipulation) and says "do not enter". Filter 2 catches the absence of fundamental inflow (the market is falling, there is no pump) and also says "do not enter". What remains is exactly what the whole thing was started for: signals under which there is real capital inflow.

Conclusion

A Telegram pump is not a market bug that will be arbitraged away and disappear. It is crowd behavior that reproduces every time the author has an audience. As long as there are subscribers — there is inflow. And that means there is a fundamental factor to which the arithmetic of equilibrium does not apply: it is a game with a growing sum.

Thank you for your attention

⚡ Monorepo architecture for parallel execution of trading strategies

Petr Tripolsky — Fri, 18 Sep 2026 17:50:56 +0000

The source code discussed in the article is published in this GitHub repository

The imperative approach does not work in the AI world. If you build a codebase on a God Object, out of three employees only one will be able to write code, the rest will be blocked by merge conflicts. If you split the repositories, no knowledge base will accumulate: the only information about how a trading strategy works lives in the code itself. The synergistic effect is lost: the Coding Agent will not be able to read code from prior iterations of development. Each next strategy is a random shot, not a continuation of the thought from the previous one

The problem

Open-source software for programming automated trading strategies is all in Python. In Python it is uncomfortable to write declarative code - all examples are imperative classes bloated to thousands of lines, the God Object antipattern

class AwesomeStrategy(IStrategy):
    position_adjustment_enable = True   # global switch, without it DCA does not work

    # 1. Ladder parameters - class attributes
    max_entry_position_adjustment = 9   # max 9 averaging steps + 1 initial entry = 10 steps
    max_dca_multiplier = 5.5            # reserve 5.5x of the stake for future averaging
    stoploss = -0.30                    # a high hard stop is needed, otherwise DCA blows up

    # 2. Initial entry - trim the stake so there is enough left for the ladder
    def custom_stake_amount(self, pair: str, current_time: datetime, current_rate: float,
                            proposed_stake: float, min_stake: float, max_stake: float,
                            entry_tag: Optional[str], side: str, **kwargs) -> float:
        # Reserve the larger part for possible DCA averaging
        return proposed_stake / self.max_dca_multiplier

    # 3. The ladder itself - a separate callback that Freqtrade calls on every tick
    def adjust_trade_position(self, trade: Trade, current_time: datetime,
                              current_rate: float, current_profit: float,
                              min_stake: float, max_stake: float,
                              current_entry_rate: float, current_exit_rate: float,
                              current_entry_profit: float, current_exit_profit: float,
                              **kwargs) -> Optional[float]:
        # Current drawdown is not deep enough - do not average
        if current_profit > -0.05 and trade.nr_of_successful_entries == 1:
            return None
        if current_profit > -0.10 and trade.nr_of_successful_entries == 2:
            return None
        # ... repeat this ladder of conditions for each subsequent step

        # Pull the list of already filled entries from the trade state
        filled_entries = trade.select_filled_orders(trade.entry_side)
        count_of_entries = trade.nr_of_successful_entries
        try:
            # Stake of the first purchase x (count_of_entries - for ladder geometry)
            stake_amount = filled_entries[0].stake_amount
            stake_amount = stake_amount * (1 + (count_of_entries * 0.25))
            return stake_amount
        except Exception:
            return None

    # 4. populate_indicators / populate_entry_trend / populate_exit_trend are still needed,
    #    because without an entry signal the initial entry will never happen.
    def populate_indicators(self, dataframe, metadata): ...
    def populate_entry_trend(self, dataframe, metadata): ...
    def populate_exit_trend(self, dataframe, metadata): ...

This boilerplate only serves laddered averaging: price fell - we bought more. To figure out when to start buying in the first place, in order not to go bankrupt, you will have to add database integration methods into the same class. A direct violation of SOLID

class TelegramSignalStrategy(IStrategy):
    custom_signals = {}  # nested dict: pair -> list of signals

    def bot_start(self) -> None:
        # starts a cron task in a separate thread that goes to Telegram
        # and writes the results into self.custom_signals
        threading.Thread(target=self._poll_telegram_loop, daemon=True).start()

    def _poll_telegram_loop(self):
        while True:
            try:
                messages = telegram_client.iter_messages("crypto_yoda_channel")
                for msg in messages:
                    parsed = self._parse_signal(msg.text)  # regex inline
                    if parsed:
                        self.custom_signals.setdefault(parsed['pair'], []).append(parsed)
            except Exception:
                pass
            time.sleep(60)

    def _parse_signal(self, text: str) -> Optional[dict]:
        m = re.search(r"#([A-Z0-9]+)/USDT.*?(LONG|SHORT).*?zone\s+\$?([\d.,]+)\s*[-–-]\s*\$?([\d.,]+)", text)
        if not m:
            return None
        return {
            "pair": m.group(1) + "/USDT",
            "direction": "long" if m.group(2) == "LONG" else "short",
            "entry_from": float(m.group(3).replace(",", ".")),
            "entry_to":   float(m.group(4).replace(",", ".")),
        }

    def populate_entry_trend(self, dataframe: DataFrame, metadata: dict) -> DataFrame:
        signals = self.custom_signals.get(metadata['pair'], [])
        # ... somehow apply signals to the dataframe here

The entry point deserves separate attention: in freqtrade it is a json file. API keys and magic constants like dry_run are stuffed in together. It is unclear whether to commit these changes or not: if you do commit them, you will always have a merge conflict when working in a team

{
  "dry_run": true,
  "timeframe": "3m",
  "stake_currency": "USDT",
  "stake_amount": 200,
  "max_open_trades": 5,
  "exchange": {
    "name": "binance",
    "key": "af8ddd35195e9dc500b9a6f799f6f5c93d89193b",
    "secret": "08a9dc6db3d7b53e1acebd9275677f4b0a04f1a5",
    "pair_whitelist": ["BTC/USDT", "ETH/USDT"]
  },
  "timerange": "20260401-20260427",
  "datadir": "user_data/data/binance"
}

With this kind of architecture, look-ahead bias cannot be avoided: to build a frontend integration you need to write data into an intermediate database and delete it through crontab. This imperative code is mathematically unprovable, because it does not even come close to looking like a pure function

Solving the problem

Before hiring employees, design a pipeline that will convert the cumulative effect of time spent into the next turn of the dialectical spiral. For that you need to build the following folder structure for the code

monorepo/
├── content/
│   ├── apr_2026.strategy/ 
|       ├──modules
│       │   ├──backtest.module.ts  # testnet paper
│       ├── apr_2026.strategy.ts   # strategy production code
│       ├── apr_2026.test.ts       # developer playground
├── modules/
│       ├── backtest.module.ts     # mainnet paper
│       ├── live.module.ts         # mainnet live
├── packages/
│   ├── core/                      # database layer
│   ├── main/                      # cli arguments parser

N entry points instead of one: gated by a CLI flag

The root import in packages/main/src/index.ts pulls in four files

import "./main/session";
import "./main/backtest";
import "./main/live";
import "./main/paper";

Each of which is a standalone entry point

const main = async () => {
  const { values } = getArgs();

  if (!values.entry) return;
  if (!values.backtest) return;

  await waitForReady(true);

  const [strategySchema] = await listStrategySchema();
  const [exchangeSchema] = await listExchangeSchema();
  const [frameSchema]    = await listFrameSchema();

  if (values.cache) {
    await CACHE_CANDLES_FN();
  }

  for (const symbol of CC_SYMBOL_LIST) {
    Backtest.background(symbol, {
      exchangeName: exchangeSchema.exchangeName,
      strategyName: strategySchema.strategyName,
      frameName:    frameSchema.frameName,
    });
  }
};

main();

Shared event-driven strategy code

The entry, averaging, stop loss and early exit have to be written in a functionally pure way, in a declarative style, so that they can be split across different files and reused

import {
  addStrategySchema, listenActivePing, listenError,
  Log, Position,
  commitClosePending, commitAverageBuy,
  getPositionPnlPercent, getPositionEntryOverlap, getPositionEntries,
} from "backtest-kit";

const HARD_STOP        = 10.0;
const TARGET_PROFIT    = 3;
const LADDER_STEP_COST = 100;
const LADDER_UPPER_STEP = 5;
const LADDER_LOWER_STEP = 1;
const LADDER_MAX_STEPS  = 10;

addStrategySchema({
  strategyName: "apr_2026_strategy",
  getSignal: async (symbol, when, currentPrice) => ({
    ...Position.moonbag({ 
        position: "long", 
        currentPrice, 
        percentStopLoss: HARD_STOP
    }),
    minuteEstimatedTime: Infinity,
    cost: LADDER_STEP_COST,
  }),
});

listenActivePing(async ({ symbol, currentPrice }) => {
  const { length: steps } = await getPositionEntries(symbol);
  if (steps >= LADDER_MAX_STEPS) return;

  const hasOverlap = await getPositionEntryOverlap(symbol, currentPrice, {
    upperPercent: LADDER_UPPER_STEP,
    lowerPercent: LADDER_LOWER_STEP,
  });
  if (hasOverlap) return;

  await commitAverageBuy(symbol, LADDER_STEP_COST);
});

listenActivePing(async ({ symbol }) => {
  const currentProfit = await getPositionPnlPercent(symbol);
  if (currentProfit < TARGET_PROFIT) {
    return;
  }
  await commitClosePending(symbol, { id: "unknown", note: "# closed by target pnl" });
});

This way you can incrementally bolt a trailing take onto any strategy without changing the code. Any code change is a side effect, because it grows the table of possible inputs and outputs of the function, even if the nature of the mutation comes from a shit-coding neural net and not from runtime circumstances.

if (GLOBAL_CONFIG.ATTACH_TRAILING_TAKE) {
    listenActivePing(async ({ symbol, data }) => {
        const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol);
        const currentProfit = await getPositionPnlPercent(symbol);
        if (currentProfit < 0) {
            return;
        }
        if (peakProfitDistance < TRAILING_TAKE) {
            return;
        }
        Log.info("position closed due to the trailing take", {
            symbol,
            data,
        });
        await commitClosePending(symbol, {
            id: "unknown",
            note: str.newline(
                "# closed by trailing take",
            ),
        });
    });
}

In Freqtrade, deleting custom_stoploss means "you have to remember what was important in there". We do not lose information, we only accumulate it

Modular plug-and-play configuration per mode

Next to the strategy lies modules/backtest.module.ts. This is a neighbour file that the CLI loads together with the strategy and that describes "everything that is not the strategy itself" - the exchange, the historical frame, the global parameters

addExchangeSchema({
  exchangeName: "ccxt-exchange",
  getCandles: async (symbol, interval, since, limit) => {
    const exchange = await getExchange();
    const candles  = await exchange.fetchOHLCV(symbol, interval, since.getTime(), limit);
    return candles.map(([timestamp, open, high, low, close, volume]) => ({
      timestamp, open, high, low, close, volume,
    }));
  },
  getOrderBook: async (symbol, depth, _from, _to, backtest) => {
    if (backtest) throw new Error("Order book not supported in backtest");
    const exchange = await getExchange();
    const bookData = await exchange.fetchOrderBook(symbol, depth);
    return {
      symbol,
      asks: bookData.asks.map(([price, quantity]) => ({ price: String(price), quantity: String(quantity) })),
      bids: bookData.bids.map(([price, quantity]) => ({ price: String(price), quantity: String(quantity) })),
    };
  },
  // ...formatPrice, formatQuantity, getAggregatedTrades
});

addFrameSchema({
  frameName:  "apr_2026_frame",
  interval:   "1m",
  startDate:  new Date("2026-04-01T00:00:00Z"),
  endDate:    new Date("2026-04-27T00:00:00Z"),
});

A new strategy is a folder under the content directory. This way several strategies can be running in different terminal tabs without changing the root json

content/apr_2026.strategy/
├── apr_2026.strategy.ts        # strategy entry file
├── apr_2026.test.ts            # developer playground
└── modules/
    └── backtest.module.ts      # exchange + timeframe

It is notable that the timeframe the strategy was run against is not lost and gets committed as code. You can figure out why something stopped working, relative to a known point in time when it definitely did work

MVC for the data layer

The trigger of any significant market move is the news background. As of 2026 indicators do not work, because a price increase is not news. If the news parser code is kept in the same class as the strategy, the system cannot be debugged. The parser code has to be kept separately so that it can be developed via TDD

export class ScraperService {
  private readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  public scrapeDay = async (channel: string, date: Date): Promise<ScraperMessage[]> => {
    const client   = await getTelegram();
    const dayStart = new Date(date); dayStart.setUTCHours(0, 0, 0, 0);
    const dayEnd   = new Date(date); dayEnd.setUTCHours(23, 59, 59, 999);

    const rows: ScraperMessage[] = [];
    for await (const message of client.iterMessages(channel, {
      offsetDate: Math.floor(dayEnd.getTime() / 1000) + 1,
      reverse: false,
    })) {
      if (!message.message) continue;
      const ts = message.date * 1000;
      if (ts < dayStart.getTime()) break;
      rows.push({ id: message.id, content: message.message, channel, date: new Date(ts) });
    }
    return rows;
  }
}

The same applies to the database integration. It is not enough to just write an SQL query - before executing it in backtest you need to check that there was no time-travel into the future, in order to avoid look-ahead bias. To implement this you need a class with methods

class CandleDbService extends BaseCRUD(CandleModel) {
  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  public create = async (dto: ICandleDto): Promise<ICandleRow> => {
    this.loggerService.log("candleDbService create", { dto });
    const filter = {
      symbol: dto.symbol,
      interval: dto.interval,
      timestamp: dto.timestamp,
    };
    const insertOnly = {
      exchangeName: EXCHANGE_NAME,
      open: dto.open,
      high: dto.high,
      low: dto.low,
      close: dto.close,
      volume: dto.volume,
    };
    const document = await CandleModel.findOneAndUpdate(
      filter,
      { $setOnInsert: insertOnly },
      { upsert: true, new: true, setDefaultsOnInsert: true },
    );
    const result = readTransform(document.toJSON()) as unknown as ICandleRow;
    return result;
  };

  public hasCandle = async (symbol: string, interval: CandleInterval, timestamp: number): Promise<boolean> => {
    this.loggerService.log("candleDbService hasCandle", { 
      symbol,
      interval,
      timestamp,
    });
    const candle = await this.findBySymbolIntervalTimestamp(symbol, interval, timestamp);
    return !!candle;
  };

  public findBySymbolIntervalTimestamp = 
    async (symbol: string, interval: CandleInterval, timestamp: number): Promise<ICandleRow | null> => {
      this.loggerService.log("candleDbService findBySymbolIntervalTimestamp", { symbol, interval, timestamp });
      return await await super.findByFilter({ symbol, interval, exchangeName: EXCHANGE_NAME, timestamp });
    };

}

Performance

After rolling out the software, it turned out that the modular approach not only creates jobs and speeds up development, but also delivers significantly higher performance.

class CandleCacheService extends BaseMap(REDIS_KEY, -1) {
  readonly loggerService = inject<LoggerService>(TYPES.loggerService);

  private _cacheKey(symbol: string, interval: CandleInterval, exchangeName: string, timestamp: number): string {
    return `${exchangeName}:${symbol}:${interval}:${timestamp}`;
  }

  public async hasCandleId(symbol: string, interval: CandleInterval, exchangeName: string, timestamp: number) {
    this.loggerService.log("candleCacheService getCandleId", { 
        symbol, 
        interval, 
        exchangeName, 
        timestamp,
    });
    const key = this._cacheKey(symbol, interval, exchangeName, timestamp);
    return await this.has(key);
  }

  public async getCandleId(symbol: string, interval: CandleInterval, exchangeName: string, timestamp: number): Promise<string | null> {
    this.loggerService.log("candleCacheService getCandleId", { 
        symbol, 
        interval, 
        exchangeName, 
        timestamp,
    });
    const key = this._cacheKey(symbol, interval, exchangeName, timestamp);
    const id = <string>await super.get(key);
    return id ?? null;
  }

  public async setCandleId(row: ICandleRow): Promise<string> {
    this.loggerService.log(`candleCacheService setCandleId`, { 
        symbol: row.symbol, 
        interval: row.interval, 
        timestamp: row.timestamp
    });
    const key = this._cacheKey(row.symbol, row.interval, row.exchangeName, row.timestamp);
    await super.set(key, row.id);
    return row.id;
  }
}

All of the most commonly used databases - Postgres, MongoDB, MariaDB, MySQL - use a B-Tree for row lookup, which is O(log n) complexity, where n is the number of rows in the table. A Redis cache lets you reduce the complexity to O(1) by looking up the row id by a composite key, however with the imperative syntax of freqtrade there is simply nowhere to apply it. If you store in redis not just a key-id dictionary but the data itself, performance will be lost on json serialization/deserialization. Below is the table with the measured performance metrics

Metric	Value
Wall-clock span (first → last event)	`1779292952202 − 1779292949309` = 2 893 ms (~2.9 s)
Total events captured	297
Symbols running in parallel	9 (BTC, POL, ZEC, HYPE, XAUT, DOGE, SOL, PENGU, HBAR)
Historical time advanced per symbol	`1775003640000 − 1775001600000` = 2 040 000 ms = 34 minutes
Per-symbol replay speed	34 min historical ÷ 2.9 s wall = ≈ 703× real-time
Aggregate replay speed (9 symbols)	9 × 703 = ≈ 6 326× real-time
Event throughput	297 ev / 2.893 s = ≈ 103 events/sec (one Node process)
Frame coverage	`2026-04-01 → 2026-04-27` = 27 days × 1m candles = 38 880 candles/symbol × 9 = ~350 000 candle ticks

Speed: ~700x acceleration of historical time relative to real time, with 9 parallel contexts - an effective ~6300x relative to a check that waits for candles in real time

Thank you for your attention

🥶 Why Your Broker Froze Your Deposit or Where Does +20% Per Month Come From

Petr Tripolsky — Fri, 18 Sep 2026 17:41:25 +0000

Asset Price Averaging

There's a trading technique called asset price averaging. Let's say we have insider knowledge that Trump is about to post some good news about Iran. So we buy Bitcoin in advance on the rumor, planning to sell it to retail investors once the news breaks.

However, we'd only capture the raw market move. The market went from $65,820 to $79,382 — that's +15.3%. If we take profit in portions, it comes out to about 12%. We put in $100 at the start and pulled out $112.45 at the end. Not a lot for a whole month of waiting.

Here's a trick. The market doesn't rise linearly — there are pullbacks along the way. If the price starts to fall, instead of selling we buy again.

Let me briefly explain the math. A coin was worth 100 rubles, then 75, then 50, then 25. If you buy the coin on each of those days, your average cost per coin is 62.5 rubles — simple arithmetic mean. That's exactly halfway between 50 and 75 rubles.

Looks a lot more attractive already. 12% turns into 19%, and we earned $67.85 instead of $12.45. On top of that, our capital is actually working — we deployed not $100 but $500 total.

But there's a catch.

Even at a -2.5% price dip — which is perfectly normal volatility for Bitcoin — your account balance in fiat will show -$10 at that moment. Your broker will tell you that your funds are frozen.

Everything Is Going According to Plan

Over the course of a month, the worst drawdown on a single trade was 13.92% (−$50.41). In reality, these funds aren't frozen — they're simply gone. The broker is just lying to you, telling you everything is fine. That's because their dashboard only shows closed positions: displaying real-time portfolio drawdowns would cause panic and trigger a mass withdrawal of funds from their scheme.

But what happens if the news forecast doesn't play out?

Source code

/**
 * Averaging
 */
listenActivePing(async ({ symbol, currentPrice }) => {
  const { length: steps } = await getPositionEntries(symbol);
  if (steps >= LADDER_MAX_STEPS) {
    return;
  }
  const hasOverlap = await getPositionEntryOverlap(symbol, currentPrice, {
    upperPercent: LADDER_UPPER_STEP,
    lowerPercent: LADDER_LOWER_STEP,
  });
  if (hasOverlap) {
    return;
  }
  await commitAverageBuy(symbol, LADDER_STEP_COST);
});

/**
 * Closing
 */
listenActivePing(async ({ symbol, data, timestamp }) => {
  console.log(new Date(timestamp));
  const currentProfit = await getPositionPnlPercent(symbol);
  if (currentProfit < TARGET_PROFIT) {
    return;
  }
  Log.info("position closed due to the target pnl reached", {
    symbol,
    data,
  });
  await commitClosePending(symbol, {
    id: "unknown",
    note: str.newline(
      "# Position closed on target PnL",
    ),
  });
});

🌲 Running Pine Script on Exchanges Without TradingView

Petr Tripolsky — Fri, 18 Sep 2026 17:38:35 +0000

The source code discussed in this article is published in this repository

The Pine Script ecosystem contains a huge number of technical analysis tools. However, TradingView itself is not available everywhere. For example, regional stock exchanges of emerging markets that are simply not on TradingView at all — no data, no trading.

MSE (Mongolia) — not available
UZSE (Uzbekistan) — not available
DSE (Dhaka, Bangladesh) — not available
GSE (Ghana) — not available
SGBV (Algeria) — not available
BSE (Botswana) — not available
ESE (Eswatini) — not available
MERJ (Seychelles) — not available

Why Not Just Use Their Websites?

When instead of a clear price chart I see raw aggregate trades with the ability to download only one month in Excel (given a 6-hour trading day and constant holidays), I feel blind. The registration button leads nowhere.

Beyond the price chart, to avoid being limited to standard Excel, I wanted to apply the full range of Open Source tools rather than reinventing the wheel.

Building Candles from Executed Trades

The first script downloads pages with trades. Excel could have been used, but it doesn't include minutes:

async function main() {
  const buildUrl = (p: number) =>
    `https://uzse.uz/trade_results?begin=${begin}&end=${end}&mkt_id=${mktId}&page=${p}&search_key=${symbol}`;

  const browser = await chromium.launch({ headless: true });
  const page = await browser.newPage();

  const firstHtml = await fetchPage(page, buildUrl(1));
  fs.writeFileSync(path.join(TMP_DIR, "trades_page_1.html"), firstHtml, "utf8");

  const totalPages = getLastPage(firstHtml);
  console.log(`Total pages: ${totalPages}`);

  for (let p = 2; p <= totalPages; p++) {
    const html = await fetchPage(page, buildUrl(p));
    fs.writeFileSync(path.join(TMP_DIR, `trades_page_${p}.html`), html, "utf8");
    console.log(`Downloaded page ${p}/${totalPages}`);
  }

  await browser.close();
  console.log(`Done. HTML saved to ${TMP_DIR}`);
}

The second script imports into MongoDB:

function parseHtmlTable(html: string, pageIndex: number) {
  const rows: object[] = [];
  const trRegex = /<tr[\s\S]*?<\/tr>/gi;
  const tdRegex = /<td[^>]*>([\s\S]*?)<\/td>/gi;
  const tagRegex = /<[^>]+>/g;
  let rowIndex = 0;
  const urlKey = extractUrlKey(html);

  let trMatch: RegExpExecArray | null;
  while ((trMatch = trRegex.exec(html)) !== null) {
    const rowHtml = trMatch[0];
    const cells: string[] = [];
    let tdMatch: RegExpExecArray | null;
    while ((tdMatch = tdRegex.exec(rowHtml)) !== null) {
      cells.push(tdMatch[1].replace(tagRegex, " ").replace(/\s+/g, " ").trim());
    }
    if (cells.length < 10) continue;

    const symbolParts = cells[2].split(/\s+/).filter(Boolean);
    const volumeParts = cells[9].split(/\s+/).filter(Boolean);

    const time = parseRuDate(cells[0]);
    const symbol = symbolParts[0] ?? "";
    const tradePrice = parseNumber(cells[7]);
    const quantity = parseNumber(cells[8]);
    const volume = parseNumber(volumeParts[volumeParts.length - 1] ?? "");
    const hash = crypto
      .createHash("sha1")
      .update(`${symbol}|${time?.toISOString()}|${tradePrice}|${quantity}|${volume}|${pageIndex}|${rowIndex}|${urlKey}`)
      .digest("hex");

    rowIndex++;
    rows.push({ time, symbol, issuer: cells[3], securityType: cells[4], market: cells[5], platform: cells[6], tradePrice, quantity, volume, hash });
  }
  return rows.filter((r: any) => r.time !== null);
}

Seeing the Chart

Trading was halted for a week from 12.08.2023 to 21.08.2023. It looks alarming, so we ask Claude what happened during that period. We get a reasoned answer with references.

Reason for the crash: an additional share issuance that tripled the authorized capital.

At the annual general meeting of shareholders on May 26, 2023, a decision was made to increase the bank's authorized capital from 107.77 billion soums to 323.32 billion soums — i.e. approximately 3x — through retained earnings. The new share issue was registered by the regulator on August 7, 2023.

The shares were placed through a private subscription among existing shareholders included in the register, formed on the 10th day from the date of state registration of the issue — meaning the register was fixed approximately on August 17, 2023.

The profit is not paid out in cash but is converted into shares.

Looking at Technical Analysis

I picked the first indicator I came across. It seems we sell at the red bearish line price and buy at the green bullish one. The important thing is that the complex visualization worked.

You can also view the history. It is visible that the price moved far above SMA(20) several times. The same pattern: several days without trading before it. Looks like a single-price auction day.

How to Connect Candles

File ./modules/editor.module.ts:

import { addExchangeSchema } from "backtest-kit";
import { CandleModel } from "../schema/Candle.schema";

import "../config/setup";

addExchangeSchema({
  exchangeName: "mongo-exchange",
  getCandles: async (symbol, interval, since, limit) => {
    const candles = await CandleModel.find(
      { symbol, interval, timestamp: { $gte: since.getTime() } },
      { timestamp: 1, open: 1, high: 1, low: 1, close: 1, volume: 1, _id: 0 }
    )
      .sort({ timestamp: 1 })
      .limit(limit)
      .lean();

    return candles.map(({ timestamp, open, high, low, close, volume }) => ({
      timestamp,
      open,
      high,
      low,
      close,
      volume,
    }));
  },
});

How to Run

Via npm start:

{
  "name": "backtest-kit-project",
  "version": "1.0.0",
  "description": "Backtest Kit trading bot project",
  "main": "index.js",
  "homepage": "https://backtest-kit.github.io/documents/article_07_ai_news_trading_signals.html",
  "scripts": {
    "start": "node ./node_modules/@backtest-kit/cli/build/index.mjs --editor"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs",
  "dependencies": {
    "@backtest-kit/cli": "^7.1.0",
    "@backtest-kit/graph": "^7.1.0",
    "@backtest-kit/pinets": "^7.1.0",
    "@backtest-kit/ui": "^7.1.0",
    "agent-swarm-kit": "^2.5.1",
    "backtest-kit": "^7.1.0",
    "functools-kit": "^2.2.0",
    "garch": "^1.2.3",
    "get-moment-stamp": "^1.1.2",
    "mongoose": "^8.23.0",
    "ollama": "^0.6.3",
    "playwright": "^1.59.1",
    "volume-anomaly": "^1.2.3"
  }
}

What's Interesting

Market participants cannot hire a Pine Script developer

They are hard to find on the market and there is nowhere to place them: there is no TradingView infrastructure. Writing indicator visualizations is a technically complex task that AI will not solve — a human is needed.

News sentiment does not affect stock prices

An indicator is calibrated on historical data. Historical data becomes invalid if market sentiment has changed. Uzbekistan news is not media-prominent.

Party policy is investment

The only news source that affects sentiment is the president of the republic. He called it a shared responsibility of the entire international community to help such regions through investment in their economies and development.

This is exactly the reason why indicators stopped working on major markets: the new value of an indicator itself has become news.

🔪 AI Liquidity Harvesting Machine

Petr Tripolsky — Fri, 18 Sep 2026 17:30:10 +0000

The source code discussed in this article is published in this GitHub repository.

Telegram is full of signal channels — services that publish trading recommendations telling you at what price to buy or sell an asset. Before following any of them, it makes sense to backtest their historical signals.

After exporting the signals to a file and running analysis, a pattern becomes visible: repeated sequences where opening a position in the opposite direction would have been correct.

The channel author is a craftsman — in January 2026, all 8 out of 8 SHORT signals on TRXUSDT moved sharply in the opposite direction within 45 minutes of publication. But is this actually the author's doing?

Cracking Open the Tamagotchi

The step multipliers between take-profit targets are always ×1.52 → ×1.74 → ×1.47 → ×1.50. The T5/SL ratio is always 1.34. This recommendation was generated by a trading algorithm. But that's not the most interesting part.

Fifteen minutes before each post, a volume anomaly appears on the chart: a large blue candle at 10:00. The post publishes at 10:15. Then another candle at exactly 10:30.

The SHORT recommendation with x25 leverage is placed precisely at the low of the 4H candle (green line).

Inverting the Signal and Trading the Counter-Trend

Using the criteria above, we invert the recommendation and enter against the suggested direction. For signal #7, the move occurred but was insufficient to move the position to breakeven.

Here is the price chart showing what happened after each SHORT recommendation with x25 leverage:

Performance

Portfolio PNL: 8.54%

Portfolio Sharpe: 1.08

Avg Peak PNL: 1.44%

Avg Max Drawdown PNL: −0.48%

Source Code

addStrategySchema({
  strategyName: "jan_2026_strategy",
  getSignal: async (symbol, when, currentPrice) => {

    const signal = getActiveSignal(symbol, when);

    if (!signal) {
      return null;
    }

    const close_1m = await getClosePrice(symbol, "1m");

    if (close_1m < signal.entry.from || close_1m > signal.entry.to) {
      return null;
    }

    const [close_4h_prev, close_4h_cur] = await getCandles(symbol, "4h", 2);

    const range_high = Math.max(close_4h_prev.high, close_4h_cur.high);
    const range_low = Math.min(close_4h_prev.low, close_4h_cur.low); 
    const range_middle = (range_high + range_low) / 2; 

    const position = close_1m > range_middle ? "short" : "long";

    return {
      position,
      ...Position.moonbag({
        position,
        currentPrice,
        percentStopLoss: HARD_STOP,
      }),
      minuteEstimatedTime: 24 * 60,
      note: signal.note,
    };
  },
});

listenActivePing(async ({ symbol, data }) => {
  const peakProfitDistance = await getPositionHighestProfitDistancePnlPercentage(symbol);
  const currentProfit = await getPositionPnlPercent(symbol);
  if (currentProfit < 0) {
    return;
  }
  if (peakProfitDistance < TRAILING_TAKE) {
    return;
  }
  Log.info("position closed due to the trailing take", {
    symbol,
    data,
  });
  await commitClosePending(symbol, {
    id: "unknown",
    note: str.newline(
      "# Позиция закрыта по trailing take",
    ),
  });
});

listenActivePing(async ({ symbol, data }) => {
  const peakProfitCost = await getPositionHighestPnlPercentage(symbol);
  const peakProfitMinutes = await getPositionHighestProfitMinutes(symbol);
  if (peakProfitCost < PEAK_STALENESS_SINCE_PROFIT) {
    return;
  }
  if (peakProfitMinutes < PEAK_STALENESS_SINCE_MINUTES) {
    return;
  }
  Log.info("position closed due to the peak staleness", {
    symbol,
    data,
  });
  await commitClosePending(symbol, {
    id: "unknown",
    note: str.newline(
      "# Позиция закрыта по peak staleness",
    ),
  });
});

Thanks for reading!

🧠 AI News Sentiment Analysis as a Trading Signal 🐻🔄🐂

Petr Tripolsky — Fri, 18 Sep 2026 17:27:21 +0000

The source code discussed in this article is published in this GitHub repository.

When trading the market, you can observe situations where moving averages sharply reverse direction. An indicator is calibrated on historical data and assumes a stable regime. Technical analysis recommends using different sets of indicators when the market regime changes — but this doesn't work.

But wait — how did they ever work in the first place? Is this a scam of planetary scale, and what's actually going on?

What Changed?

News sentiment defines the regime. The indicator works inside the regime. Sentiment being changed every 24 hours or shorter.

https://cn.wsj.com/articles/在萬物皆可下注的時代-我們都在-監控局勢-1abd25ab

A Practical Guide to Identifying Sentiment

You need vector search over news. It's easy to implement using Scrapy + PostgreSQL + PgVector or Scrapy + MongoDB Atlas Vector Search. See VectorEmbeddings + Cosine Distance. I personally use a SaaS solution that fits within the free tier — tavily.com. Perplexity Search API also works. Below is a guide on how to structure your search queries to extract news sentiment.

1. Score as a Sorting Criterion, Not a Filter

The word "Trump" doesn't equal "Bitcoin" — but the implication is that he's speculating in the market. Maximum-score results will be flagged as direct advertising. Zero-score results don't mention Bitcoin at all. You want the near-zero score — that's exactly what shapes market sentiment.

Think of it like product placement: Corona beer in Fast & Furious, or a Sony smartphone in a James Bond film.

2. Domain Takes Priority Over Search Query

Searching for "SEC crypto enforcement action lawsuit" is a mistake. Market sentiment is created by specific domains and blogs — the market pioneers. If they don't repost a new SEC filing, nobody sees it. The SEC can show up at a blogger's door with a subpoena, but it's the blogger's post that moves the crowd.

3. Time Takes Priority Over Publication Meaning

Averaging kills directionality — morning optimism cancels out evening pessimism. Sentiment collapses into noise. A news item both precedes an impulse and sustains the continuation of price movement through a cascade. The criterion for the presence of a cascade is a statistically significant increase in the number of publications per unit of time. Each individual publication does not reflect the future in isolation — the future is the synergistic effect of publications combined.

4. Find the Fundamental Narrative Being Priced In — Don't Invent Your Own

It is critically important to use VectorEmbeddings + Cosine Distance rather than an LLM for sentiment search. An LLM will see the keyword "Overbought RSI" and hallucinate a market move from its own knowledge. The task is not to interpret meaning — it's to find the sentiment that authoritative participants are embedding into the market. See RAG Embedding Models.

5. Volume of Publications Increases Noise

You can build a well-crafted system for detecting market sentiment in publications — but the sources themselves may have no audience. What needs calibration is not the prompt, but the set of authorities whose recommendations actually influence retail traders.

Important

LLM and vector news search must be physically separated. Vector search should be performed against the concept of "forecast/outlook," while the LLM should analyze market sentiment. Otherwise, the output will not reflect the fundamental trend being priced in — preceded by a shift in market participant sentiment — but rather an interpretation of technical analysis indicators.

Testing the Hypothesis

Case 1. Neutral-Bearish Trend

Using the recommendations above, I constructed a search query. Tavily has a built-in LLM that produces a short summary across results.

Search query result: neutral-bearish sentiment

Market reaction:

Case 2. Bullish Sentiment

Repeating the experiment on a different date:

Search query result: bullish sentiment

Market reaction:

Recommendations on Search Time Window

1. Not all news agencies include a publication time. To avoid look-ahead bias, those sources must be excluded from the dataset. Among them:

coindesk.com
reuters.com
bloomberg.com
wsj.com

In Tavily's database, these are assigned a timestamp of Thu, ?? Jan ???? 00:00:00 GMT. To filter them out, cast to UTC — otherwise your local timezone will be used as an offset:

const hour = dayjs(publishedDate).utc().get("hour");
const minute = dayjs(publishedDate).utc().get("minute");
if (hour === 0 && minute === 0) {
    console.warn(`fetchNews search invalid publishedDate query=${query} url=${url} from=${from} to=${to}`)
    return false;
}

2. Query data from -2 days back and filter the last 24 hours on your side.

Tavily uses a date without a time component when searching, so on the boundary between 23:59 and 00:00 you will lose publications. Even with a perfect site parser, distributed CDN databases are a problem: the same news article reaches readers at different times as server capacity becomes available.

3. Don't try to outrun the market.

Averaging kills directionality: morning optimism cancels out evening pessimism, and sentiment drifts toward noise. But if you take a window shorter than 24 hours, it becomes unclear how to interpret sentiment: Trump is bombing Iran — but it's unclear whether Bitcoin will drop to zero or rally. A 24-hour window is optimal for understanding context and cutting through noise.

Backtest

All of the above recommendations were successfully automated. The AI agent identifies a news signal:

And holds the position until the news sentiment is exhausted:

For risk management, a statistically unreachable hard stop is set alongside a trailing take-profit.

Why Indicators Don't Work

Traders try to tune a trading regime over a month — but sentiment alternates every day: bearish, bullish, bullish, bearish. As a result, both the bullish and bearish strategies each land at 50/50.

What Can Be Improved

If you exit on a sentiment change, some profit is lost due to the news parser's latency. My solution: exit on a 3% pullback from the position's maximum PnL.

This means a shortfall of 3% PnL multiplied across 10 positions — that's +30% additional profit on top of the existing 16%. Given that the news sentiment is predictable at the time the position is open: do you think it's worth trying to use an indicator for the exit signal?

Thank you for your attention

🤖 News Sentiment AI Analysis Blueprint

Petr Tripolsky — Fri, 18 Sep 2026 17:23:53 +0000

Existing solutions on GitHub have fatal flaws. Let's look at a few examples — pros and cons.

This article covers why existing LLM-based trading agents fail, and how the ReAct (reasoning + acting) pattern fixes the core problem. I'll show a working implementation that generated correct BUY/SELL/WAIT signals during the April 2026 Iran escalation, explain the hierarchical search prompt design, and share the full source code.

TauricResearch/TradingAgents

Link to the source code

A pipeline that pulls posts from Reddit suggestions, X, Bloomberg, Reuters, and Yahoo Finance. Two agents then debate each other: one argues the price will go up, the other argues it will go down. You pass in a number for how many debate rounds to run — at the end, one agent's arguments win out.

This program creates the illusion of working. If you dig into the code, you'll see the swarm is fed a dump of raw indicators. LLMs are technically incapable of processing that properly in a text-based conversation due to a prioritization problem.

LLMs learn to justify an answer faster than they learn to reason carefully. When fed raw indicators — say, RSI and Stoch RSI together — the agent's response is shaped by whichever one it picks up first. But a situation where one indicator says the market is overbought and the other says oversold is extremely common. The chain of reasoning goes like this:

RSI — oversold, in theory the price should go up
There's no backtesting tool to verify this hypothesis, so we don't think about it
Stoch RSI is overbought — I'm not looking at this anymore, I already have my answer

If you hard-code priority weights for the indicators, the system stops being adaptive and bleeds money. In this article I showed how to build an environment that lets an agent dynamically set indicator priorities — but the price is steep: 200k tokens per backtest ($1.20 for Haiku 4.5, $3.60 for Sonnet 4.6, $6.00 for Opus 4.6). Don't update it frequently enough and you're back to static priorities. In other words, TauricResearch is just a coin flip.

Remove the indicators entirely and you get a vacuum cleaner effect. You have Reddit posts, but you have no idea whether it's one person posting their opinion from 10 accounts or 10 genuinely different people. There's also the paid API problem: plugging into X (Twitter) costs $200/month. If you rely on free APIs (like Mastodon), the blogger whose forecasts your agent was tracking might burn out and stop posting.

tripolskypetr/node-ccxt-backtest

Link to the source code

Based on their failed experience, I took a different approach: 8 agents search for targeted news across different topics.

Balance Sheet — On-chain reserves. Exchange outflows, LTH supply, illiquid supply share, HODL waves.
Cash Flow Statement — Capital flows. Net ETF inflows, miner selling pressure, stablecoin exchange inflows, OTC trading volume.
Fundamental Metrics — Network health. Hash rate, MVRV ratio, NVT ratio, Stock-to-Flow model.
P&L Report — Network revenue. Transaction fees, Lightning throughput, bond activity, DeFi TVL.
Insider Transactions — Smart money. MicroStrategy purchases, BlackRock ETF assets, Grayscale GBTC, government wallets.
Asset News — Market sentiment. Regulatory events, exchange hacks, institutional adoption.
Global Macro — Macro environment. Fed rate decisions, CPI surprise prints, DXY index, Fear & Greed index, M2 money supply.
Price History — Volume spikes, breakout confirmations, closed trades.

In an ideal world, this should work. However, there are portfolio performance metrics to consider: max drawdown and sharpe ratio. The issue is that this kind of analysis is too fundamental and too disconnected from real market conditions — where the US president moves markets with a sh*tpost.

Why Both Approaches Don't Work

They're the same thing at different scales: static queries to smart information sources, and static queries to dumb information sources. The problem is the approach itself: the query needs to adapt based on the new market conditions each day brings.

The Reasoning + Acting Pattern

This is an LLM agent pattern where the model alternates between thinking and acting. Simplified: between reasoning steps, give the agent the ability to search the news feed — then it knows what to focus on: a fundamental breakdown or a local bounce.

The Solution

I wrote the following code. Lucky timing: the US president decided to get involved with Iran and was kind enough to give me a live test case. The code is at the bottom of the article — first let's look at the signals and the price chart.

Fundamental Analysis for All of April 2026

{
"reasoning": "All the reports provided focus on negative signals: 1) macroeconomics - the Fed keeps rates high, the dollar is strong, employment growth → risk-off sentiment, limited demand for risky assets. 2) on-chain indicators - a decrease in the LTH substitution, an increase in short-term holders, a drop in the hashprice to a level close to breakeven, outflows from ETFs and a lack of inflows into the largest Spot ETF BlackRock. 3) market metrics - low volume with a price increase, high funding rate (≈15%), no confirming volumes when the resistance is broken, a price drop to $57-$66k and a strong fear index (28). 4) institutional flows - although there are individual large purchases (MicroStrategy, large \"whales\"), their total volume is less than the negative pressures (outflow from ETFs, lack of active whale buying, outflows from large funds). 5) Technical signals – possible false breakout above $68.5k without volume, weak liquidity, high funding rate indicates an overvaluation of bullish positions.\n\nThus, the dominant theme is increasing bearish pressure from macroeconomics and on-chain fundamentals, as well as a lack of convincing institutional demand. Contradictions (some institutional buying and growing BTC dominance) are not enough to redefine the overall picture.\n\nTherefore, the optimal single signal is **SELL**, as the current situation indicates a high risk of a price decline in the coming weeks.\n\n",
"signal": "SELL"
}

April 5, 2026

PS C:\Users\User\Documents\GitHub\node-ccxt-backtest-final> bun .\scripts\run_signal.ts
Searching Bitcoin news April 5 2026
Searching Bitcoin flash crash April 5 2026
Searching April 5 2026 Bitcoin Trump tweet
{
  id: "4cc66bf6-4443-4800-aa43-28b6cb9f8800",
  reasoning: "The acute event is the US ultimatum to Iran, which raises geopolitical tensions and historically leads to price decline in the medium term (bearish risk scenario — probability ≈45%). Technical signals also point to weakness: price is trading below all moving averages, RSI at 44, volume is low, fear index at extreme fear (12) — which could trigger a fast short squeeze, but without a confirming news catalyst this is unlikely. Since signals are contradictory — a sharp drop below $65,500 is possible, but so is a quick rally on a break of $68,200 with volume confirmation — the picture is blurry. Better to stay out for now.\n\nConclusion: WAIT signal.",
  signal: "WAIT",
}

April 8, 2026

PS C:\Users\User\Documents\GitHub\backtest-kit\example> bun .\scripts\run_research.ts
Searching April 8 2026 Bitcoin breaking news
Searching April 8 2026 Bitcoin hack withdrawal suspended
Searching April 8 2026 Trump tweet Bitcoin
Searching April 8 2026 Bitcoin flash crash
Searching Decrypt April 8 2026 Bitcoin Trump ceasefire
{
  id: "c5e27ed0-4bba-4000-a7a1-879b822d6000",
  signal: "BUY",
  reasoning: "The acute event driver — Trump's announcement of a two-week ceasefire with Iran (04:30 UTC) — triggered an instant Bitcoin rally to $72,000, liquidation of ~$425M in short positions, and a massive volume spike (>2M BTC/hour). These facts indicate a sharp bullish impulse that should sustain price growth in the coming hours. Optimal move: open a long with a tight stop-loss around $70,000.",
}

April 9, 2026

PS C:\Users\User\Documents\GitHub\backtest-kit\example> bun .\scripts\run_research.ts
Searching Bitcoin breaking news April 9 2026
Searching Bitcoin Supply Shock: Long-Term Investors Now Control 21% Of Total BTC April 9 2026
Searching Bitcoin breaking news April 8 2026 20:00 UTC
{
  id: "8708ddc6-57aa-4800-a114-787029fbd000",
  reasoning: "The report shows a contradictory picture: on one hand — an acute event — price breaking above $71,000 following ceasefire news, pointing to short-term upside; on the other — strong bearish factors: significant miner selling, hash rate decline, put option dominance (premium ~17%), risk of breaking the $70,000 support and potential pullback to $58–63k, plus quantum vulnerability news rattling investors. With strong bullish and bearish signals present simultaneously, the trader's call is caution with no clear direction. Therefore, the most accurate signal is WAIT.",
  signal: "WAIT",
}

Source Code

Web Search Agent

import { addAgent } from "agent-swarm-kit";
...
import { str } from "functools-kit";

addAgent({
  agentName: AgentName.WebSearchAgent,
  completion: CompletionName.OllamaTextCompletion,
  keepMessages: Infinity,
  prompt: str.newline(
    "You are a web search agent in a trading system agent swarm.",
    "",
    "Your task is to produce an objective report based on the user's query:",
    " * focus on negative news/metrics",
    " * no marketing spin",
    " * don't make things up",
    " * write only what you actually found",
    "",
    "Critical requirements:",
    " * The user specifies a DATE for the report — avoid look-ahead bias",
    " * Avoid bias from articles you find online: analyze the picture objectively, don't just copy one opinion",
    " * If you cannot explicitly determine the date of an internet source, do not use it in your conclusion",
    " * Run multiple search queries — gather all available information",
    "",
    "Don't stop until you've reached an answer to the user's question with reasoning",
    "Respond as a professional trader, in a format ready to paste into a file",
    "Don't write a prefix like 'Sure, here is your report' — just the file content",
    ""
  ),
  tools: [
    ToolName.WebSearchTool,
  ],
});

Trading Signal Generator

import {
  addOutline,
  commitAssistantMessage,
  commitUserMessage,
  dumpOutlineResult,
  execute,
  fork,
  IOutlineHistory,
  IOutlineResult,
} from "agent-swarm-kit";

...

import { str } from "functools-kit";

const DISPLAY_NAME_MAP = {
  BTCUSDT: "Bitcoin",
  ETHUSDT: "Ethereum",
  BNBUSDT: "Binance Coin (BNB)",
  XRPUSDT: "Ripple",
  SOLUSDT: "Solana",
};

const SEARCH_PROMPT = str.newline(
  "You are looking for acute event triggers from the last few hours — things that just happened and aren't fully priced in yet.",
  "Don't look for fundamental data (funding rate, liquidations, whale wallets) — those are lagging and already in the price.",
  "",
  "Level 1 — Acute Events (search first):",
  " - {asset} breaking news {date}",
  " - {asset} SEC CFTC DOJ enforcement action {date}",
  " - {asset} exchange hack withdrawal suspended {date}",
  " - {asset} flash crash reason {date}",
  " - Trump tweet statement Bitcoin crypto {date}",
  " - Bitcoin ETF approval rejection decision {date}",
  "",
  "Level 2 — Macro deviations from expectations (only if already happened):",
  " - Federal Reserve decision surprise Bitcoin reaction {date}",
  " - CPI inflation data surprise {date} Bitcoin",
  " - dollar DXY sudden move Bitcoin correlation {date}",
  "",
  "Level 3 — Volume anomalies:",
  " - {asset} unusual volume spike {date}",
  " - {asset} price sudden move reason {date}",
  "",
  "Level 4 — Pre-made analyst forecasts:",
  " - {asset} price forecast today {date}",
  " - {asset} price target analyst {date}",
  "",
  "Rules:",
  " * Only events from the last 4–12 hours — no week-old lagging analysis",
  " * If you can't explicitly determine a source's date — don't use it",
  " * Don't copy one article's opinion — look for confirmation from multiple sources",
  " * Write only what you found, no speculation",
);

const SIGNAL_PROMPT = str.newline(
  "You are a trader making a directional decision right now based on fresh market events.",
  "",
  "You have read the short-term signals report. Your task is to output one signal for the next few hours.",
  "",
  "**How to think:**",
  " - Acute events outweigh lagging analysis: an exchange hack, a regulator decision, an anomalous volume spike — these are facts, not forecasts",
  " - If data is sparse or no clear event has occurred — choose WAIT",
  " - If the picture is contradictory — choose WAIT",
  "",
  "**Signal definitions (pick exactly one):**",
  " - **BUY**:  Short-term data points to upside in the next few hours",
  " - **SELL**: Short-term data points to downside in the next few hours",
  " - **WAIT**: Data is insufficient or the picture is unclear — don't enter",
  "",
  "**Required output:**",
  "1. **signal**: BUY, SELL, or WAIT.",
  "2. **reasoning**: which specific events from the report led to this conclusion.",
);

const commitSignalSearch = async (
  query: string,
  date: Date,
  resultId: string,
  history: IOutlineHistory,
) => {
  const report = await fork(
    async (clientId, agentName) => {
      await commitUserMessage(
        str.newline(
          "Read what exactly I need you to find and say OK",
          "",
          SEARCH_PROMPT,
        ),
        "user",
        clientId,
        agentName,
      );
      await commitAssistantMessage("OK", clientId, agentName);
      const request = str.newline(
        `Find short-term signals for ${query} on the internet`,
        `Only events relevant as of ${dayjs(date).format("DD MMMM YYYY HH:mm Z")}`,
        `Produce a report on short-term risks and opportunities`,
      );
      return await execute(request, clientId, agentName);
    },
    {
      clientId: `${resultId}_signal`,
      swarmName: SwarmName.WebSearchSwarm,
      onError: (error) => console.error(`Error in SignalOutline search for ${query}:`, error),
    },
  );
  if (!report) {
    throw new Error("SignalOutline web search failed");
  }
  if (typeof report === "symbol") {
    throw new Error("SignalOutline web search failed");
  }
  await history.push(
    {
      role: "user",
      content: str.newline(
        "Read the short-term market signals report and say OK",
        "",
        report,
      ),
    },
    {
      role: "assistant",
      content: "OK",
    },
  );
};

addOutline<ResearchResponseContract>({
  outlineName: OutlineName.ResearchOutline,
  completion: CompletionName.OllamaOutlineToolCompletion,
  format: {
    type: "object",
    properties: {
      signal: {
        type: "string",
        description: "Short-term trading signal for the next few hours.",
        enum: ["BUY", "SELL", "WAIT"],
      },
      reasoning: {
        type: "string",
        description: "Specific events from the report that justify the signal.",
      },
    },
    required: ["signal", "reasoning"],
  },
  getOutlineHistory: async ({ resultId, history }, symbol: string, when: Date) => {
    const displayName = Reflect.get(DISPLAY_NAME_MAP, symbol) || symbol;
    await history.push({
      role: "system",
      content: str.newline(
        `Current date and time: ${dayjs(when).format("DD MMMM YYYY HH:mm")}`,
        `Asset: ${displayName}`,
      ),
    });
    await commitSignalSearch(displayName, when, resultId, history);
    await history.push({
      role: "user",
      content: SIGNAL_PROMPT,
    });
  },
  validations: [
    {
      validate: ({ data }) => {
        if (!data.signal) {
          throw new Error("signal field is empty");
        }
      },
      docDescription: "Validates that the signal is defined.",
    },
    {
      validate: ({ data }) => {
        if (data.signal === "BUY") {
          return;
        }
        if (data.signal === "SELL") {
          return;
        }
        if (data.signal === "WAIT") {
          return;
        }
        throw new Error("signal field must be BUY, SELL, or WAIT");
      },
      docDescription: "Validates that signal contains an allowed value.",
    },
    {
      validate: ({ data }) => {
        if (!data.reasoning) {
          throw new Error("reasoning field is empty");
        }
      },
      docDescription: "Validates that the signal is justified.",
    },
  ],
  callbacks: {
    async onValidDocument(result) {
      if (!result.data) {
        return;
      }
      await dumpOutlineResult(result, "./dump/outline/research");
    },
  },
});