Short answer: A crypto trading strategy is a written set of rules for what to trade, when to enter, how much to risk, when to exit and how performance will be reviewed. If a rule cannot be tested or followed consistently, it is not yet a strategy.
| Step | Decision | Required output |
|---|---|---|
| 1 | Goal, asset and timeframe | A narrow trading universe |
| 2 | Market hypothesis | A testable reason the setup may work |
| 3 | Entry and exit rules | Unambiguous if–then rules |
| 4 | Risk and position size | Maximum loss per trade |
| 5 | Backtest | Results after fees and slippage |
| 6 | Validation | Unseen-data and paper-trading checks |
| 7 | Monitoring | A journal and stop conditions |
1. Define the Goal, Asset and Timeframe
Start with one job for the strategy: trend following, mean reversion, breakout trading or risk reduction. Choose liquid assets and a timeframe you can actually monitor. A daily strategy and a five-minute strategy have different costs, data needs and emotional demands.
Write the scope in one sentence, for example: “This strategy tests daily BTC spot breakouts and holds for up to ten days.” This prevents the rules from expanding whenever a test performs poorly.
2. Write a Testable Market Hypothesis
A hypothesis explains why the rules might have an edge. “Buy when price goes up” is not enough. A testable version is: “A close above a 20-day high, confirmed by above-average volume, may capture persistent trends in liquid crypto markets.” The hypothesis can be wrong; the purpose of testing is to find out.
3. Turn the Idea Into Exact If–Then Rules
Define the data source, candle close, entry, exit and invalidation. Avoid discretionary words such as “strong,” “soon” or “looks bullish” unless you define them numerically.
- Universe: BTC/USD spot on a named exchange or aggregated price feed.
- Entry: buy only after the daily candle closes above the previous 20-day high and volume exceeds its 20-day average.
- Exit: close if price reaches the predefined stop, closes below the trailing rule or reaches the maximum holding period.
- No-trade filter: skip when liquidity is below the minimum or data is missing.
For indicator definitions, use the crypto technical-indicator guide. For examples of strategy families, see beginner crypto trading strategies.
4. Set Risk and Position Size Before Entry
Choose the maximum amount the portfolio may lose if the setup is invalidated. Position size should follow the distance between entry and stop, not confidence or excitement.
Illustrative formula: position size = maximum acceptable loss ÷ stop distance. If the risk budget is $10 and the stop is 5% below entry, the notional position is $200 before fees. This is an educational example, not a recommended allocation.
Do not add leverage merely to improve backtest returns. A CFTC customer advisory warns that leverage can amplify gains and losses in virtual-currency futures; it can also make small data or execution errors destructive. Use the position-size calculator guide and the risk-management framework before live testing.
5. Backtest With Fees, Slippage and Clean Data
A backtest should use rules exactly as written and avoid information that was unavailable at the time. Include trading fees, spread, slippage, funding where relevant and realistic order timing. Testing only a rising market can make a weak strategy look strong.
- Use enough trades to avoid judging the strategy from a few lucky outcomes.
- Separate the period used to design the rules from the period used to evaluate them.
- Test bull, bear, sideways and high-volatility regimes.
- Record missing candles, delistings and exchange-specific price differences.
The crypto backtesting guide explains common data-leakage and overfitting errors.
6. Validate on Unseen Data and Paper Trade
Keep part of the history out of the design process, then run the final rules once on that unseen period. If performance collapses, the strategy may be fitted to noise. Next, paper trade forward to check whether alerts, order timing and liquidity behave as expected.
Changing rules after every losing trade invalidates the test. Record a proposed change, wait for the scheduled review and test the new version separately.
7. Monitor Live Performance and Define Stop Conditions
A strategy is a monitored process, not a one-time backtest. Track results after fees, compare them with the test range and pause when data quality, execution or drawdown moves outside the written limits.
| Metric | What it answers | Common trap |
|---|---|---|
| Net return | Did the strategy gain after costs? | Ignoring fees |
| Maximum drawdown | How deep was the largest decline? | Looking only at final profit |
| Win rate | How often did trades win? | Assuming high win rate means low risk |
| Profit factor | How did gross wins compare with losses? | Using too few trades |
| Turnover | How often did the strategy trade? | Underestimating execution costs |
Worked Example: Daily BTC Spot Breakout
Suppose the rule enters after a daily close above the previous 20-day high with above-average volume. The stop is set from a predefined volatility rule, position size follows the maximum-loss formula and no leverage is used. The test includes fees and slippage, reserves the most recent data for validation and compares results across different market regimes.
This example is useful because every decision is observable. It does not claim that a breakout will be profitable. A valid test may show that the idea should be rejected.
Final Checklist Before Using Real Money
- The goal, market and timeframe are fixed.
- Entry, exit and no-trade rules are unambiguous.
- Position size follows a maximum-loss rule.
- Fees, spread and slippage are included.
- Unseen data and multiple market regimes are tested.
- Paper trading confirms that execution is practical.
- The journal includes review dates and stop conditions.
Forvest can support monitoring and analysis, but no model or tool guarantees profitable trades. The final decision and risk remain with the user.
Related reading: For a broader decision workflow, read candlestick reading resources and trading-alert types and validation.
