An algorithm is a set of instructions, not a source of returns
Crypto algorithmic trading uses explicit rules or models to choose, size and execute trades. The code might rebalance a portfolio weekly, follow a trend, quote both sides of a market or trade a gap between related instruments. Automation makes those decisions repeatable. It does not make the trading idea profitable.
Here, “algorithmic” refers to the trading process, not an algorithmic stablecoin or a token whose protocol adjusts supply. AI is optional. A weekly rebalance rule is an algorithm; a machine-learning model is simply one possible source of a signal.
The strategy says which exposure it wants and why. The surrounding automated trading system supplies validated data, risk controls, order management, reconciliation and recovery. Good research inside an unreliable system still produces bad trades.
From an idea to a reconciled fill
Each pass should leave a usable record: data version, feature values, strategy parameters, target position, risk decision, intended order, actual fill and cost. Without that trail, the result may be visible but cannot be explained or reproduced.
Write down what would prove the idea wrong
“Bitcoin goes up” is an opinion, not a research specification. A testable idea names the market, observable condition, action, time horizon and reason the behavior might persist. It also says which result would make you abandon the idea rather than tune it again.
| Weak statement | Research-ready version |
|---|---|
| Buy when momentum is strong. | Define the return window, threshold, rebalance time, asset universe, holding period and exit rule before testing. |
| Trade exchange price differences. | Specify venues, transfer and settlement constraints, simultaneous execution rules, inventory requirements and minimum net spread. |
| Use AI to predict crypto. | Name the model output, forecast horizon, benchmark, retraining schedule, uncertainty threshold and permitted position response. |
| Market make profitable pairs. | Define quote width, inventory skew, cancellation policy, queue assumptions, fee tier and adverse-selection measure. |
Writing this down first limits hindsight. If every loss sends the researcher back for a new indicator, friendlier asset list or better date range, the process is selecting noise rather than testing an idea.
Crypto data arrives on more than one clock
A point-in-time dataset contains only what was available when the decision happened. Downloading today’s historical candles does not guarantee that. Symbols change, tokens list and delist, contract specifications are revised, funding settles on venue clocks and on-chain events become usable at different confirmation depths.
| Data layer | What to preserve | Common research error |
|---|---|---|
| Trades and quotes | Venue, instrument, event time, receipt time, price, size and side convention | Combining venues as if one executable market existed. |
| Order book | Snapshots, incremental updates, sequence and depth | Using the best quote for more size than was available there. |
| Instrument metadata | Tick, lot, contract size, collateral, settlement, listing and delisting time | Applying current specifications to older trades. |
| Derivatives state | Index, mark, funding, open interest, margin tiers and expiry | Treating last trade as the price used for every risk event. |
| On-chain state | Block, transaction ordering, fee, confirmation policy and contract version | Using finalized state before it would have been known. |
| Account state | Balances, positions, orders, fills, fees, borrow and transfers | Assuming capital is instantly available at every venue. |
The asset list also has to exist point by point in time. Testing only tokens that survive today drops the failures and delistings that were eligible then. Save the selection rule and the data used to apply it on each date.
There is no single executable “crypto price”
Digital assets trade continuously across centralized exchanges, decentralized protocols and derivatives venues. Price, liquidity, custody, settlement and access differ among them. Makarov and Schoar document how price discovery and segmentation vary across exchanges and time. The model therefore needs the venue the account can actually trade, not only a synthetic global price.
On a centralized limit order book, the best bid and ask represent only displayed prices and quantities. Coinbase Exchange, for example, documents price-time priority: orders at better prices execute first, and earlier orders have priority at the same price. That means a passive order touching the best price does not automatically fill. It may sit behind existing size while the market moves away.
| Market feature | Research implication | Execution implication |
|---|---|---|
| Fragmented venues | A reference price may not be executable on the selected account. | Capital, limits and inventory must already be available where the order is placed. |
| 24/7 trading | Day boundaries and maintenance windows must be defined explicitly. | Monitoring and recovery cannot assume a universal market close. |
| Uneven depth | Capacity changes by asset, venue, time and volatility. | Order size can move through several book levels. |
| Maker/taker pricing | Cost depends on whether an order rests or executes immediately. | A partially marketable limit order may incur both treatments. |
| Venue-specific rules | Ticks, lots, fees and order behavior need versioned metadata. | The adapter must round and validate before submission. |
| On-chain execution | Block inclusion, gas and state changes enter the cost model. | Pending transactions face reordering, replacement, reversion and contract risk. |
Spot and derivatives need separate assumptions
| Dimension | Spot | Perpetual or dated derivative |
|---|---|---|
| Exposure | Ownership or sale of the asset, with borrowing if used | Contract notional that can be long or short |
| Capital | Cash and asset inventory | Collateral and margin rules |
| Recurring cost | Trading, custody and possible borrow cost | Trading cost plus funding or basis and margin effects |
| Reference prices | Order book and trades on the spot venue | Last, index, mark and settlement prices may serve different purposes |
| Tail failure | Illiquidity, custody or borrow recall | Liquidation, funding reversal, basis change or expiry handling |
One return series and one cost model cannot represent both. The futures trading bot guide covers margin and liquidation; funding-rate arbitrage covers hedged carry and its remaining basis, execution and venue risks.
The main strategy families—and what usually breaks
| Family | Core hypothesis | Dominant implementation risk |
|---|---|---|
| Scheduled accumulation or rebalancing | A time or allocation policy is preferable to discretionary timing. | Liquidity, concentration and rebalancing cost. |
| Trend and momentum | Price movement persists longer than the strategy's reaction and trading cost. | Whipsaw, crowded exits and regime reversal. |
| Mean reversion | A measured displacement tends to normalize over the chosen horizon. | A structural break turns temporary divergence into a persistent move. |
| Market making | Spread capture exceeds adverse selection, inventory and operating cost. | Fills arrive before unfavorable price movement and inventory accumulates. |
| Cross-market arbitrage | Linked prices converge after every execution, transfer and funding cost. | One leg fails, capital cannot move or the apparent spread is not executable. |
| Basis and carry | Funding or convergence exceeds hedge, margin and venue costs. | Funding reverses, basis widens or a leveraged leg liquidates. |
| Short-horizon scalping | Order flow or microstructure predicts a move larger than immediate costs. | Latency, queue position, noise and overtrading. |
| Cross-sectional portfolio | Relative features rank assets with repeatable differences in future return or risk. | Survivorship bias, turnover, concentration and changing correlations. |
The trend-following guide, arbitrage-bot guide and AI scalping guide cover the mechanics and tests specific to those families in more detail.
Do the cost arithmetic before choosing a fancy model
Gross return is the captured price move before implementation. Net return subtracts what it cost to enter, hold and leave the position. The terms change by strategy, but this is a useful starting point:
Net return = benchmark-price return − execution shortfall − fees − financing/carry where applicable − failed-execution loss Execution shortfall is the difference between decision-time benchmark prices and actual fills. Measured that way, it captures bid–ask spread, market movement during delay and size impact once rather than listing three overlapping deductions. Financing, borrow and funding belong in the equation only when the position and holding period actually incur them.
Maker and taker fees can differ and may depend on an account's current volume tier. Coinbase Advanced, for example, documents separate maker and taker treatment and notes that an immediately filled part of an order can be charged differently from the portion that rests. Check current terms for the actual venue and account rather than copying a fee table into a permanent backtest.
A worked $25,000 net-return example
Suppose a fully funded, unlevered spot strategy expects a 70 bp benchmark-price move on $25,000 of notional over one holding interval. Its hypothetical fills produce 16 bp of round-trip execution shortfall, fees are 12 bp on each side, and partial or failed execution carries an estimated 5 bp cost. No borrow, funding or financing charge applies to this example.
| Component | Basis points | Dollar effect |
|---|---|---|
| Gross strategy move | +70 bp | +$175.00 |
| Round-trip execution shortfall | −16 bp | −$40.00 |
| Entry and exit fees | −24 bp | −$60.00 |
| Expected execution loss | −5 bp | −$12.50 |
| Illustrative net result | +25 bp | +$62.50 |
These are hypothetical numbers, not current costs from a named venue. They show the sensitivity: another 25 bp of execution shortfall erases the estimate. If normal uncertainty in the cost model is as large as the expected edge, gross returns cannot tell you much.
Build a backtest another person could challenge
- Freeze the specification. Record the hypothesis, universe, features, horizon, sizing, benchmark, costs and rejection criteria before the final test.
- Version raw data. Preserve source, timestamps, metadata and transformations so the dataset can be reproduced.
- Enforce event order. Make features available only after the source event could have reached the strategy.
- Use a point-in-time universe. Include delistings and historical eligibility rather than today's survivors alone.
- Model executable fills. Use bid, ask and depth appropriate to size; include queue and gas assumptions where relevant.
- Deduct every cost. Apply the fee tier, spread, slippage, funding, borrow, impact and failure treatment that the live design would face.
- Separate development and test periods. Tune on earlier data, evaluate once on later untouched data and continue with walk-forward observation.
- Stress assumptions. Widen spreads, delay orders, reduce fills, raise fees, reverse funding and remove the best-performing assets.
- Compare with a benchmark. Measure whether complexity improves net risk-adjusted results over a simpler allocation or no-trade rule.
The SEC has brought an enforcement action over hypothetical backtested advertising in which the test and live strategy used materially different instruments. The case involved a registered investment adviser, but the broader lesson is straightforward: state the differences between simulation and live implementation instead of presenting them as one record. See backtests versus live results for a dedicated treatment.
Eight ways a backtest manufactures an edge
| Error | How it enters | Preventive test |
|---|---|---|
| Look-ahead bias | Using a close, index value or on-chain state before it was observable. | Delay every feature to its real availability timestamp. |
| Survivorship bias | Testing only assets and venues that remain available today. | Reconstruct historical eligibility, delistings and failures. |
| Selection bias | Reporting the best result after many unreported trials. | Track all experiments and reserve an untouched final period. |
| Impossible fills | Buying at a candle low, selling at a high or filling unlimited size at one quote. | Replay executable book state with latency and partial fills. |
| Cost omission | Ignoring one side of fees, funding, gas, borrow or failed orders. | Reconcile simulated costs to sample venue statements or fills. |
| Capital teleportation | Using the same funds simultaneously across fragmented venues. | Maintain separate balances, transfers and settlement delays. |
| Parameter instability | One narrow setting works while adjacent values fail. | Map a parameter neighborhood and test later regimes. |
| Capacity blindness | Assuming returns remain constant as size increases. | Recalculate fills and impact across several order sizes. |
A win rate can hide the entire risk profile
A strategy can win 70% of its trades and still lose money when the other 30% are larger. A high return may come from hidden leverage or one exceptional month. Read economic performance, execution quality and operating reliability separately.
- Return: net profit, benchmark-relative return and distribution by trade and period.
- Risk: drawdown, volatility, downside tail, leverage, concentration and liquidation distance.
- Stability: results by asset, venue, volatility, direction, liquidity and later unseen period.
- Execution: fill ratio, partial fills, slippage, spread paid, maker/taker mix and post-fill markout.
- Capacity: net result as notional rises and available depth is consumed.
- Operations: rejects, timeouts, stale-data events, reconciliation breaks, downtime and recovery time.
Earn the right to increase size
Move forward only after written thresholds are met, not because a few days were profitable. Check that invalid orders are rejected, a restart rediscovers existing exposure, partial fills update positions and the independent stop works. The account should stay inside its limits even when the signal, feed or venue fails.
What to ask a strategy provider
- Identify the exact product. Is it software, signals, copy trading, a managed account, a fund or a venue feature?
- Read the strategy specification. Look for universe, venue, horizon, leverage, entry, exit, sizing and conditions for no trade.
- Separate evidence types. Label hypothetical backtest, paper, shadow and live results with dates and capital.
- Recalculate net return. Include fees, spread, slippage, funding, borrow, impact, downtime and subscription cost.
- Inspect custody and permissions. Determine who holds assets, whether API credentials can transfer value and how access is revoked.
- Ask about bad periods. Review maximum drawdown, worst trades, outages, delistings and markets in which the strategy should be disabled.
- Review controls. Confirm maximum exposure, loss limits, price collars, stale-data handling, reconciliation and a kill switch.
- Reject guarantees. The CFTC warns that AI cannot predict sudden market changes and highlights the effect of fees, spreads and subscription costs.
Practical questions about algorithmic crypto trading
Do crypto trading algorithms need AI?
No. Scheduled rebalancing, execution schedules, trend rules and spread thresholds can be fully algorithmic without machine learning. Use AI only when it adds measurable value over a simpler benchmark after cost and operational complexity.
Can a profitable backtest be trusted?
Reproducible data, code and assumptions can make a backtest useful support for a hypothesis, but never proof of future or live performance. The result becomes more credible when it survives later untouched periods, conservative costs, shadow operation and limited live observation.
What programming language is best for algorithmic crypto trading?
The best choice depends on latency, libraries, team skill and operational requirements. Research code and production execution do not have to use the same language, but calculations, rounding and strategy behavior must match across implementations and be covered by shared test cases.
How much capital does an algorithm need?
There is no universal minimum. Capital must cover venue minimums, diversified risk, fees and stressed loss without relying on leverage to make a tiny expected edge visible. Test capacity in both directions: an account can be too small for costs and too large for available liquidity.
Does 24/7 crypto trading make automation necessary?
It makes continuous monitoring valuable, but it does not justify unattended risk. A system can restrict trading windows, enter no-new-risk mode or require operator coverage. Safe automation is preferable to constant activity.
Research, rules and enforcement references
- Coinbase Developer Documentation — Exchange matching engine and price-time priority
- Coinbase Help — Maker, taker and partially matched order fees
- Makarov and Schoar — Price Discovery in Cryptocurrency Markets
- IOSCO — Policy Recommendations for Crypto and Digital Asset Markets
- SEC — Backtested-performance compliance and records action
- CFTC — AI won't turn trading bots into money machines
- Onchain Off Emotion — Risk disclosure
The worked calculation uses hypothetical costs and does not promise that any strategy is profitable. Market, product, tax and regulatory requirements change by venue and location; check the current rules for the exact account rather than treating this guide as a trade recommendation.