An autonomous Bitcoin trading robot for Indonesian rupiah (BTC/IDR), designed so that a person who is not a trader can trust it, supervise it from a phone, and stop it in one tap. The strategy is deliberately plain. The product is the safety, the explanations and the operations around it.
Internal tool, not for sale. ZeusTrading trades only the founder's own account. It is not offered as a product, signal or fund-management service, and nothing here is an invitation to invest.
Alat internal, tidak dijual. ZeusTrading hanya memperdagangkan akun pribadi pendiri. Bukan produk, jasa sinyal, atau jasa pengelolaan dana, dan halaman ini bukan ajakan berinvestasi.
Past results are not a guarantee of future results. Backtest figures use 0.2% exchange fee per side, 0.05% slippage per side and 0.21% sales tax.
* Buy-and-hold from the very first data day (before the rule could act) would be +80%; we show the stricter comparison.
Automated crypto trading usually fails for human reasons: too much risk, overfitted strategies, no one watching, and reports only the builder can read. I wanted the opposite. The owner (me) is not a trader, will not stare at charts, and must still be able to answer three questions at any time: is it running, is my money safe, and can I stop it?
Twelve decisions shaped the product. Each one answers a specific way the system could hurt the owner or mislead them.
Daily and weekly reports read like a note from a colleague. Jargon such as moving averages, long, flat and drawdown is banned from owner-facing text, and this is written into the rules every change must follow.
The dashboard accepts only the owner's device passkey (WebAuthn). There are no passwords. It adds a one-time recovery code, a lockout after repeated failures, and an alert on every new login.
The owner can only reduce risk from the phone. STOP halts the robot; resuming requires physical access to the server. If the cloud layer dies, the robot keeps its own loss limit.
Escalating push alerts when the real-money value falls 10%, 15% and 20%, before a hard stop ends trading at the loss limit. Also alerts for held trades, stale data, a silent robot and real-vs-simulation mismatch.
Before any real order: daily data must be fresh, the live price must be near the last close, and the exchange balance must cover the robot's own ledger. A failed check means no trade and a retry next hour. Orders are never auto-repeated, so a double buy cannot happen.
A simulated twin takes the same decisions on practice money. If the real robot ever decides differently from the simulation, the owner is alerted. The twin is the system's conscience.
A home server is primary and a cloud server is standby. Only the holder of a single "baton" may trade; the standby takes over only after the primary has been silent for three hours. If the baton service is unreachable, nobody trades: better a day late than running twice.
After each daily decision the baton holder uploads the robot's ledger and journal off-site. A server taking over restores them first. If the records lag the real balance, the real-money robot holds back and warns.
On the 1st of each month the owner receives a PDF: real and simulated profit or loss, every trade, the 0.21% tax per sale, and the audit result. Built with a small PDF writer that needs no third-party library.
Every quarter the current rule is re-tested against its five nearest neighbours, with full costs, over all data, each half, and the last 12 months. The review only advises. Nothing changes automatically.
An AI analyst writes market context and risk warnings but never decides or trades, because language models can be confidently wrong with numbers. Thirty days later its warnings are graded against what the price actually did, versus the chance baseline.
Adding or removing capital from the dashboard needs a fresh passkey confirmation, not just an open session. Requests have per-request limits, a unique id so none is applied twice, and are refused while the robot is stopped.
Two machines can run the robot, but a single lease held in the cloud decides which one may act. The cloud layer also hosts the owner dashboard, authentication, the STOP and capital queues, alerting, and the off-site backup.
Check STOP flag → confirm baton → fetch data → decide once after the morning cut-off → sanity checks → trade or hold → write plain-language journal line → email report → push snapshot → back up records off-site. A failed data fetch leaves no "done" marker, so the job retries the next hour.
Code changes cannot enable real money, add leverage, short, or raise trading frequency without written owner approval. Every strategy change must pass the automated tests and a full-cost backtest.
I treated the strategy as a hypothesis to be falsified. The aim was to find the simplest rule that survives scrutiny, and to resist every tweak that merely looked better on past data.
Second asset, same discipline. Applied to Ethereum, the rule beat buy-and-hold (+123% vs +6%) but with a deeper worst fall (−57%) and strong sensitivity to its settings. A 50/50 Bitcoin and Ethereum mix was weaker than Bitcoin alone because the two move together. Ethereum therefore runs on practice money only; real money requires at least six months of simulation, a hard cap, and my written approval.
Source: internal research notes of 19 October 2026. Buy-and-hold is measured from the first day the rule could act; from the very first data day it would be +80%. Charts are drawn from the stated figures; bar lengths are proportional within each chart. The walk-forward figure (+193%) is an upper bound, not a promise: the setting was chosen with knowledge of all data, so it is slightly flattering.
The signal is a commodity. Trust comes from what happens when data is stale, a server dies, or a number looks wrong.
Stopping is one tap; adding risk needs Face ID and limits. Make the safe action easy and the risky one deliberate.
When unsure, do nothing and say so. A day late is acceptable; running twice is not.
I report the flattering figure as an upper bound and make every change survive unseen data. Most "improvements" were noise.
The AI analyst informs but never decides, and is graded against outcomes. Usefulness is measured, not assumed.
A pre-commitment document lists what may and may not justify changing the strategy, written when nothing is at stake.
If the owner cannot read the report, the system is not done. It is a requirement, tested like any other.
My leverage is precise constraints, acceptance tests, written approval gates and review of evidence.
Next: keep the twelve-month forward test running, review the rule each quarter, and consider Ethereum with real money only after six months of simulation and written approval, at a small cap.