A noob’s adventures in quant trading

1. Know basic statistics

I didn’t even do out of sample testing before running my first ever strategy, I misunderstood a few days of tick by tick data as independent regimes and not highly correlated markets. It’s not binary, but for my first taker strategy I only used 6 days of data. When I ran the same strategy on 30 days, split across tests and validated dataset, it was badly negative. Anyways, make sure before running your strategy do these two things at least and a lot more, t-stat, etc, best thing to do is to manually look into the raw data, and ask a lot of questions. Are the profitable trades coming from 1 or 2 days? Are they coming from specific times, etc, etc. Ask infinite questions. Have a checklist just for statistical things you need to check before deploying a strategy live. Don’t be an idiot and lose money because you missed one statistical check that invalidates your whole strategy.

2. Every strategy is latency sensitive

Yes, everything from long term 10yrs timeframes to hft, milliseconds is latency sensitive. Specifically, think of every strategy as signal firing and then when does it reprice to your fair. For hft stuff, like a few seconds timeframes etc, you need to look at how fast your signal reprices to your fair. For my very first taker strategy, by the time I was able to execute, 80-90% of the “edge” had already been repriced. I didn’t even think about this before running, honestly kinda embarrassing. The thing to take away from this point is signals vs executable signals.

3. There’s a lot of infra.

Especially if you do market making, simply, because you need to be there in the market and everything is conditioned on getting fills so if you do do backtesting it’s a lot more code to write to simulate when you’ll get filled and how much you’d get filled and everything around getting filled and basically your job is to make like 5-x bps a lot of times and then lose all your money in 1 trade. Getting in a queue and picking up coins in front of a steamroller is a pretty analogy.

Also for the live trading engine, most hft strategies are highly latency sensitive, i.e. you’d definitely make more money if you’re faster independent of what strategies you use. So it’s this huge incentive to always be improving your code and optimize the entire stack so you can trade faster, because you can directly contribute to profits. Furthermore, the live engine is kinda complex, there’s a lot of quirky things specifically built around the randomness of cloud based exchanges and websockets to make it super fast.

Backtesting and research also is another side of the infra you need to be thinking of. What format are you going to store market data in?, will you have it on external cloud storage or local drives? Will you record certain features so you can easily test out strategies that use them? If so, what?

Overall there’s just a lot of code to write, more infra if you’re a maker and more modelling if you’re a taker.

This a rough architecture diagram of the live trading system

There’s a lot of nuance underneath, some interesting ideas, implementation to increase speed or reduce tail events are in no particular order and btw this is just an extremely basic system that I’ve worked on in like 3 months relatively full time I’d say. A lot are fairly basic rn:

• The engine opens four subscriptions to the same Polymarket market stream and user stream and accepts the first copy of each event, rather than trusting the latency tail of one TCP/WebSocket path. The readers reconnect independently, so the race is also feed redundancy. Implementation
• Results, paired benchmark: fastest-of-1 to fastest-of-4 changed p50 63.7 → 45.9 ms (-17.9 ms), p95 7,500 → 5,353 ms (-2,147 ms), and p99 9,373 → 8,082 ms (-1,291 ms) over 9,270 fully observed events.
• At startup and when new assets are added, the gateway builds and EIP-712-signs reusable post-only orders for every configured price/size key. The submit path pops a signed order from memory and falls back to live signing only when a finite cache bucket is empty
• Give order cancel races four pre-authenticated HTTP clients

There are like 25 more main core things I did to speed up the engine, but won’t put here. Generally speaking its common optimisation stuff.

Another weird thing on the infra is crypto exchanges and prediction markets are very flaky. There’s a lot of random shit that can give you an infrastructure advantage. For example on polymarket, I found out the market websocket only returns about 20% of the actual trade tape compared against the rtds api, which returns 100% of all the trades. The 20% and 100% are compared against real onchain data. Also found out that the /orders endpoint was significantly slower than sending concurrent /order orders. Another thing I found was that when you cancel an order with /cancel endpoint and it returns a successful 200 response, it can somehow still not be cancelled onchain and you end up not canceling that order. Just to clear up, this is not a cancel race issue, but an issue with dumb api + onchain design.

For each of these quirks I'm sure there’s plenty of strategies designed to exploit each one.

4. Data?

This part for me was a little underexplored. I just used public data, I think this is one of the reasons why my models don’t really work on something like pricing 5min BTC, simply because it’s too competitive to find an edge in publicly available data? All the pros have squeezed all the juice here perhaps.

5. Utility to the world?

We’re not curing cancer here folks and at the market level at which traders operate it is a zero sum game (in that market! Not as a whole).

6. Art or Science?

Right now I’d say it’s a fair amount of art. Well I’m not profitable yet, but based on the process it’s a fairly artistic/creative process? You kind of have to have some amount of taste to design these strategies and craft it around the quirks of the exchanges as well as some insight you have about other traders or markets.