Python / TimesFM / Binance API / BigQuery
TimesFM 100-Coin Trading Bot
ML-powered trading bot using Google TimesFM for signal generation across 100 coins. Automated execution via Binance API.
Showcase
Product Walkthrough
Five reports from the actual c3 OOS validation run (Apr 1–19, 2026) plus a live PnL snapshot. All numbers are pulled from the bot's Postgres state — no synthetic data.
Leadership Lens
01 The Call
Chose to build on Google TimesFM 2.5 200M — a pre-trained time-series foundation model — rather than hand-engineering technical indicators or training a bespoke model from scratch, betting that transfer learning from 100B real-world time points would outperform feature-engineered baselines on crypto OHLCV data.
02 The Bet
Bet that fine-tuning the foundation model with LoRA adapters on crypto-specific data, using only 192-bar context windows on a 7.8 GB RAM CPU-only VM, would achieve production-grade signal quality (AUC > 0.85) without GPU infrastructure — and designed the entire tiered execution system around that constraint from day one.
03 The Trade-off
Accepted sequential TimesFM inference across all 100 coins (no concurrent model instances) due to the 2.4 GB model footprint against the VM's 7.8 GB RAM ceiling, in exchange for avoiding a costly GPU instance upgrade and keeping infrastructure costs flat while running 6 live algo variants simultaneously.
04 The Outcome
Six live algo variants (s4_hourly, fm_sniper, fm_broadnet, fm_patience, fm_momentum, fm_conviction) running 24/7 on Binance Futures across 100 coins in 4 tiers — with backtest AUC of 0.896 and precision of 0.880, automated grid entries, trailing stops, and a Flask dashboard on Cloud Run delivering daily and weekly PDF performance reports.
05 Coordinated
Sole engineer-of-record across the full stack: GCP VM provisioning, TimesFM model integration and LoRA fine-tuning, Binance SDK derivatives integration, PostgreSQL schema design, Cloud Run dashboard deployment, and GitHub Actions CI/CD with 4 path-filtered jobs covering both VM and containerized deployments.
06 Where this goes next
Extend LoRA fine-tuning with live trade feedback to close the backtest-to-live performance gap, add multi-timeframe signal confluence (1h + 4h) to improve entry quality, and integrate BigQuery for long-horizon trade analytics and model retraining pipelines.
01 Chapter 1
ML-Powered Signals at Scale Across 100 Coins
Crypto markets operate 24/7 across hundreds of assets. Manual trading cannot scale — human attention is limited, emotional bias degrades decisions, and opportunity windows close in minutes. The challenge: generate ML-powered trading signals at scale and execute them automatically with rigorous risk management.
Google TimesFM is a pre-trained time-series foundation model trained on 100B real-world time points. Unlike traditional technical indicators, it captures complex temporal patterns without hand-engineered features. The goal: leverage this foundation model for signal generation across 100 coins with automated Binance futures execution.
Design Constraint
The GCP VM has only 7.8 GB RAM — the TimesFM model consumes ~2.4 GB. The bot must load the model once at startup and share it across all scan jobs. No concurrent model instances are possible.
Coins Tracked
100
across 4 tiers
Signal Freq
Hourly
fires at HH:01
Backtest AUC
0.896
precision 0.880
Context
192
bars per inference
02 Chapter 2
TimesFM 2.5 Foundation Model with LoRA Fine-Tuning
The system is built on Google TimesFM 2.5 200M — a decoder-only transformer pre-trained on diverse time-series data. Rather than training from scratch, the foundation model is fine-tuned on crypto OHLCV data using LoRA adapters, achieving strong out-of-sample performance with minimal compute.
End-to-End Signal Flow
Tiered Trading Strategy
| Tier | Coins | Allocation | Threshold | Character |
|---|---|---|---|---|
| T1 — High Conviction | 10 | $120/trade | 0.57% | Top-tier liquidity, lowest threshold |
| T2 — Broad Net | 15 | $100/trade | 0.75% | Mid-cap, moderate confidence |
| T3 — Momentum | 25 | $20/trade | 1.33% | Small-cap, high threshold filter |
| T4 — Patience | 31 | $13/trade | 1.50% | Lowest allocation, strictest filter |
Position Lifecycle
Grid Entry (40/35/25%) → Partial Fills → Full Position → Profit Monitor (every 5 min: trailing stop tracking) → Reconcile (every hour: check SL/TP hits on exchange) → EOD Close (MAX_HOLD_H=4h, force market close) → Exit recorded (bot.positions, PnL calculated)
Risk Management
Trailing SL
0.5%
arm + trail
Take Profit
4.5%
limit exit
Max Hold
4h
EOD force close
Regime Filter
BTC
SuperTrend gate
03 Chapter 3
Four-Subsystem Architecture
The platform is organized into four major subsystems, each responsible for a distinct concern — from core trading logic to model training to operational monitoring.
Repository Layout
s4_bot/ Main bot — 4 variants (T1-high, T1-broad, T2, PAXG) config/ All variant configs (coins, filters, SL/TP, leverage) core/ Signal logic, position management, trailing stops data/ OHLCV fetching (ThreadPoolExecutor, 20 workers) db/ Postgres state: positions, account, daily_log jobs/ APScheduler tasks: scan, reconcile, eod_close scripts/ Operational: deploy_restart.sh, run_loop dashboard/ Flask + Cloud Run — portfolio view, metrics, reports hourly_timesfm/ Training: finetune.py, predict.py, evaluate.py timesfm_repo/ Google TimesFM model source + adapters
Component A — s4_bot/ Core Trading Bot
The production trading engine. Contains config (settings, variant configs), core (signal logic, position management), data (OHLCV fetching, 20 parallel workers), db (Postgres state management), deploy (restart scripts), jobs (APScheduler tasks), scripts (operational utilities), and utils (Binance SDK wrappers). Entry point: main.py fires hourly at HH:01.
Component B — dashboard/ Flask + Cloud Run
Monitoring web application deployed on Cloud Run. Flask backend with app.py, configs.py, db.py for Postgres connectivity, metrics.py for performance calculations, report.py for daily/weekly PDF generation, and email_sender.py for automated report distribution. Served with Docker containerization.
Component C — hourly_timesfm/ Training Pipeline
Model fine-tuning and evaluation pipeline. Includes finetune.py (LoRA adapter training), predict.py (batch inference), evaluate.py (backtest metrics), config.py (hyperparameters), dataset.py (data loading), lora_layers.py (adapter architecture), and multiple backtest variants for parameter sweeping.
Component D — timesfm_repo/ Model Integration
Fork of Google Research TimesFM repository. Contains the model source (src/), v1 compatibility layer, and project scaffolding (pyproject.toml). Provides the base TimesFM model that the hourly_timesfm pipeline fine-tunes with crypto-specific LoRA adapters.
04 Chapter 4
Hybrid GCP VM + Cloud Run Deployment
The system uses a hybrid deployment model: the trading bot runs on a GCP VM (for persistent process and low-latency exchange connectivity), while the monitoring dashboard is containerized and deployed to Cloud Run (for scalability and zero-ops serving).
GitHub Actions Workflow (deploy.yml)
VM — Bot Execution (GCP Compute Engine)
Host: openclaw-bot. 7.8 GB RAM, CPU-only. Python 3.11, APScheduler for job orchestration. Bot process runs continuously, model loaded once at startup (~2.4 GB). Deploy via SSH + appleboy/ssh-action.
Cloud Run — Monitoring Dashboard
Docker image built from dashboard/Dockerfile. Auto-scaling, HTTPS. Cloud Scheduler triggers daily reports at 02:30 UTC and weekly reports on Monday 02:30 UTC. Zero-ops serving with gcloud deploy.
Deployment Pattern
Bot deploys use SSH to pull latest code and run deploy_restart.sh, which gracefully stops the current process and restarts with the new code. This preserves the model in memory during the brief restart window, minimizing downtime to under 30 seconds.
05 Chapter 5
Flask Dashboard with Automated PDF Reports
The Flask-based dashboard provides real-time visibility into bot performance, portfolio allocation, and trade history. Deployed on Cloud Run with automated report generation.
Coins Tracked
100
4 tiers, daily scans
Reports
Daily
+ weekly summary
Automation
24/7
Cloud Scheduler
| Module | File | Responsibility |
|---|---|---|
| Application | app.py | Flask routes, API endpoints, template rendering |
| Configuration | configs.py | Environment variables, Cloud Run settings |
| Database | db.py | Postgres connection pool, query helpers |
| Metrics | metrics.py | PnL calculations, Sharpe ratio, drawdown analysis |
| Reports | report.py | Daily/weekly PDF generation, HTML formatting |
| Notifications | email_sender.py | Automated report distribution via email |
Database Schema (Postgres — cp_ai)
bot.account — per-algo equity, allocation, daily PnL bot.positions — all trades (OPEN/CLOSED), entry/exit, PnL bot.daily_log — cumulative PnL per day per algo bot.pending_entries — grid entry tranches (t1/t2/t3) bot.bot_events — START/STOP/CRASH lifecycle events
06 Chapter 6
Technology Stack
A Python-native stack optimized for ML inference, exchange connectivity, and operational reliability.
Key Technical Decisions
MODEL — TimesFM 2.5 200M: Foundation model pre-trained on 100B time points. Fine-tuned with LoRA adapters on crypto OHLCV data. Context length of 192 bars provides sufficient temporal context for hourly predictions. Checkpoint size: ~500 MB.
EXCHANGE — Binance SDK (Native): Using official binance-sdk-derivatives-trading-usds-futures (v7.1.1) — NOT ccxt. Direct futures API access for grid orders, trailing stops, and position management. Taker fee: 0.05%, maker: 0.02%.
SCHEDULING — APScheduler: BlockingScheduler for main bot loop (hourly scans), BackgroundScheduler for 5-minute profit monitoring. Runs as persistent process on VM — no serverless cold starts affecting latency.
DATA FETCHING — ThreadPoolExecutor (20 workers): Parallel OHLCV fetching across all 100 coins. Sequential TimesFM inference (GPU/CPU bound). This hybrid approach maximizes throughput while respecting model memory constraints.
| Algo ID | Strategy | Status |
|---|---|---|
| s4_hourly | Main S4 bot — 4-tier hourly signals | LIVE |
| fm_sniper | High-conviction, tight stops | LIVE |
| fm_broadnet | Wide net, relaxed thresholds | LIVE |
| fm_patience | High threshold, low frequency | LIVE |
| fm_momentum | Trend-following confirmation | LIVE |
| fm_conviction | Maximum confidence filter | LIVE |
Performance Metrics
Backtest results: AUC = 0.896, Precision = 0.880, F1 = 0.839, optimal threshold = 0.0249. The model demonstrates strong discriminative ability between profitable and non-profitable trades across all four tiers.