krish678

I’m open-sourcing OpenTX, a production-grade payment gateway and canonical transaction protocol designed to modernize legacy ISO 8583 payment systems for cloud-native architectures.

GitHub: https://github.com/krish567366/OpenTX

Stack: Go, Protocol Buffers, Kafka, OpenTelemetry License: MIT

OpenTX provides a strongly-typed canonical transaction layer between legacy card networks and modern APIs, allowing fintech teams to decouple application logic from network-specific ISO 8583 formats.

Most payment teams still integrate directly with brittle, tightly-coupled ISO 8583 implementations. OpenTX introduces a standardized, versioned transaction model with bidirectional mapping, exactly-once semantics, message-level security, and built-in observability.

This is relevant for:

Fintech and payments startups

Infrastructure and developer tools teams

Multi-network aggregation platforms

Companies modernizing legacy financial rails

Feedback and contributions from founders and infra engineers are welcome.

That number is for a non-trivial software path (parsing, state updates, decision logic), not a minimal hot loop. Sub-100 ns in pure software usually means extremely constrained logic or offloading parts elsewhere. I agree there’s room to improve, and I’m working on reducing structural overheads, but this wasn’t meant to represent the absolute lower bound of what’s possible.

Good point — ‘sub-microsecond’ is definitely more precise! Appreciate the feedback.

I understand — the reviewers clearly see it differently, which is why they’ve been carefully evaluating my paper for the past 15 days.

Not a bot — just a human who thinks em dashes pair nicely with tinsel. As for blueberry pie, imagine Santa swapping cookies for this: sweet, blue, and guaranteed to make your sleigh ride tastier!

Thanks for pointing this out. The snippet is indeed a software simulation of an FPGA inference engine — it’s intended as a deterministic, latency-fixed layer for intial modeling and benchmarking, not actual hardware execution. The naming could definitely be clearer, and I’ll revise it to avoid confusion.

Thankyou so much all this feedback. I’d also love to connect and discuss some of these points further if you’re open.

Not a parody, just me trying to keep the thread constructive while sharing the project. Enjoying the discussion, even when it gets a bit wild.

I hear you. I realize the repository and docs are dense and can be overwhelming. I’m actively working on cleaning up the presentation, improving examples, and making the intent and learning points easier to see. Thanks for your feedback.

Congrats on the vacation vibes! Hope you enjoy some well-earned time offshore or wherever it takes you.

The main goal is experimenting and sharing what I’ve learned. Seems like people are enjoying it, which is nice to see.

Thanks for the perspective! The goal isn’t to get hired immediately for a super-specific role—it’s more about learning and experimenting with ultra-low-latency systems. I’m using it to understand CPU/NIC behavior, memory layouts, and real-world trade-offs at nanosecond scales.

Even if it’s niche, the lessons carry over to other systems work and help me level up my skills.

Thanks for asking! So far, optimizations are on x86—CPU pinning, NUMA layouts, huge pages, and custom NIC paths. Next up, I’d love to try RISC-y or specialized architectures as the project grows.

The focus is still on learning and pushing latency on regular hardware.

Thanks for checking out the repo. Broken links and top-level social URLs were my mistake—I’ll fix them. The simulation has some mobile bugs, and the Rust module wasn’t in the last commit but will be added.

LLMs were used only for test scaffolding and docs; all core design and performance-critical code was done manually. This is a research project, not production trading.

For context, my related work (under peer review): https://www.preprints.org/manuscript/202512.2293 https://www.preprints.org/manuscript/202512.2270

Not vibe coded! See the research (under peer review): https://www.preprints.org/manuscript/202512.2293

https://www.preprints.org/manuscript/202512.2270

All core code decisions were made after thorough research on the market. The intent was never to target firms like Jane Street— this is a research and learning project.

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):

https://www.preprints.org/manuscript/202512.2293

https://www.preprints.org/manuscript/202512.2270

Thanks again for your attention.

Thank you for taking the time to look through the repository.

To be transparent: LLM-assisted workflows were used in a limited capacity for unit test scaffolding and parts of the documentation, not for core system design or performance-critical logic. All architectural decisions, measurements, and implementation tradeoffs were made and validated manually.

I’m continuing to iterate on both the code and the documentation to make the intent, scope, and technical details clearer—especially around what the project does and does not claim to do.

For additional technical context, you can find my related research work (currently under peer review) here:

https://www.preprints.org/manuscript/202512.2293

https://www.preprints.org/manuscript/202512.2270

Thanks again for your time and attention!

Thanks for the observation! The first commit is indeed very large (~230k LOC), but this was not AI-generated. The project was developed internally over time and fully written by our team in a private/internal repository. Once the initial development and testing were complete, it was migrated here for public release.

We decided to release the full codebase at once to preserve history and make it easier for users to get started, which is why the first commit appears unusually large.

Thank you for taking the time to look through the repository.

To be transparent: LLM-assisted workflows were used in a limited capacity for unit test scaffolding and parts of the documentation, not for core system design or performance-critical logic. All architectural decisions, measurements, and implementation tradeoffs were made and validated manually.

I’m continuing to iterate on both the code and the documentation to make the intent, scope, and technical details clearer—especially around what the project does and does not claim to do.

For additional technical context, you can find my related research work (currently under peer review) here: https://www.preprints.org/manuscript/202512.2293

https://www.preprints.org/manuscript/202512.2270

Thanks again for your time.

Thank you for taking the time to look through the repository. I’m continuing to iterate on both the code and the documentation to make the intent and technical details clearer. You can find my research paper(under peer review) here:

https://www.preprints.org/manuscript/202512.2293 https://www.preprints.org/manuscript/202512.2270

Thanks again for your time.

That’s fair feedback — you’re right that the front-page wording overreaches given the current scope.

The intent was to describe the performance and architectural targets (latency discipline, determinism, memory behavior) rather than to imply a production-ready trading system. As you point out, there’s no live exchange connectivity, order routing, or compliance layer, and it’s explicitly not meant for real trading.

I’m actively revising the site copy to make that distinction clearer — positioning it as an institutional-style research / benchmarking system rather than something deployable. Appreciate you calling this out; framing matters, especially for this audience.

That’s a fair point, and I agree on wire-to-wire (SOF-in → SOF-out) hardware timestamps being the correct benchmark for HFT.

The current numbers are software-level TSC samples (full frame available → TX start) and were intended to isolate the software critical path, not to claim true market-to-market latency.

I’m actively working on mitigating the remaining sources of latency (ingress handling, batching boundaries, and NIC interaction), and feedback like this is genuinely helpful in prioritizing the next steps. Hardware timestamping is already on the roadmap so both internal and wire-level latencies can be reported side-by-side.

Appreciate you calling this out — guidance from people who’ve measured this properly is exactly what I’m looking for.

Fair point — agreed. I’ve cleaned up the README and removed most of the emojis to keep it more technical and understated. Thanks for the feedback.

That’s a fair question — thanks for calling it out.

The Rust component is a small, standalone module (used for the latency-critical fast path) that was referenced in the write-up but was not included in the last public commit due to an oversight. Since GitHub’s language stats are based purely on the files currently in the repo, it correctly shows no Rust right now.

I’m updating the repository to include that Rust module so the implementation matches the description. Until then, the language breakdown you’re seeing is accurate for the current commit.

Appreciate the scrutiny — it helps keep things honest.

Thank you for bringing this to my attention, and my sincere apologies for the oversight. The Rust file was inadvertently missed in the previous commit.

I will update it promptly and ensure it is included correctly. Please give a star to repo, if you loved.

Hi HN,

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