A cryptocurrency trading bot specification: a completed example
A completed educational crypto bot specification: closed candles, entry and exit rules, position sizing, data errors, and three acceptance scenarios before backtesting.
“Buy after a breakout and exit on a reversal” sounds clear until two developers turn that sentence into two different bots. One buys during the candle; the other waits for it to close. One enters again; the other keeps a single position. A specification for a cryptocurrency trading bot needs to resolve these differences in advance.
Below is a completed educational example. You can give it to a developer as a starting point for discussion: the rules, implementation boundaries, and three acceptance scenarios are already linked.
What to include in a trading bot specification
Start with the decision point. What data is already known at that moment? At what price does the model allow an order to execute? What happens if the same candle is received again?
| Ambiguous wording | Testable rule for this example |
|---|---|
| Buy on a breakout | After an hourly candle closes, its Close is strictly above the previous candle’s High |
| Enter with a small amount | One purchase for 100 USDT without leverage, provided the available balance is sufficient |
| Exit on a reversal | After a candle closes, its Close is strictly below the previous candle’s Low |
| Avoid extra positions | At most one position; receiving a candle again does not create another order |
“Above” and “below” mean strict comparisons here. Equality does not generate a signal. Even this detail must be written down; otherwise, the differences will only emerge when you compare trades.
A completed contract: one position on an hourly chart
Purpose. Version 1 describes a research prototype with no connection to a live account. Market: Binance Spot; symbol: BTCUSDT; timeframe: 1h. The model includes no short positions, leverage, averaging into positions, or manual trades.
Data. Use closed OHLCV candles with opening timestamps in UTC. Each decision requires two consecutive hourly candles. If an hour is missing or the same timestamp has conflicting values, the test stops with a data error. An entirely identical duplicate is ignored. No trades are allowed on the first available candle.
Entry. If there is no position or pending order and the Close of the current closed candle is strictly greater than the previous candle’s High, create one buy order. In this educational model, it executes at the next candle’s open. The purchase amount is 100 USDT; the BTC quantity is 100 divided by the execution price. Insufficient available funds cancel that signal; it is not carried forward to the next hour.
Exit. If a position is open and the Close of the current closed candle is strictly less than the previous candle’s Low, create an order to sell the entire BTC quantity. Execution also takes place at the next candle’s open. After an exit, a new entry is allowed only on a signal from the next candle close. If there is no exit signal, the position remains open. This example has no built-in stop-loss.
Event order. First, execute any pending order at the hour’s open; then evaluate the new candle at its close. Process each timestamp once. If there is no next candle, the order remains unfilled and is included in the report. A position still open at the end of the test is shown separately, without inventing a sale.
Simplifications. The model starts with a balance of 1,000 USDT. Fees and slippage are zero, and quantities are not rounded. These assumptions are only for checking the logic. This calculation must not be used to assess returns.
A live exchange adapter will require a separate specification appendix covering current order quantity and notional limits, fees, partial fills, cancellation, and recovery after a lost connection. For example, Binance Spot filters define LOT_SIZE, MARKET_LOT_SIZE, and MIN_NOTIONAL constraints. Values from the educational prototype cannot automatically be carried over to the exchange.
Three acceptance scenarios before a long backtest
All prices below are invented for testing the code. They are not BTC quotes or strategy results.
1. Breakout with delayed execution. There is no position, and 1,000 USDT is available. The previous candle’s High is 100; the current candle closes at 101. The next candle opens at 102. Expect one purchase for 100 USDT at 102, with a quantity of 100/102 BTC. The report must not contain a trade at 101.
2. Equality and repeated delivery. In a separate test, the previous candle’s High is 100 and the current Close is also 100. There is no entry. Then deliver the candle from the first scenario again with the same timestamp and OHLCV values: there must be no second order or second purchase.
3. Exiting a position. In a separate test, a position of 0.5 BTC is already open. The previous candle’s Low is 98, the current Close is 97, and the next open is 96. Expect a sale of exactly 0.5 BTC at 96, proceeds of 48 USDT before costs, and a zero position. There is no purchase at that same open.
The acceptance log needs the input candles, position state before the decision, signal condition, order time, and execution time. This lets the client see why each trade happened without reading all the code.
What to give the developer alongside the rules
Save this contract as a separate document with a version number and replace the educational conditions with your own. Ask the developer to return the results of the three scenarios first. If interpretations differ, correct the rules before tuning parameters or running long tests.
Once the logic has been checked, you can move on to researching a strategy on historical data in XTester. The roles of the tools are described in the EasyTrading ecosystem: the portal helps you choose a stage of work, but is not itself a trading bot builder. Assessing the quality of a result is covered separately in why a profitable backtest may fail in live trading.
This educational contract checks whether the rules are unambiguous. It is not investment advice, does not establish that a strategy is safe, and does not guarantee returns; live trading can lead to loss of funds.