Cycle Bot
A theory I believe in, held to evidence anyway.
A crypto trading system built on market-cycle theory and Wyckoff-style accumulation and distribution: publicly studyable ideas about how markets move in repeating phases, which I learned from a creator who teaches them well and then read around on my own. I do believe in the theory. That is exactly why I built the measurement before the money, so I would find out which parts of it hold up and which parts I had only assumed.
WHAT HELD UP confirmation signals profit factor ~2x vs matched control phase logic reproducible, tested, 216 cases WHAT DID NOT per-asset cycle length identical for both assets, every setting out of sample (asset B) profit factor 7.56 -> 1.30 live trading GATED OFF (5 independent code paths)
Cycle theory says markets move through repeating phases rather than in a straight line, and Wyckoff describes how accumulation and distribution show up inside those phases. Both are decades old and widely taught, so the interesting engineering question is not whether the ideas exist, it is which specific version of them survives contact with real data. I turned the version I had learned into code: pivot detection, phase classification, and confirmation signals, each one a testable component rather than a single opaque rule.
Then I built the harness that could tell me I was wrong. A matched control, the dumbest trend follower I could write, gave me something to beat, and the confirmation signals did roughly double it on profit factor, so that part of the theory earns its place. One specific timing parameter did not: the claim that different assets turn on measurably different cycle lengths did not reproduce, because my implementation returned the same length for both assets at every setting I tried. A walk-forward test on data the parameters had never seen showed the other weak spot, one asset falling from a profit factor of 7.56 in-sample to 1.30 out-of-sample, which is the signature of fitting the past rather than describing it. So live trading is disabled at five separate points in the code. Switching it on has to be a deliberate act with a reason, not a flag someone forgets.
The most valuable thing I found was in the data, not the strategy. The exchange I intended to execute on prints occasional phantom lows: on one day it reported a low of around 8,200 dollars for an asset that other sources put near 62,000, while the closing prices from both sources agreed to within 0.05 percent. The cycle detector reads lows directly, so those prints would have silently defined turning points that never happened, and a resting stop order would have been filled by one. All cycle maths now runs on a separate data source, and resting stops are banned in favour of decisions made on closes. 216 tests cover the engine.
- Python
- backtesting
- walk-forward validation
- data integrity checks
- REST and WebSocket APIs
- 216 automated tests
- separating a theory from its implementation
multi-week build
What it actually took. The uncomfortable part was that I believe in this theory, so I was the worst possible person to test it. I had done the reading, taken the notes and built the scaffolding, and the honest move was to write the test that could embarrass my own conclusion. It embarrassed one parameter and vindicated another, which is a better outcome than either faith or dismissal would have given me. What I have now is a measurement harness, a control to compare against, a documented data trap, and a system that refuses to place a real order until the evidence says it should. Believing in an idea and verifying it are not in conflict. Verification is how the belief becomes usable.
Private build. The theory is public and widely taught; the implementation, parameters and test results are mine. Walkthrough on request.