Show HN: I built a Bitcoin DCA bot – here's why
7 comments
This is excellent! Do you know where to find a free API to get options data for BTC?
Options data fore free you get directly from each exchange.
There are aggregators like "glassnode" but they charge you.
There are aggregators like "glassnode" but they charge you.
Thanks! Which exchange would you recommend for that?
Start with binance or kraken?
Pretty neat.
How would the multiplier DCA act during a multi-month "crypto winter"?
How would the multiplier DCA act during a multi-month "crypto winter"?
It would try to snipe the bottom, slowly scaling into bigger order sizes
Why I didn’t use existing tools: Most options I tried were either locked to one exchange or did fixed-amount DCA with naive execution. I wanted multi-exchange support and a way to scale buys during dips and preserve capital during rips. I also kept running into inconsistent API rate limits and small-order quirks, which made me prefer building.
Why turn it into a service: At first it was just JSON configs on my machine. More friends kept joining. I added a basic self-serve UI so I wasn’t SSH’ing to change params. Hosting costs stayed small, but my time did not. At that point it made sense to package it.
“multiplier DCA”: Instead of buying a fixed amount on a schedule, the bot computes a multiplier in the range 0.1–3× and scales the order size. During dips it buys more; during euphoria it scales back or skips. Inputs include standard indicators plus some AI and social context; guardrails cap the multiplier and enforce cool-downs so you don’t blow a week’s budget in the first leg of a dump. The goal isn’t to “time the bottom,” it’s to shift size a bit toward better prices without starving future buys.
Results so far (caveats included): On a public, static backtest over the last year, the multiplier approach accumulated ~30% more BTC than fixed DCA, with slightly higher total spend. Backtests aren’t reality; live trading taught me to add pacing and cool-downs.
Tech stack and latency: Watcher → queue → workers. Node.js services with AWS DynamoDB/Aurora for state, SQS for queues, Lambda workers for execution. Typical timings: ~20 ms to scan, ~10 ms to enqueue, ~100 ms–2 s for the trade depending on the exchange. We didn’t optimize for HFT; this is DCA, not microsecond arbitrage.
How long it took: The first script is ~6 years old. The multiplier engine grew out of a friend’s suggestion to size into dips. I iterated for years, added a UI this year, and opened it to more friends.
https://dca.bot
I’m here for feedback and AMA—architecture critiques, multiplier design, failure modes, exchange abstractions, whatever’s useful.