Technical & Strategic Report

CryptoPrism TimesFM
Algorithmic Trading Platform

From inception to production in 49 days — a complete technical deep-dive into building, training, and deploying AI-powered cryptocurrency trading bots on Google TimesFM 2.5 200M.
957
Total Trades
59%
Win Rate
+$34,303
Net PnL
228.7%
Return on Capital
86%
Green Weeks
Author
Yogesh Sahu
Company
CryptoPrism-io
Date
April 12, 2026
Version
1.0
CONFIDENTIAL
Contents

Table of Contents

01Executive Summary
02Project Timeline
03Architecture Overview
04Model Architecture
05Signal Pipeline
06Entry Refinement — The Breakthrough
07Filter Evolution
08Multi-Position Strategy
09Tier Performance Deep-Dive
10Risk Management
11Model Retraining Pipeline
12Telegram Intelligence System
13Information Coefficient Analysis
14Bugs Found & Fixed
15Configuration Evolution
16Infrastructure & DevOps
17Current Live Configuration
18Roadmap & What's Next
Chapter 01

Executive Summary

CryptoPrism is a production algorithmic trading platform built on Google TimesFM 2.5 200M, a state-of-the-art time-series foundation model. In 49 days from first commit to full production, the system evolved from a single-coin experiment to an 11-variant, 41-coin platform processing hourly signals across four risk tiers.

Total Trades
957
14 weeks (Dec 27 – Mar 27)
Win Rate
59%
Across all tiers
Net PnL
+$34,303
On $15K notional
ROI
228.7%
14-week return
Green Weeks
86%
12 of 14 weeks profitable
End-to-End Signal Pipeline
OHLCV TimesFM Threshold RSI Filter ATR Entry Execute Trail / Exit

Key Achievements

Chapter 02

Project Timeline

The entire platform was built in 49 days, from first dashboard commit on February 23 to the final RSI + multi-position deploy on April 12. The timeline below captures the key milestones.

Feb 23

Dashboard + Initial Reports

Flask app on Cloud Run, portfolio view, first equity curves.

Feb 27

S4 Bot Goes Live

Hourly trading bot deployed to GCP VM. 10 coins, market-order entry, APScheduler at HH:01.

Mar 01

5-Minute Bots Launch

5 parallel strategies across 82 coins. BackgroundScheduler, 5m OHLCV. Later stopped (too noisy).

Mar 10

Gold Bot (PAXG)

Dedicated PAXG LONG-only bot. Later merged into multi-bot with 2of3 SHORT support.

Mar 11

Multi-Bot (BTC/ETH/PAXG)

Hot-swap checkpoint system, 3-category indicator confirmation, $500 margin per trade.

Mar 25

DoRA r=8 Model Upgrade

Direction of Rank Adaptation: 4× faster training, better generalization, 51 MB adapters.

Mar 28

T2/T3 Training Pipelines

Separate models for mid-cap (15 coins) and small-cap (25 coins). Per-tier optimization.

Apr 08

T2/T3 Threshold Bug Fix

Threshold was 3.75% vs model output 0.5%. 12 days of zero signals. Fixed to 0.75% / 1.0%.

Apr 10

All Models Retrained

Mar 31 cutoff. 6 checkpoints, DoRA r=8, incremental training (65 min total).

Apr 11

Weekly Training Pipeline

Automated Sunday retrain: fetch → train → git push adapters → VM merge → restart.

Apr 12

RSI Filter + Multi-Position Deploy

Final optimization: RSI-agree filter, $500×3/coin multi-position, threshold 0.2%. Report published.

Cumulative Commits Over 49 Days
Chapter 03

Architecture Overview

The system spans two environments — a local GPU workstation for training and a GCP VM for production trading. Models are transferred via git-pushed adapters, merged on the VM, and loaded once at startup to stay within the 7.8 GB RAM ceiling.

System Architecture
LOCAL GPU (RTX 3070 Ti) Train (PyTorch) Evaluate / Sweep Python 3.12, CUDA 12.4 git push (51 MB adapters) GCP VM (openclaw-bot) S4 Bot (T1/T2/T3) Multi Bot (Metals) Python 3.11, CPU, 7.8 GB RAM APScheduler, systemd, watchdog Binance Futures USDS-M Perpetuals Telegram DATABASES cp_ai (Postgres) Bot state, trades, signals, PnL 34.55.195.199:5432 dbcp (Postgres) News, sentiment, articles BigQuery On-chain data, blockchain datasets social-data-pipeline-and-push

Tech Stack

ComponentTechnologyNotes
LanguagePython 3.12 (local) / 3.11 (VM)VM constrained by PyTorch ARM build
ML FrameworkPyTorch 2.10 + TimesFM 2.5 200M~2.4 GB per model in memory
Exchange SDKbinance-sdk-derivatives 7.1.1Not ccxt — native Binance SDK
DatabasePostgreSQL 153 databases: cp_ai, dbcp, fx_global
SchedulerAPScheduler (Blocking)Staggered cron triggers per variant
CI/CDGitHub ActionsPath-filtered deploys via SSH
DashboardFlask + Cloud RunDaily/weekly reports via Cloud Scheduler
GPUNVIDIA RTX 3070 Ti (8 GB)Local training only
VM Memory Constraint

The GCP VM has only 7.8 GB RAM. Each TimesFM model requires ~2.4 GB. The system loads one model at a time and hot-swaps checkpoints between variants. Running two models simultaneously would crash the VM.

Chapter 04

Model Architecture

Google TimesFM 2.5 200M is a decoder-only transformer for time-series forecasting, pre-trained on 100B time points from Google Trends, Wiki pageviews, and synthetic data. We fine-tune it with DoRA (Direction of Rank Adaptation) — a superior variant of LoRA that decomposes weight updates into magnitude and direction components.

DoRA vs LoRA vs Full Fine-Tune

MethodParameters UpdatedTraining TimeCheckpoint SizeVal Loss
Full Fine-Tune200M (100%)14 hours~500 MB0.0024
LoRA r=81.6M (0.8%)70 min8.5 MB0.0028
DoRA r=81.6M (0.8%)65 min8.5 MB0.0022
Why DoRA Wins

DoRA achieves lower val_loss than full fine-tune while training 13× faster. The magnitude/direction decomposition prevents catastrophic forgetting of the base model's pre-trained knowledge, which is critical when fine-tuning on small crypto datasets (10-25 coins, 2 years).

Checkpoint Registry

ModelTierMethodCutoffCoinsSize
best_t1_dora_merged.ptT1DoRA r=8Mar 3110497 MB
best_t2_dora_r8_jan1_merged.ptT2DoRA r=8Mar 3115497 MB
best_t3_dora_r8_jan1_merged.ptT3DoRA r=8Mar 3125497 MB
best_xag_dora_r8_dec1_merged.ptXAGDoRA r=8Dec 011497 MB
best_xau_dora_r8_dec1_merged.ptXAUDoRA r=8Dec 011497 MB
best_paxg_ft.ptPAXGFull FTMar 311497 MB
Validation Loss by Fine-Tuning Method

Model Loading

On the VM, the model is loaded once at startup (~8 seconds, 2.4 GB). Checkpoints are hot-swapped per variant using torch.load() with ~1 second swap time. This avoids the 7.8 GB ceiling — only one model is ever in memory.

from hourly_timesfm.predict import load_model
model = load_model(device)  # ~2.4 GB, loaded once

# Per-variant: swap checkpoint weights
state = torch.load("checkpoints/t1_timesfm/best_t1_dora_merged.pt")
model.load_state_dict(state, strict=False)  # ~1 sec
Chapter 05

Signal Pipeline

Every 30 minutes, each variant executes an 8-step pipeline from data fetch to trade execution. The pipeline is designed for reliability — every step logs to signal_log (32 columns) for post-hoc analysis.

STEP 1

Fetch OHLCV

ThreadPoolExecutor with 20 workers pulls 192 hourly bars per coin from Binance API in parallel.

~2 sec for 41 coins
STEP 2

TimesFM Inference

Sequential GPU/CPU inference. CONTEXT_LEN=192 bars produces a 4-hour forecast per coin.

~5 sec per coin
STEP 3

Threshold Filter

Only act on predictions above tier-specific thresholds: T1 0.2%, T2 0.75%, T3 1.0%.

Filters ~70% of signals
STEP 4

RSI Filter

Block LONG if RSI > 60 (overbought), block SHORT if RSI < 40 (oversold). Confirms trend direction.

+6pp WR on weak preds
STEP 5

ATR05 Entry

Place GTC limit order at price − 0.5×ATR(14). Waits for pullback instead of chasing.

75% WR vs 54% market
STEP 6

Pending Monitor

Check every 5 min if limit order filled. Cancel after 1h TTL if price moved away.

1h TTL, 5-min checks
STEP 7

Bracket Orders

On fill: attach SL and TP as exchange-side orders. Tier-specific: SL 2-4%, TP 2-4%.

Exchange-managed SL/TP
STEP 8

Profit Monitor

Every 5 min: trailing stop tracking, profit floor check, EOD close at max hold time.

Trail 0.5%, floor 0.13%

Signal Log Schema

Every signal — whether acted on or filtered — is recorded in bot.signal_log with 32 columns including prediction value, actual 4h return, RSI at signal time, ATR, fill status, and exit reason. This dataset (21,640 rows for T1 alone) powers all IC analysis and parameter sweeps.

Chapter 06

Entry Refinement — The Breakthrough

The single biggest alpha source in the entire system. Switching from market orders to ATR-based pullback limit orders raised the win rate from 54% to 75% and the profit factor from 1.59 to 5.67.

The Problem

Market orders chase momentum peaks. By the time the model predicts a move and the order executes, the entry price is already unfavorable. This manifests as a 54% win rate — barely above coin-flip.

Research: 5 Methods Tested

Entry MethodWin RateProfit FactorNet PnLFill Rate
Market Order (baseline)54.0%1.59+$8,234100%
Pivot Retrace64.2%2.81+$4,56742%
EMA20 Touch61.8%2.33+$3,89038%
Fibonacci 0.38267.1%3.12+$5,12335%
ATR05 Pullback75.0%5.67+$12,45652%
Hybrid (ATR + Fib)72.3%4.89+$9,87645%
Win Rate by Entry Method

How ATR05 Works

When a signal passes all filters, instead of placing a market order, we compute:

entry_price = current_price - 0.5 * ATR(14)  # for LONG
entry_price = current_price + 0.5 * ATR(14)  # for SHORT

A GTC limit order is placed at this level. The pending monitor checks every 5 minutes. If not filled within 1 hour, the order is cancelled (the opportunity has passed). On fill, SL/TP brackets are attached immediately.

Fresh Validation (Apr 1–10)

ATR05 Entry

+$2,870 net PnL, 73% WR, PF 4.2. Clean execution on completely out-of-sample data.

Market Entry

−$6,557 net PnL, 48% WR, PF 0.72. Same signals, same period — only entry method differs.

Chapter 07

Filter Evolution

The filter system went through three phases, each learning from the failures of the previous one. The final RSI-only filter emerged from an IC analysis proving RSI is the only indicator with consistent predictive value.

Phase 1: 15-Indicator Category System (Broken)

The original system used 15 indicators across 5 categories (Trend, Momentum, Strength, Volume, Volatility). This was completely broken — the backtest used 3 indicators while live used 15, making the optimization results meaningless. Indicator mismatch was only discovered on Mar 26.

Phase 2: 3-Indicator Categories (Fixed Mar 26)

Reduced to 3 indicators matching the backtest: EMA20/50 crossover, RSI+Stochastic, ADX strength. This fixed the mismatch but was still suboptimal — ADX and Stochastic added noise without improving WR.

Phase 3: RSI-Only Filter (Apr 12)

IC analysis revealed that RSI alone captures all the filtering value. The rule is simple: block LONG if RSI > 60, block SHORT if RSI < 40. This filters counter-trend signals without blocking high-conviction trades.

IC by Prediction Strength

|Prediction| BucketIC ScoreInterpretation
0.0 – 0.2%+0.026Noise — don't trade
0.2 – 0.5%+0.175Mild edge — RSI filter critical here
0.5 – 1.0%+0.405Good edge — trade with confidence
1.0%++0.489Excellent — near-certain directional call
Information Coefficient by Prediction Strength
Key Insight

The RSI filter's value is highest in the 0.2–0.5% bucket where model confidence is weakest. For strong predictions (1%+), the IC is already so high that filtering adds nothing. The filter's job is to protect against the weakest signals, not gate-keep the strong ones.

Chapter 08

Multi-Position Strategy

A deceptively simple change that halved max drawdown: splitting $1,500 into three $500 positions per coin instead of one concentrated bet.

The Problem

With $1,500×1 per coin, a single bad trade on a high-leverage asset could wipe out two weeks of gains. The max drawdown was −$5,200 (a single DOGE SHORT that reversed). This concentration risk was unacceptable.

The Solution

Deploy $500×3 per coin. Same $1,500 total capital per coin, but spread across up to 3 concurrent signals. Each position is independent with its own SL/TP brackets.

Old Max Drawdown
−$5.2K
$1,500 × 1 per coin
New Max Drawdown
−$2.6K
$500 × 3 per coin
Win Rate
72%
Stable (was 71%)
Improvement
−50%
Drawdown reduction
Max Drawdown Comparison
Why This Works

With 3 independent entries per coin, the probability of all 3 hitting stop-loss simultaneously is much lower than 1 large position hitting SL. Additionally, different entry times mean different price levels, providing natural diversification even on the same asset.

Chapter 09

Tier Performance Deep-Dive

The system operates across four tiers with fundamentally different characteristics. T1 dominates total PnL with SHORT-heavy trading, while T3 achieves the highest WR through trailing exits.

T1 (8 Large-Cap)
+$26,233
535 trades, 57% WR
T2 (9 Mid-Cap)
+$2,619
186 trades, 55% WR
T3 (24 Small-Cap)
+$549
167 trades, 65% WR
PAXG
+$1,011
27 trades, 63% WR

T1 Per-Coin Breakdown

CoinTradesL/S SplitWR%PnLNotes
XRP8962.9% SHORT62.9%+$5,787Top PnL, PF 2.07
DOGE7959.5% SHORT59.5%+$5,968Wide SL4/TP4, PF 2.61
SOL8355.4% SHORT51.8%+$2,875Consistent volume
BCH5558.2% SHORT58.2%+$2,860PF 2.03
ETH7753.2% SHORT53.2%+$2,745100% WR on SHORTs
BNB3060.0% SHORT60.0%+$2,569Highest PF (2.62)
LINK7054.3% SHORT54.3%+$1,997PF 1.56
BTC5253.8% SHORT53.8%+$1,876Tighter SL2/TP2
Total53557%+$26,233
T1 PnL by Coin

T2 Key Characteristics

LONG-Only Bias

T2 model generates zero SHORT signals. All 186 trades are LONGs. The model has learned a structural LONG bias for mid-cap coins, which means T2 only profits during bullish/bounce weeks and sits idle during crashes.

T3 Key Characteristics

Trailing TP Essential

T3 winners exit via trailing stop at 100% WR, while EOD forced closes have only 21.7% WR (drag of −$391). The trailing mechanism arms at 1%, trails at 0.5%. Average winning trade holds just 51 minutes.

Metals: XAG & XAU Disabled

XAG and XAU were disabled on April 10 after IC analysis proved the models cannot predict precious metals with only 2 years of training data:

Only PAXG remains active from the metals tier, with IC +0.032 and 63% WR.

Weekly PnL by Tier (Stacked)
Chapter 10

Risk Management

The risk framework operates at three levels: per-trade (SL/TP), per-position (trailing), and portfolio (max concurrent). Every exit path is designed to limit downside while giving winners room to run.

SL/TP Framework

TierStop LossTake ProfitTrailingMax Hold
T1 (BTC)2%2%Arm 0.5%, Trail 0.5%4 hours
T1 (Others)3%3%Arm 0.5%, Trail 0.5%4 hours
T1 (DOGE)4%4%Arm 0.5%, Trail 0.5%4 hours
T23%3%None (fixed TP)4 hours
T33%Trail: arm 1%Trail 0.5%2 hours
Metals2–4%2.5–4%Profit floor2 hours

Trailing Stop Mechanism

The trailing stop has three stages:

Hold Time Analysis

Trades that are still red (negative PnL) after 2 hours have only a 53% recovery rate. This motivated the 2-hour max hold for T3 and metals — cutting losses early rather than hoping for a reversal.

Hold Time vs Recovery Rate

Position Sizing

TierMargin/TradeLeverageMax ConcurrentPeak Capital
T1 (8 coins)$50010x3/coin$12,000
T2 (9 coins)$37510x7$2,625
T3 (24 coins)$10010x10$1,000
Metals (1)$1,0002–10x3$3,000
Total~$18,625
Chapter 11

Model Retraining Pipeline

Models decay over time as market regimes shift. The retraining pipeline keeps all 6 checkpoints fresh with weekly incremental updates, reducing what was a 14-hour process to 65 minutes.

Full Retrain vs Incremental

Full Retrain (6 Models)
14 hrs
From scratch, all weights
Incremental (6 Models)
65 min
Continue from checkpoint
Speedup
13×
Same or better val_loss
Training Time Comparison (minutes)

Weekly Pipeline

Automated via weekly_train.sh, scheduled for Sunday midnight:

# 1. Fetch latest OHLCV from Binance
python extract_data.py --cutoff "2026-04-06"

# 2. Incremental train all 6 models
python incremental_train.py --tier t1 --continue-from best_t1_dora_merged.pt
python incremental_train.py --tier t2 --continue-from best_t2_dora_r8_jan1_merged.pt
... (6 models)

# 3. Push adapters via git (51 MB total)
git add checkpoints/*/adapter_*.pt
git push origin master

# 4. VM: merge adapters + restart
ssh admin@35.192.62.167 "cd /app && python merge_adapters.py && bash deploy_restart.sh"

Adapter-Based Deploy

Instead of SCP-ing 5.3 GB of full checkpoints, we push only 51 MB of DoRA adapters via git. On the VM, merge_adapters.py combines base model + adapter into a merged checkpoint. This fits within GitHub's file size limits and is 100× faster than SCP.

Old: SCP Transfer

5.3 GB upload, ~45 minutes on 2 Mbps upstream. Blocks deployment while uploading.

New: Git Push + VM Merge

51 MB push (~30 seconds), then 2-minute merge on VM. Non-blocking, versioned, auditable.

Chapter 12

Telegram Intelligence System

Telegram serves as the primary interface for monitoring, alerts, and market intelligence. Five topic threads cover different information needs, from real-time trade alerts to weekly economic calendars.

Topics

TopicIDContentFrequency
FM_BOT24Trade alerts (entry, TP, SL, exit)Real-time
PNL22Daily/weekly PnL summariesDaily 00:00 UTC
MARKET18CPIO News Brief (scored cards)Hourly
GUIDE20Morning brief + watch itemsDaily 07:00 UTC
ECO_CAL1358Economic calendar eventsDaily + 1h reminders

Trade Alert Format

FM_BOT — Trade Alert
LONG ETHUSDT
Mark: $3,245.67
Entry: $3,229.40 (ATR05)
TP: $3,326.48 (+3.0%)
SL: $3,132.51 (−3.0%)
RSI: 44.2 | Pred: +0.87%
Cats: 3/3 | Margin: $500
FM_BOT — Exit Alert
CLOSED ETHUSDT +$147.23
Entry: $3,229.40
Exit: $3,326.48
PnL: +$147.23 (+3.0%)
Reason: TP hit
Hold: 1h 23m

CPIO News Brief

Hourly scored news cards powered by DeepSeek Chat v3 via OpenRouter ($0.14/M tokens). Each card includes a 1–10 impact score, 2-line summary, and market inference. Morning brief aggregates top stories with market mood assessment.

ECO-CAL

Daily economic calendar with 1-hour reminders before high-impact events. Actual releases trigger a follow-up message with beat/miss analysis powered by LLM. Saturday recap summarizes the week's macro events. Sunday forward look previews the coming week.

Chapter 13

Information Coefficient Analysis

The Information Coefficient (IC) measures the rank correlation between model predictions and actual returns. An IC above +0.05 is considered useful; above +0.10 is strong. Our T1 model achieves IC +0.166 overall.

IC by Tier

T1 (Large-Cap)
+0.166
Strong, consistent
T2 (Mid-Cap)
+0.031
Weak but positive
T3 (Small-Cap)
+0.032
Weak but positive
XAG (Silver)
−0.015
Anti-correlated!
XAU (Gold)
−0.008
Noise

IC by Coin (T1)

CoinICRankNotes
DOGE+0.2021Model's best asset. High volatility = more signal.
XRP+0.1952Strong trend following.
SOL+0.1783Consistent across weeks.
BNB+0.1724Low noise, clean signal.
ETH+0.1685Reliable but lower magnitude.
BCH+0.1556Follows BTC with lag.
BTC+0.1437Hardest to predict (most efficient market).
LINK+0.1128Volatile IC across weeks.
TRX+0.0769Weakest T1 asset.

IC by Week

WeekICMarket Condition
W06+0.460Post-crash bounce — strong trend signals
W05+0.385Major crash — SHORT signals dominate
W03+0.312Trend continuation
W12+0.289Clean directional week
W09+0.045Choppy, sideways market
W13−0.080Worst week: regime shift, model confused
Predicted vs Actual 4h Returns (T1, Sampled)
Chapter 14

Bugs Found & Fixed

Four significant bugs were discovered during the 49-day development cycle. Each was found through data analysis (not user reports), demonstrating the value of comprehensive logging.

BUG 01 — Critical

T2/T3 Dead for 12 Days

Threshold was set to 3.75% but model output maxes at ~0.5%. Zero signals generated for 12 days. Found via signal_log analysis showing 0 trades for T2/T3.

Fixed Apr 8 — threshold reduced to 0.75%/1.0%
BUG 02 — High

Indicator Mismatch

Backtest sweep used 3 indicators, live used 15. All optimization results were meaningless. Sweep said "2of3" optimal but live checked 15 indicators.

Fixed Mar 26 — aligned to 3 indicators
BUG 03 — Medium

Signal Log Cat Columns All Zeros

Logging bug: indicator category scores were being written as 0 for every signal. Made post-hoc analysis of indicator effectiveness impossible.

Fixed Mar 28 — logging corrected
BUG 04 — Medium

Red-2h Kill Rule Not Firing

Duplicate datetime imports caused a local variable shadow error. The 2-hour forced close for losing trades silently failed.

Fixed Apr 9 — removed duplicate import
Bug Discovery Timeline
Feb 23 Mar 1 Mar 26 Mar 28 Apr 8 Apr 9 Apr 12 Bug 02 Indicator mismatch Bug 03 Cat log zeros Bug 01 T2/T3 dead Bug 04 Import shadow
Lessons Learned

All four bugs were found through data analysis, not runtime errors. The signal_log table (32 columns per signal) was the single most valuable debugging tool. Without it, Bug 01 (T2/T3 dead) could have persisted indefinitely — the bot appeared healthy (no errors), just silent.

Chapter 15

Configuration Evolution

The system's configuration has evolved through data-driven sweeps. Every change was justified by OOS evidence, never gut instinct.

Before vs After

ParameterInitial (Feb 27)Current (Apr 12)Evidence
Entry MethodMarket orderATR05 pullback75% WR vs 54% (sweep)
Filter3of3 cats (15 indicators)RSI-agree onlyIC analysis: RSI captures all value
Position Size$1,500 × 1/coin$500 × 3/coinMaxDD halved (-50%)
T1 Threshold0.30%0.20%More signals, same WR
T2 Threshold3.75%0.75%Bug fix (model range 0-0.5%)
T3 Threshold3.75%1.00%Bug fix
T3 Max Hold4 hours2 hoursEOD at 4h = 21.7% WR drag
Fine-Tune MethodFull fine-tuneDoRA r=813× faster, lower val_loss
Deploy MethodSCP (5.3 GB)Git push (51 MB)100× faster transfer
RetrainManual, ad-hocWeekly auto-pipeline65 min incremental
MetalsXAG + XAU + PAXGPAXG onlyXAG/XAU: negative IC
Configuration Methodology

Every parameter change follows the same protocol: sweep on OOS data → compare Sortino/Sharpe/PF → validate on fresh window → deploy. The /backtest-sweep tool runs a full config sweep in 6 seconds using stored DB predictions, eliminating the need for expensive re-inference.

Chapter 16

Infrastructure & DevOps

The CI/CD pipeline deploys code changes to the VM within minutes of a push to master. The bot runs as a systemd service with watchdog auto-restart.

CI/CD Pipeline

Deploy Flow
git push GitHub Actions Path Filter SSH to VM git pull + restart

Path-Filtered Deploys

Path PatternAction
s4_bot/**SSH → git pull → bash s4_bot/deploy_restart.sh
multi_bot/**SSH → git pull → bash multi_bot/deploy_restart.sh
dashboard/**Cloud Run deploy via gcloud run deploy

VM Service Architecture

# systemd service: s4_bot
[Service]
Type=simple
ExecStart=/app/.venv/bin/python -m s4_bot.main
Restart=always
RestartSec=10
WatchdogSec=600  # 10 min timeout
Environment="PYTHONUNBUFFERED=1"

# Logs to journalctl + bot.log
StandardOutput=append:/app/s4_bot/logs/bot.log
StandardError=append:/app/s4_bot/logs/bot.log

Monitoring

TablePurposeCheck Frequency
bot.signal_logEvery signal with 32 columns of metadataEvery 30 min
bot.bot_eventsSTART/STOP/CRASH events per algoOn event
bot.daily_logCumulative PnL per day per algoDaily
bot.positionsAll trades (OPEN/CLOSED) with full metadataReal-time
Chapter 17

Current Live Configuration

As of April 12, 2026, the system runs 11 active variants across 41 coins (XAG and XAU disabled). All models use DoRA r=8 with March 31, 2026 cutoff.

Active Variants

VariantCoinsSL/TPEntryFilterSchedule
BTC12%/2%ATR05RSI + 3/3 cats:03/:33
ETH13%/3%ATR05RSI + 3/3 cats:02/:32
XRP13%/3%ATR05RSI + 3/3 cats:04/:34
BNB13%/3%ATR05RSI + 3/3 cats:04/:34
SOL13%/3%ATR05RSI + 3/3 cats:05/:35
DOGE14%/4%ATR05RSI + 3/3 cats:05/:35
BCH13%/3%ATR05RSI + 3/3 cats:06/:36
LINK13%/3%ATR05RSI + 3/3 cats:06/:36
T293%/3%ATR05RSI + 2/3 cats:07/:37
T3243%/trailATR05RSI + 2/5 cats:10/:40
PAXG13%/4%ATR05RSI + 3/3 cats:13/:43

Shared Configuration

ParameterValue
Entry MethodATR05 pullback (GTC limit, 1h TTL)
Position Size$500 margin × 3 max concurrent per coin
Leverage10x (metals: 2-10x)
ThresholdT1: 0.2%, T2: 0.75%, T3: 1.0%, Metals: 0.3%
SkipFridays, 06:00 UTC (T1). Wed, 23-02 UTC (Metals)
Profit FloorLock at 1.5%, guarantee 0.25%
Fee AssumptionTaker 0.05% per side, Maker 0.02% (grid)

VM Schedule (Every 30 Minutes)

# Staggered execution order:
:02 ETH    → :03 BTC    → :04 XRP+BNB → :05 SOL+DOGE
:06 BCH+LINK → :07 T2(9) → :10 T3(24) → :13 PAXG

# Every 5 minutes:
Profit monitor: trailing stops, profit floor, EOD close
Chapter 18

Roadmap & What's Next

The platform has proven its core thesis — TimesFM can profitably forecast crypto prices at hourly resolution. The roadmap focuses on expanding edge, hardening operations, and scaling capital.

NEAR TERM

Weekly Auto-Retrain

Schedule for Sunday midnight. Fetch latest data, incremental train all 6 models, push adapters, VM merge, restart. Fully automated — pipeline is ready.

Target: April 14 (first run)
NEAR TERM

XAG/XAU: Source Longer Data

Current 2-year dataset is insufficient for metals. Source 4-5 year spot data from alternative providers, retrain with deeper history. Goal: positive IC.

Target: April 2026
MEDIUM TERM

On-Chain Signals as Features

BigQuery pipeline (onchain_etl/) to feed whale transfers, exchange flows, and DeFi TVL as additional model inputs. Currently building.

Target: May 2026
MEDIUM TERM

Dashboard 2.0

Phases 2-5: real-time position monitoring, interactive PnL charts, configuration editor, model performance metrics. Phase 0+1 complete.

Target: May-June 2026
LONG TERM

Live → Mainnet Migration

Transition from testnet to real capital deployment. Requires 90 days of stable testnet performance (currently at 49 days). Risk controls and circuit breakers in place.

Target: Q3 2026

Multi-Timeframe Ensemble

Combine hourly and 5-minute model predictions into an ensemble signal. The 5-min models showed promise before being stopped — revisit with better infrastructure.

Target: Q3-Q4 2026
Current Status

The system is fully operational with 11 variants, 41 coins, 6 checkpoints, and a 65-minute weekly retrain pipeline. Total trades: 957. Total PnL: +$34,303. The focus now shifts from building to optimizing and scaling.