@dhairya_09

Devlog 01 — Building a Systematic Trading Bot

June 13, 2026
The why
I’ve always been interested in markets but what drew me to algorithmic trading specifically was the idea that you could remove emotion from the equation entirely and replace it with a testable, falsifiable system. Either the edge exists in the data or it doesn’t.
What I built
The bot runs on Freqtrade, an open source crypto trading framework, on Binance USDT-M futures. Everything is Dockerised and runs locally on my laptop. The core strategy is a mean-reversion long that enters dip positions in altcoins when BTC is in a confirmed uptrend, using RSI, Bollinger Bands, and an ADX regime filter to avoid trading in choppy conditions.
The research process was more rigorous than I expected going in. Every strategy candidate goes through a multi-gate evaluation: full history backtest, out-of-sample holdout, walk-forward validation across multiple windows, per-pair concentration checks, and a fee sensitivity re-run at double the maker rate. Anything that fails a gate gets documented and dropped, not iterated on endlessly.
What the numbers look like
The current live system backtests at around 715% over 5 years across 39 pairs, with out-of-sample results of roughly 188% CAGR over the most recent 23 months. A Monte Carlo bootstrap of the out-of-sample trade history gives a median 1-year CAGR around 79% with a 2% chance of a losing year. The bot is currently in dry-run, meaning it trades with paper money to validate that live behaviour matches backtest expectations before any real capital goes in.
What I learned
The biggest lesson was around leverage semantics. Early in the project I discovered that Freqtrade applies stoploss and ROI values to the leveraged profit ratio, not the price move. A stoploss of -7% at 5x leverage is actually a -1.4% price move. Every stop in the original version of the bot was sized wrong because of this. Catching it and rebuilding the risk model from scratch was the most important thing I did on this project.
The second lesson was that hyperopt, the built-in parameter optimisation tool, actively makes things worse if used before you have a real edge. I ran a 150-epoch optimisation that produced a strategy 4x worse out-of-sample than the hand-tuned defaults. Now I only run it after a candidate passes all evaluation gates on its original parameters.
What’s next
Observing the dry-run for 4 to 6 weeks and comparing live trade distribution against backtest expectations before considering real capital. Also researching a funding-rate carry strategy as a second uncorrelated bot.

Devlog 01 — Why Argus Exists

June 13, 2026
The why
My dad works in facilities and industrial management in Dubai. I’ve seen firsthand what inspection looks like in practice: engineers going into spaces that are genuinely unpleasant and sometimes dangerous, in a city where summer temperatures outside regularly hit 45C and inside certain industrial environments can be worse. The job is slow, manual, and puts people in places they shouldn’t need to be in just to check whether something is working or not.
It got more concrete when I did internships at two UAE companies. At BEEAH, one of the UAE’s largest waste management and environmental services groups, I saw how large-scale industrial operations actually run on the ground. At Nissan’s UAE operations I got a closer look at manufacturing and engineering workflows. Both experiences made the same thing clear: a huge amount of human time goes into tasks that are repetitive, physically demanding, and in some cases genuinely risky, specifically because there’s nothing autonomous doing them instead.
That’s the problem Argus is built to solve. An autonomous rover that navigates a facility, reads thermal signatures, detects anomalies, and generates a report, without a human entering the space. BEEAH is the first target client. I’ve already had conversations with them and with MBRIF about deployment. This isn’t a school project with a real-world framing bolted on. The real-world deployment is the point.
Where I’m starting from
I’m not starting from zero on electronics. Over the past few weeks I’ve been building up the fundamentals before touching the rover hardware.
I worked through two soldering kits. The first was a spring electromagnetic swing kit with LED, a simple but satisfying build that got me comfortable with through-hole components, iron temperature control, and reading a basic schematic. The second was a more involved obstacle avoidance smart car kit with an ultrasonic ranging sensor, directly relevant to Argus given it uses similar distance-sensing logic. Both came out working first try.
From there I built my first fully independent project: a panning radar with a real-time laptop display using an ultrasonic sensor and Arduino. The sensor sweeps on a servo, pings distances at each angle, and the results render as a radar sweep on screen. First thing I built without a kit manual, and seeing the display populate in real time made the whole sensor-to-software pipeline click properly.
What’s arriving
Rover parts are 2-3 days out. Raspberry Pi 5 8GB with AI HAT+ 26 TOPS, four JGB37-520 200RPM motors, four BTS7960 motor drivers, MLX90640 thermal camera, Pi Camera Module 3, VL53L1X ToF sensors, environmental sensors, LiPo power system, and an IP67 enclosure. Chassis plate and extrusions are being laser cut externally.
What’s next
The moment parts arrive: unbox, photograph everything, and start with ESP32 and motor driver wiring. First milestone is all four motors spinning under manual control before touching anything else. Get the chassis moving first, add sensors one at a time.