Philosophy and Design Choices

This post is about building Outlier Detector, and the design choices that kept forcing hard decisions along the way.

This whole project came from something I kept running into during my years of discretionary trading ventures. I would notice patterns from day to day. Certain times of the week looked more active than others. Certain structures on the chart kept seeming to matter. At one point I built a program that split the day into minute intervals and tried to find which minute had produced the most cumulative profit over a year. I did the same with hours and with days. Clear patterns emerged. Some were more green than others. Was it coincidence? Was it random? I honestly did not know.

What I did know was that I did not trust it enough to put money behind it. Just because something happened before does not mean it should happen again in the future, and my paper-trading setup at the time was nowhere near good enough to prove otherwise. That was one of the first points where I had to admit the difference between an interesting idea and something I would actually be prepared to trade.

I wanted a real momentum signal. My first attempt was relatively pathetic. I might as well have looked at the top hourly winners and losers on CoinMarketCap. There was no real difference. The same question kept coming back: if something has already gained or lost a lot, why should it continue from there? In some cases there is more logic in fading that move than chasing it. That is something I am still interested in, but it made one thing clear very quickly: my first version was not enough.

So I did more research. I read papers, especially work from Cliff Asness and AQR around momentum and value, and tried to understand what could actually survive contact with crypto. His framework made sense in equities and commodities, but crypto is a different environment. A lot of assets are still heavily pulled around by BTC, and sometimes the market is just absurd.

SIREN - PREVIOUSLY A TOP 40 COIN BY MARKET CAP, LISTED ACROSS MAJOR EXCHANGES

SIRENUSDT chart showing violent price spikes and collapses.

Siren was a great example of this. At the time it was not some forgotten micro-cap hidden in the corner of the market. It was a large listed coin, available everywhere, and to me the chart still looked like pure manipulation. That is why I found a lot of traditional universe-selection logic hard to trust here. You can make the process look sophisticated, but if the underlying market is still capable of behaving like that, you have to stay honest about what your inputs are worth.

That is one of the reasons I decided to use a fixed universe. It is less sophisticated, but safer, and at this stage I care more about being able to reason clearly about what the engine is looking at than sounding clever. I found the same issue with value. In crypto, value is hard to define without stitching together proxies from activity, revenue, flows, or on-chain usage. Maybe that comes later, but I did not want to force it in just because it makes the model sound more complete.

More than anything, I did not want this project turning into one of those systems where features are added just so the builder can say they know complex methods. Every feature has to fight for its life before it gets included. That is the standard I wanted. If something does not materially improve the detector, it has no right being in there.

Testing has been a large part of that. I have been running parallel instances on rented VPSs, letting them collect logs, then going back through the output by eye after a day or two. It is tiring, but I trust that process more than pretending the first clean backtest tells the truth. At the time of writing, I am still testing. In between testing periods I just work on something else and come back to it.

I never wanted a system that only wakes up every fifteen minutes because the bar closed. I wanted something constantly observing, but rarely alerting. I am still researching ways to get closer to that. I have explored a more WebSocket-heavy approach, but that comes with downsides as well. There is no perfect architecture here. There are only tradeoffs you understand and tradeoffs you do not.

Outlier Detector is still a work in progress, and that is fine. Right now this is the first step. I want to build a detector I genuinely trust before I even think about layering on execution, portfolio logic, and the rest of a full trading system. Trying to do all of that at once is a very good way to fail.

Back to Ideas