Fixed grid sizes were hurting my results
A simple assumption about market behaviour eventually forced me to rethink how trading systems should adapt to changing conditions.
For a long time, fixed parameters felt like the most sensible approach. Choose a buy interval, choose a sell interval, configure the system and let it run.
Simple. Predictable. Easy to understand. Unfortunately, markets are rarely that cooperative.
The assumption
Many trading systems rely on static values: a fixed distance between entries, a fixed target for exits, a fixed interpretation of volatility.
At first, this seems logical. Consistent rules create consistent behaviour. The problem is that markets themselves are not consistent.
Some periods are calm. Others are chaotic. Some assets move slowly. Others move aggressively.
Yet the system continues applying exactly the same rules.
When good settings become bad settings
One observation appeared repeatedly: a configuration that worked well during one market phase often performed poorly during another.
The settings themselves were not necessarily wrong. The environment had changed.
What used to be appropriate became too aggressive, too conservative or simply irrelevant. This forced me to ask a difficult question.
Should the market adapt to the system? Or should the system adapt to the market?
The cost of rigidity
Static rules have advantages. They are easy to test, easy to explain and easy to reproduce. But rigidity comes at a cost.
Markets evolve continuously. Volatility expands and contracts. Momentum appears and disappears. Liquidity changes.
A system that ignores those changes risks making increasingly poor decisions over time.
Searching for adaptation
The objective was never to create a system that constantly changes its behaviour. That can create a different set of problems. The goal was to find ways of acknowledging market conditions without introducing unnecessary complexity.
A balance between stability and adaptability. Simple in theory, much harder in practice.
A turning point
This realization eventually pushed me toward an entirely different way of thinking about execution.
Instead of asking:
"What are the correct parameters?"
I started asking:
"How should parameters behave when conditions change?"
The distinction may seem subtle. But it fundamentally changed the direction of the project, and it would later influence several important components of Oblivion.
Sometimes the biggest improvements do not come from finding better values. They come from questioning whether those values should remain fixed at all.