SKM.
Resume

DOCUMENT LIBRARY

Resume / PDF

Software Engineering Resume

Systems, software, and engineering work.

Resume / PDF

Machine Learning / AI Resume

Machine intelligence and applied research.

Resume / PDF

Quantitative Research Resume

Quantitative research and performance-oriented computing.

Find your way

↑ ↓ to select · enter to open · esc to close

← Back to projects

Quantitative Finance / Independent exploration

TradeCore

A bounded-memory matching-engine prototype, examined through correctness invariants and the limits of its latency claims.

2026-11-09 / 2 MIN READ

Problem

An exchange-style order book must maintain price priority while handling partial fills and conserving volume. TradeCore explores how preallocated storage and explicit invariants can make this behavior inspectable.

Architecture

The inspected matcher applies a templated risk pipeline, scans liquidity for fill-or-kill requests, matches against the opposite book side, and inserts residual limit orders. AVL price levels and pooled orders separate price lookup from order storage.

01Risk checks02Order book03Fill records
Conceptual workflow — not a verified implementation

Implementation

The risk pipeline evaluates a tuple of rules using a short-circuit fold expression. The matcher contains debug assertions for trade quantities, resting prices, and the conservation of filled plus remaining volume. StaticVector uses inline arrays rather than an unbounded result container.

Engineering decisions

Fixed capacities make memory budgets explicit, but capacity exhaustion needs defined behavior. The implementation uses steady-clock timestamps; deterministic book-state reconstruction should not be confused with byte-identical timestamped outputs.

Results

VERIFIED by source inspection: price-constrained matching, compile-time risk-rule composition, and conservation assertions exist. DOCUMENTED only: allocator timing artifacts and README latency contracts. The contracts are targets, not independently measured P99 results.

Limitations

The fill-or-kill prescan counts total opposing liquidity without receiving a limit price, whereas the matching loop enforces that price. This can admit a request that cannot be completely filled at its limit. RiskResult contains std::string and long rejection messages, so a universal zero-allocation claim is unsupported. The contract checker can report success when no matching benchmark rows exist. No institutional-readiness claim is made.

Reproducibility

Reviewed at commit fed1e79d7d14 on 2026-11-09. Source inspection establishes implementation structure; repository-authored results are not independent measurements. The upstream application and benchmark suite were not rerun during this review.

Next investigation

Resolve the limitations above, preserve the reviewed commit and exact experiment configuration, and reproduce correctness checks before promoting performance or deployment claims.

Links and citation

Source code ↗