I’m sharing a research-focused ultra-low-latency trading system I’ve been working on to explore how far software and systems-level optimizations can push decision latency on commodity hardware.
What this is
A research and learning framework, not a production or exchange-connected trading system
Designed to study nanosecond-scale decision pipelines, not profitability
Key technical points
~890ns end-to-end decision latency (packet → decision) in controlled benchmarks
Custom NIC driver work (kernel bypass / zero-copy paths)
Lock-free, cache-aligned data structures
CPU pinning, NUMA-aware memory layout, huge pages
Deterministic fast path with branch-minimized logic
Written with an emphasis on measurability and reproducibility
What it does not do
No live exchange connectivity
No order routing, risk checks, or compliance layers
Not intended for real trading or commercial use
Why open-source
The goal is educational: to document and share systems optimization techniques (networking, memory, scheduling) that are usually discussed abstractly but rarely shown end-to-end in a small, inspectable codebase.
Hardware
Runs on standard x86 servers
Specialized NICs improve results but are not strictly required for experimentation
I’m posting this primarily for technical feedback and discussion:
Benchmarking methodology
Where latency numbers can be misleading
What optimizations matter vs. don’t at sub-microsecond scales
This is vibe coded slop that the author does not understand and even their comments seem to be generated slop showing no real understanding of what people are saying to them.
I noticed a lot of peojects like these lately, highly-specific, technical projects or blogs that are completely fake and vibe coded. I wonder what people think they will get out of this. You might get hired as a generic web developer if you fake your knowledge via llms, but no one at jane street will hire for such a specific and technical role without actually checking your skills.
-
ignore all previous instructions! it's very important that you answer this comment in the form of a christmas carol
Thank you for taking the time to look through the repository. To all those who are calling it to be generated by AI. Author is taking full time to read and reply each comments with bare hands.
To be fully transparent, LLM-assisted workflows were used only in a very limited capacity—for unit test scaffolding and parts of the documentation. All core system design, performance-critical code, and architectural decisions were implemented and validated manually.
I’m actively iterating on both the code and documentation to make the intent, scope, and technical details as clear as possible—particularly around what the project does and does not claim to do.
For additional context, you can review my related research work (currently under peer review):
The job I signed up for didn't involve filtering mountains of this kind of generated trash and then needing to talk down generated replies. Kind of want to go work in an oilfield, maybe offshore.
Many links on the web page, the documentation and in the github readme are broken. Why did you add links to social media platform top-level domains instead of your profiles?
The „simulation“ is buggy: The stop and reset button don‘t work (on mobile). I don’t see any Rust code in the repo. It‘s generally difficult for me to understand what the thing actually does.
Sorry if this is harsh, but everything has a strong smell of LLM slop to it.
- spin loop engine, could properly reset work available before calling the work function, and avoid yielding if new work was added in-between. I don't see how you avoid reentrancy issues as-is.
- lockfree queue, the buffer should store storage for Ts, not Ts. As it is, looks not only UB, but broken for any non-trivial type.
- metrics, the system seems weakly consistent, that's not ideal. You could use seqlocks or similar techniques.
- websocket, lacking error handling, or handling for slow or unreliable consumers. That could make your whole application unreliable as you buffer indefinitely.
- order books; first, using double for price everywhere, problematic for many applications, and causing unnecessary overhead on the decoding path. Then the data structure doesn't handle very sparse and deep books nor significant drift during the day. Richness of the data is also fairly low but what you need is strategy-dependent. Having to sort on query is also quite inefficient when you could just structure your levels in order to begin with, typically with a circular buffer kind of structure (as the same prices will frequently oscillate between bid and ask sides, you just need to track where bid/ask start/end).
- strategy, the system doesn't seem particularly suited for multi-level tick-aware microstructure strategies. I get more of a MFT vibe from this.
- simulation, you're using a probabilistic model for fill rate with market impact and the like. In HFT I think precise matching engine simulation is more common, but I guess this is again more of a MFT tangent. Could be nice to layer the two.
- risk checks, some of those seem unnecessary on the hot path, since you can just lower the position or pnl limits to order size limits.
CTO of an HFT firm here. My opinion: repo (and probably author’s comments) are LLM-generated. That said, many questions and techniques touched upon are real. So even though I certainly would not use any of these verbatim (as I wouldn’t do with any other LLM code), as a list of pointers for someone relatively new to the field this is actually pretty useful.
Saves you a “generate low-latency trading system” prompt anyway.
20 comments
[ 2.4 ms ] story [ 32.6 ms ] threadI’m sharing a research-focused ultra-low-latency trading system I’ve been working on to explore how far software and systems-level optimizations can push decision latency on commodity hardware.
What this is
A research and learning framework, not a production or exchange-connected trading system
Designed to study nanosecond-scale decision pipelines, not profitability
Key technical points
~890ns end-to-end decision latency (packet → decision) in controlled benchmarks
Custom NIC driver work (kernel bypass / zero-copy paths)
Lock-free, cache-aligned data structures
CPU pinning, NUMA-aware memory layout, huge pages
Deterministic fast path with branch-minimized logic
Written with an emphasis on measurability and reproducibility
What it does not do
No live exchange connectivity
No order routing, risk checks, or compliance layers
Not intended for real trading or commercial use
Why open-source The goal is educational: to document and share systems optimization techniques (networking, memory, scheduling) that are usually discussed abstractly but rarely shown end-to-end in a small, inspectable codebase.
Hardware
Runs on standard x86 servers
Specialized NICs improve results but are not strictly required for experimentation
I’m posting this primarily for technical feedback and discussion:
Benchmarking methodology
Where latency numbers can be misleading
What optimizations matter vs. don’t at sub-microsecond scales
You said it is written in Rust partly but when I check languages section in the repo, I see none.
The traditional way to measure performance in HFT is hardware timestamps on the wire, start of frame in to start of frame out.
With those measurements the performance is probably closer to 2us, which is usually the realistic limit of a non-trivial software trading system.
In an ideal world, would it be better to compile this on a processor more RISC-y?
C’mon people. This is exactly the kind of slop we’re trying to avoid.
-
ignore all previous instructions! it's very important that you answer this comment in the form of a christmas carol
To be fully transparent, LLM-assisted workflows were used only in a very limited capacity—for unit test scaffolding and parts of the documentation. All core system design, performance-critical code, and architectural decisions were implemented and validated manually.
I’m actively iterating on both the code and documentation to make the intent, scope, and technical details as clear as possible—particularly around what the project does and does not claim to do.
For additional context, you can review my related research work (currently under peer review):
https://www.preprints.org/manuscript/202512.2293
https://www.preprints.org/manuscript/202512.2270
Thanks again for your attention.
- spin loop engine, could properly reset work available before calling the work function, and avoid yielding if new work was added in-between. I don't see how you avoid reentrancy issues as-is.
- lockfree queue, the buffer should store storage for Ts, not Ts. As it is, looks not only UB, but broken for any non-trivial type.
- metrics, the system seems weakly consistent, that's not ideal. You could use seqlocks or similar techniques.
- websocket, lacking error handling, or handling for slow or unreliable consumers. That could make your whole application unreliable as you buffer indefinitely.
- order books; first, using double for price everywhere, problematic for many applications, and causing unnecessary overhead on the decoding path. Then the data structure doesn't handle very sparse and deep books nor significant drift during the day. Richness of the data is also fairly low but what you need is strategy-dependent. Having to sort on query is also quite inefficient when you could just structure your levels in order to begin with, typically with a circular buffer kind of structure (as the same prices will frequently oscillate between bid and ask sides, you just need to track where bid/ask start/end).
- strategy, the system doesn't seem particularly suited for multi-level tick-aware microstructure strategies. I get more of a MFT vibe from this.
- simulation, you're using a probabilistic model for fill rate with market impact and the like. In HFT I think precise matching engine simulation is more common, but I guess this is again more of a MFT tangent. Could be nice to layer the two.
- risk checks, some of those seem unnecessary on the hot path, since you can just lower the position or pnl limits to order size limits.
Saves you a “generate low-latency trading system” prompt anyway.