First-hand · verified against the real thing
Building the paper-trading bot: SQLite, Telegram, and why it never goes live
In one line: A paper-trading bot is where a validated strategy meets boring reality: scheduling, state, alerts, and an audit trail. How QuantLab's bot works — and why the project keeps it on paper forever.
After the research machinery says a strategy survives validation, the last honest gate is a machine that pretends to trade it, forever, with real data and no money. QuantLab's is a deliberately small piece of Python: demo_bot.py, SQLite, and Telegram alerts. It has never placed a live trade, by policy, and this piece is about both halves of that sentence — what building it teaches, and why “never live” is a design decision rather than a temporary caution.
The shape of the thing
The bot runs hourly scans against the lab's frozen configuration (held in a versioned bot_config.yaml, not in code — the config the freeze locked, read by the bot, never tuned by it). It keeps its state in SQLite: positions, fills it would have gotten, equity history. One-shot modes make it operable and auditable — scan now, show status, print a performance report — and every signal it acts on goes to Telegram, which doubles as the lab's heartbeat: a silent bot is a broken bot, and the alert log is the audit trail. No framework, no queue, no container orchestration. A research bot's job is to be understandable in a year, not impressive in a demo.
What building it teaches that backtesting can't
State is harder than strategy. The simulation assumes you know your position; the bot has to actually keep it — through restarts, partial signals, data outages and timezone bugs (a timestamp-fixing utility exists in the repo for exactly the class of bug it caused). Data pipelines break in ways caches don't: the live feed and the cached research data disagree in format, gap policy and timing, and the bot is where those disagreements surface. Operational honesty: a backtest silently interpolates; a bot must decide what to do when a candle is missing at 3am, and that decision is engineering, not research.
Why paper forever, stated plainly
Because the bot's purpose is verification, not income. It exists to measure the gap between the simulation and executable reality — fills, latency, data breaks — at zero financial risk, and it does that job completely without ever wiring itself to an exchange order endpoint. Going live adds a new failure class (real money, real emotions, real exchange risk) while answering a question the research journal has usually already answered by then: most candidate strategies died in the validation gauntlet long before the bot stage, and the ones that reached it were being tested, not trusted. The repo's own documentation marks the bot “NEVER live”; that is not timidity, it is scope.
The bot is also the project's most honest instructor about how simulations differ from reality — and a good companion piece to the honest guide to learning Python free for anyone who wants to build small, real tools before ambitious ones.
Research note: QuantLab experiments are presented for educational and research purposes. Historical backtests and simulations do not guarantee future results and should not be interpreted as investment advice.
Sources
Next