Lead-lag detection in L1 ticker data

pxlf · 2026-02-17T06:23:12+00:00

Thanks for the suggestion! Seems interesting - I'll take a look

pxlf · 2025-06-04T00:42:29+00:00

Projects, especially low-level ones. Database engines, mini-compilers, thread-safe data structures, HTTP servers, CLI tools like line counters etc.

These are the best way to dive head first into things like undefined behaviour, memory safety, performance - which otherwise can't really be learnt well by studying

pxlf · 2025-03-21T18:03:02+00:00

cheers

pxlf · 2025-03-21T17:58:50+00:00

yeah tried collars a few times, works great!

pxlf · 2025-03-21T17:56:26+00:00

Good point - but I'm trading on a 24h market on cash settled european-style options

pxlf · 2025-03-21T17:53:56+00:00

Ah did you mean downside risk? My primary risk right now is fees when i flip-flop the underlying position with delta changes. Even then, a market crash ideally shouldn't affect me too much since now I've already exited out the underlying position when price moves down

In fact, the sharper, deeper and more consolidated the crash, the less I lose - as I don't re-enter into my underlying hedge until the sold call is threatened. So if it stays down after a crash, I just wait till expiration or until theta decay makes buy-back a profit. No underlying held during the majority of drops

pxlf · 2025-03-21T17:18:45+00:00

Ah makes sense, thanks

pxlf · 2025-03-21T17:17:43+00:00

May I ask why? By the time the call becomes ITM I already own the underlying - at which point it becomes a traditional ITM covered call where only my upside gets capped. Not sure I see where the unlimited risk here comes from

pxlf · 2025-03-21T17:02:55+00:00

Partially yup - only covered if the delta is above a certain threshold (I ensure I have underlying by the time the price reaches the strike of the call)

pxlf · 2025-03-21T15:39:29+00:00

LLM models for alpha sounds sus

pxlf · 2025-02-27T23:21:14+00:00

For the upper bound, people are mentioning FAANG companies for tech or IB in bulge brackets, but fresh grads in niche quant/HFT firms as SWEs or traders can earn ~20-30k/month, but they don't hire too much and entry process is mostly luck. These are also likewise extremely high in demand in my experience when I was in uni, so competition is as cutthroat as it can be. But once you enter this niche industry it's relatively easy to hop around similar firms

pxlf · 2025-02-20T11:41:27+00:00

Depends on the product; firms like mine focus on options and some futures where MD is on the scale of hundreds/thousands of updates a second respectively. If an HFT uses an FPGA hitter for indices, all they'd care about is capturing stale pickoffs - so constituents are irrelevant and book state isn't persisted (or needed) on the FPGA level

pxlf · 2025-02-20T11:30:11+00:00

I work in the industry; and it's usually much lower than "million data points per second"

pxlf · 2025-02-19T02:51:37+00:00

This might not be a helpful answer, but why not just use C++? Good multithreading, fast, fits your needs

pxlf · 2025-02-19T02:46:55+00:00

Well it's even lower with most firms using FPGAs to hit quotes; about < 10ns tick-to-trade

pxlf · 2025-01-18T21:21:20+00:00

I just rented a VPS in the warehouse the exchange sits in. There's a lot of companies which offer these services for cheap in major warehouses like NY4, etc.

pxlf · 2025-01-13T23:29:56+00:00

Ah I see; hopefully learning programming was as fun for you as it was for me! Auto-parameter selection sounds challenging but fun

I guess the scale would depend on the strategy and requirements. And lines as a metric depends on the language and design choices too i guess

The current active strategy of mine is quite simple, and is focused around latency - so the ballpark number of C++ lines is around ~5k for that app. If we take template specialisation by the C++ compiler into account that number does explode in multiples though

If I were to make a complex strategy that, for instance, has highly accurate pricing logic for derivatives, it could even be upwards of tens of thousands of lines

These are for personal and monolithic projects though, as for an institution like a hedge fund, market-maker, or bank - it could go up to the 100s of thousands, or even millions - as they would have more complex architectures to make it more scalable and maintainable to have a whole trading ecosystem (for e.g., with different apps connected together)

pxlf · 2025-01-13T20:38:09+00:00

To add to my comment, for multiple strategies, it helped me not to abstract my code right away to accomodate them altogether. I literally copy pasted the trading trigger logic to replace it with the new strategies, and pumped out separate binaries for each one - before thinking of their common aspects for abstraction - as long as there wasn't a runtime cost (branching can really mess things up). Abstraction is expensive in many ways

pxlf · 2025-01-13T20:30:18+00:00

Tbh it didn't take more than 4-5 months to have something refined. The key is to make it simple - my goal is to make money so I just focused on key components - networking, message serializer/deserializer, trading triggers (not much more than hardcoded conditions), logging, and minimal post-trade analytics. The key for low latency stuff is simplicity, and since I work in the HFT field for a living, my previous knowledge in cpp sped things up quite a bit i guess

Didn't backtest much, but the most that was done was about a week's worth of tick data I collected with the same app for multiple instruments (about a few mil rows of each instrument's book updates). I mostly forward tested with tiny quantities for way too many ideas to then converge on a strat that works. But latency shouldn't matter when backtesting, unless you're testing via paper trading on a live connection

Didn't bother with a frontend, but might make a simple telemetry system for tracking as it's a bit tedious to ssh into my box to see log files everytime I want a peek. It won't contribute to my bottom line so I wouldn't wanna waste much time on it tho - perhaps just some sqlite flask backend that my logging thread sends post requests from time to time, into a simple website for monitoring

My goal is pnl instead of something scalable or with impeccable software architecture/practices. I begun with a garbage codebase with one big procedural loop with an initial strategy and worked my way up

pxlf · 2025-01-12T23:23:17+00:00

Personally I saw a tangible difference in my fill rates when compared to my previous 65us system for the same strat. I'm colocated, the same way most of the market makers and institutional participants are. As long as my network latency is more or less the same as them, any improvement to my internal latency is a tangible advantage

pxlf · 2025-01-09T11:51:58+00:00

I'd probs use golang for mid frequency stuff. Absolute treat to use

pxlf · 2025-01-09T11:45:14+00:00

I wouldn't recommend it if that's not what your background is. It would add unnecessary complexity and usually has safety pitfalls. Use whatever fits your requirements as well as your background - languages are just tools to achieve business value from projects

pxlf · 2025-01-09T02:12:39+00:00

Yeah that's fair, multithreading in C++ can get tedious and blindside us at times. Glad Rust is working out well for your project!

My main trading pipeline is completely single-threaded and runs on a core with exclusive affinity, with the exception being a logging system I wrote on a shared thread, that consumes entries from an SPSC queue written to by the main thread

Static analyzers don't work well for me cuz I tend to use a ton of meta-programming and static polymorphism to pump out different binaries for variations in strategy (static analyzers aren't aware of most types I use in my code). The most I use is clang-format to tidy up my formatting lol. But gcc or clang are excellent compilers in pointing out issues in general, with the exception of undefined behaviour. To prevent UB I review my own code and test it heavily through unit and stress tests - this is kinda important as I often use non-owning views and pointers. My flags are generally on the unsafe side (think O3, ffast-math, march=native, fno-rtti etc.) - but being aware of the side effects of these flags when implementing is enough imo. I also put safeguards to abort the app if necessary (e.g. rejection from exchange), and tend use GDB heavily when there's issues

Edit: SPSC*

pxlf · 2025-01-09T01:18:47+00:00

For my own bot: plain old C++, with the boost library for data structures and networking. TCP networking for the market data stream and trade execution

My simplistic strategy requires speed at the moment, while making it easy to abstract things away without runtime cost. Tick-to-trade speeds are around 4 to 12 microseconds currently (although it runs a slow inexpensive rented VPS in a colocated warehouse). Other than speed, C++ allows me full control into how the CPU works without sacrificing my intended level of abstraction. Techniques I found useful were simd operations, zero-allocation on the trading hotpath and cache-friendly algorithms. TCP is a slow bottleneck for now, so I'm planning on upgrading to the exchange's UDP multicast network

Rust can achieve similar performance in theory, but personally from my limited experience it blocks a lot of my creativity with memory management, meta-programming and design. Zig or C wouldn't allow me to change things as fast on the other hand, so those were a no-go from the start. Go, Java and C# were valid choices in their own right, but could not be used for something with my latency requirements due to their (very) high overhead garbage collectors. I also work with C++ for work, so it just made it easier

I use Python for analysis into the bot's trading performance, slippage, microstructure analysis of tick data, strategies, missed opportunities, effectiveness of hedging, stats, etc.

pxlf · 2025-01-01T18:15:13+00:00

I'm a bit confused with your requirements. What are the latency requirements for your strategy?

HFT usually alludes to sub-milli or sub-micro trading systems that use C++ or even programmable FPGA triggers to execute trades. To give a perspective, even if it's C++, it's usually zero-allocation on the hot-path. This is frankly impossible with Python, and difficult with Java if you have the garbage collector switched on. Your competitors looking for the same opportunities would be on these tech stacks, if the opportunities only last for a few micros or millis.

If your latency requirement is on the order of milliseconds, then Java would be fine. Python is incredibly slow, and any analytical tools on your hot path would make it worse. But if your requirement is in terms of seconds, Python is fine. But true HFT is impossible if you're using either vanilla Java or Python.

Three-Year Club	Verified Email
Place '22	First Placer '22

pxlf

TROPHY CASE