Order-execution infrastructure in Rust and C++20 — matching-engine internals, venue adapters written from measurement, and the test harnesses that prove they behave.
This portfolio is about one question: can this run against a real venue safely, and can you prove it? Every claim below links to code you can clone and a command you can run.
I separate what has been independently executed from what a repository reports about itself.
| Project | Claim | Status |
|---|---|---|
| polymarket-copy-trading-hft-rust | 341 tests pass | Verified — cargo test --workspace run to completion |
| polymarket-live-clob-research | 177/177 tests pass | Verified — run against the committed recorded session |
| crypto-mm-engine | 812 tests, 97 benchmarks | Self-reported — build it yourself with the command below |
| crypto-hft-market-making-system | 284 source files, 44 test files | File-count verified; suite not executed |
Event-driven copy-trading engine with paper and live execution behind a single adapter seam.
What I built
- 13-crate Cargo workspace, 341 passing tests, zero
unsafe - Venue integration derived from measurement rather than documentation: the deployed
Polymarket EIP-712 scheme uses domain version
"3", not the"1"every public client documents. Proven by ECDSA-recovering the signers of three already-settled orders. - Published criterion medians: RTDS parse 2.39 µs, order-book sweep VWAP 519 ns – 1.01 µs
What the measurements actually showed: latency is not the binding constraint here. The venue publishes roughly 400 ms late, which dominates any internal saving. The repo argues against its own headline and shows the data.
Tech: Rust, Tokio, EIP-712, criterion
Reconstructs live market events and locates the point where theoretical edge disappears under realistic execution conditions.
What I built
- Deterministic replay over a committed 2.8 MB recorded Polymarket session
- Exact
i128Shapley edge-loss attribution that reports its own rounding residue rather than hiding it verify-replay— determinism across six stages as an executable command, not a claim- An explicit measured-versus-assumed table, so the reader knows which is which
Tech: Rust, deterministic simulation, Shapley attribution
Exchange-agnostic market-making core with replaceable strategies and a shared paper/live engine.
What I built
- Hand-rolled low-latency primitives:
Seqlock,SpscRing,ObjectPool,InlineString,LatencyHistogram,Fixed - Architecture-boundary tests wired into
ctest— module boundaries are enforced mechanically bytools/check_exchange_boundary.py, not by convention - ASan / UBSan / TSan configurations,
-Werrorby default, 9 benchmark translation units
Status, unchanged from the repository: Phase 10 of 16 — not production ready. That line stays because it is true.
Tech: C++20, CMake, ctest, sanitizers
Multi-venue market-making implementations across three languages, plus an order-book core.
284 source files and 44 test files. The substantial component is
cpp-multi-exchange-orderbook-hft (124 files); the remaining language directories are
smaller reference implementations. Roughly three quarters of the repository is written
research notes rather than code — useful, but worth knowing before you clone it.
Tech: C++, Rust, Python
git clone https://github.com/pranay123-stack/polymarket-copy-trading-hft-rust
cd polymarket-copy-trading-hft-rust && cargo test --workspace # expect 341 passing
git clone https://github.com/pranay123-stack/polymarket-live-clob-research
cd polymarket-live-clob-research && cargo test # expect 177 passing
cargo run --bin verify-replay # determinism check
git clone https://github.com/pranay123-stack/crypto-mm-engine
cd crypto-mm-engine && cmake -B build && cmake --build build && ctest --test-dir buildNSE F&O Put-Call Parity Arbitrage (XTS broker) — a six-process live trading system (market data, strategy, OMS, RMS, execution, position management) built on Redis Streams with Lua, TimescaleDB, a hot-reload config watcher and recorded production orders from November 2025.
Two caveats stated plainly: it has no automated tests, and "HFT" overstates it — the system is Python and Redis, and its own README describes sub-second rather than sub-millisecond behaviour. Withheld from the featured list pending a client-rights review, since it contains material from a commercial engagement.
These repositories contain architecture documents only — no source code. They are published as planning artefacts and each carries a banner saying so. Any latency, throughput or performance figure in them is an unmeasured design target, not a result.
| Specification | Scope |
|---|---|
| NSE-equity-HFT-market-making-system | NSE cash-market making, co-location |
| NSE-derivatives-HFT-market-making-system | NSE F&O making, options pricing, delta hedging |
| NSE-equity-xts-api-HFT-system | NSE equity via Symphony XTS broker API |
| NSE-derivatives-xts-api-HFT-system | NSE F&O via Symphony XTS broker API |
| forex-HFT-market-making-algorithmic-trading-bot | Forex making, FIX, kernel-bypass networking |
| crypto-exchange-projects | Exchange engineering reference — spot, perps, options, matching engines |
Related: Prediction Market Systems · Algorithmic Trading