EvoTrade earned 0.41% in fifteen months when its authors ran v1.7.1 through TradingView, using the same window they had tuned it on.

The paper offers EvoTrade as a way to hand manual trading-rule design to a genetic algorithm. Its premise is familiar: technical indicators contain timing information, and an algorithm can search their combinations faster than a trader. Da Silva and Mateus-Coelho represent each candidate strategy with an 80-bit string. Decoding that string produces four entry/exit conditions, combining indicators such as RSI7, MACD, ATR, stochastic %K and SMA50 through AND, OR and NOT.

One evolved rule buys on (RSI7 < 30 AND MACD < MACD_SIGNAL) OR (STOCH_K < 20 AND ATR > SMA50). Its exit is (RSI7 > 70 OR STOCH_K > 80) AND MACD > MACD_SIGNAL. Buy oversold, sell overbought: the intended source of profit is short-horizon mean reversion on daily bars. The ATR > SMA50 condition is a peculiar product of the search. It compares a range measure with a price level.

Daily OHLCV candles for BTC, XRP and ETH come from the Hyperliquid API, spanning 01/01/2024 to 01/04/2025. Version 1.7.1 runs four islands, separate populations holding 50 strategies each. Every 10 generations, five migrants selected from the top 10% travel around a ring. Fitness sharing penalizes similar strategies: a genome within Hamming distance 0.1 of another loses 20% of its score. After 20 generations without improvement, the mutation rate rises from 0.3 to 0.9. Random immigrants replace the worst 20% on stagnant islands. A web platform surrounds the optimizer, with user accounts, MongoDB storage and CSV export; its 12 use cases came from interviews with 10 stakeholders.

The reported fitness rises from an average of 0.30 in v1.6.2 to 2.50 in v1.7.1. When the authors re-run v1.7.1 on TradingView, they report 4,139.12 USD in net profit, a 68.29% win rate, a 0.33% max drawdown and a Sharpe of -3.09.

Different objectives behind EvoTrade's 0.30-to-2.50 fitness climb

The authors say v1.6.2 used a simplistic fitness function without complexity bonuses. That leaves 0.30 and 2.50 measuring different objectives. There is another ambiguity: the paper labels 0.30 an average fitness, while leaving open whether 2.50 is an average or the best score.

As printed, the formula adds raw total profit and raw Sharpe, each weighted at 0.4. Yet the paper separately defines normalized versions, profit/100,000 and (Sharpe+10)/20. It also counts trades twice. Normalized trades receive a weight of 0.1, then enter again through a trade bonus of 0.1 times normalized trades. The stated purpose is "rewarding active strategies". Each logical operator collects another 0.01. The optimizer therefore pays for more trades and longer rules, pushing in the same direction as overfitting. Among their proposed changes, the authors suggest cutting the complexity bonus in half to 0.005, linking it to convergence instability.

What does EvoTrade get from 56 winners in 82 trades?

Very little, judging by these results. The 68.29% hit rate across 82 trades delivered +0.41% over roughly fifteen months, reading the dates day-first. Frequency alone tells us nothing about the size of the wins. Rules that buy oversold and sell overbought can collect small gains repeatedly, then surrender them in a few losses. The paper supplies no average win, average loss or payoff ratio. Its Tables 3 and 4 have no contents in the text either, leaving the payoff ratio beyond checking.

A Sharpe of -3.09 accompanies positive profit and a drawdown of 0.33%. Subtracting a risk-free rate in the simulator offers one possible reconciliation. Over fifteen months, a 0.41% return would represent a negative excess return. Divide that by the tiny volatility implied by a 0.33% drawdown, and the ratio becomes heavily negative. On this reading, the strategy stayed close to flat and underperformed cash.

The Sharpe changes sign between EvoTrade's backtest and TradingView

For v1.7.1 over the same dates, the authors compare their in-house backtest with TradingView:

They explain the profit and Sharpe discrepancies as "unmodeled costs (slippage, dynamic fees) and data differences (e.g., TradingView's adjusted OHLCV)". The passage leaves the drawdown discrepancy unanswered. Costs could reasonably explain the profit difference and some of the Sharpe difference. They cannot account for drawdown falling by a factor of about 45, from 15% to 0.33%. Fees deepen drawdowns. Such a small drawdown suggests that the engines used different sizing or traded different sets of signals.

We did not find the starting capital, the sizing rule across the three coins, or TradingView commission settings in the paper. Until those agree, the runs amount to two strategies sharing a name.

One 15-month window does both jobs

The backtest covers 01/01/2024 to 01/04/2025. So does the TradingView simulation, from 01/01/2024 to 01/04/2025. We found no held-out period. The authors acknowledge the danger: the "high win rate (68.29%) may indicate overfitting to historical data, reducing generalizability". Their abstract identifies convergence stability, real-world discrepancies and overfitting as unresolved challenges. It includes the 4,139.12 USD net profit, while leaving +0.41% to the results section. The abstract also says the open design and dataset generation "position it as a significant contribution" to automated trading research.

The engineering claim stands up. There is a working platform, and the paper specifies an 80-bit genome with four conditions, although the bit layout table has no contents in the text. The trading claim still needs a chronological holdout after 01/04/2025, with results reported as the spread across GA runs using different seeds. We also did not find a buy-and-hold comparison for the same three coins and dates. The authors themselves leave commission and slippage inside the optimizer, along with live trading, as future work.

The mutation ceiling needs checking too. The text never specifies whether 0.9 applies per bit. If it does, about 72 of the 80 bits flip, placing each child near its parent's bitwise complement. Even the base rate of 0.3 would flip about 24 bits per offspring.

We are now building an EvoTrade-style version, and its limits need to be clear. We use crypto spot bars because Hyperliquid's instruments and venue history are beyond our reach. Any perpetual-contract economics are therefore absent. Since the paper's fitness equation combines raw and normalized terms, we selected and documented our own normalization. Our fitness scores will not match the 0.30 to 2.50 scale. The build tests the method family: daily technical rules evolved by an 80-bit GA on BTC, XRP and ETH. It reproduces neither the authors' software nor their TradingView run. We have no results yet.

For now, the evidence is a strategy that won 56 of 82 trades and roughly broke even.