When the First Negative Backtest Changed the Story

Futures looked faster

On June 12 the project asked a simple question: could futures make money faster than spot trading? Minutes later the direction changed. The bot was to be converted toward futures.

This was not a mature risk decision. It was an early project looking for a more powerful way to trade.

The bot was supposed to decide for itself

The same evening another idea became explicit. The bot should make its own decisions instead of relying on a growing list of rigid settings.

That ambition had appeared before, but now it was being pushed into the trading logic itself. The desired system was adaptive. The actual system was still experimental.

More data, more optimization

By June 13 the work included roughly three years of BTCUSDT futures history at 15-minute resolution. The project was collecting more data and trying to optimize the strategy.

There was already a warning sign. One earlier optimization result looked positive while another metric looked suspicious. Even at this stage, a good-looking headline number did not automatically mean the test was trustworthy.

Then the backtest lost money

Early on June 14 a later optimization finished below the starting capital. The preserved record shows 100 USDT becoming 91.54 USDT, a net result of -8.46% across 911 trades, with a 25.47% win rate.

This was not a scientific verdict on AUR. It was an early backtest of an early bot. But historically it mattered because the easy story broke. More code, more data and more optimization did not automatically produce a profitable system.

A useful failure

The project did not become rigorous overnight. It kept experimenting, changing architecture and making mistakes. But this was one of the first clear moments when the numbers pushed back against the ambition.

The next stage moved toward a more modular Python architecture and an attempt to define a coherent coding doctrine for the bot.