Matchstick v0.0.2: The Bugs That Would Have Cost You Money
Three critical order execution bugs found before launch. How stress testing prevented production losses, and why we're building a demo-first trading engine.
Three weeks ago, stress testing revealed bugs that would have caused unintended position exposure in production. Orders could overfill by 5% under load. Floating-point rounding errors could leave phantom positions on your books.
We found these before anyone lost money.
Today, weâre open-sourcing a demo version of Matchstickânot to show off features, but to demonstrate how we think about correctness in trading systems.
The bugs we caught, the tests we wrote, and the architectural decisions we made are all public.
đ Public Repository Launch
Whatâs Public:
Demo CLI, TUI, core architecture, full documentation.
Whatâs Proprietary:
Production engine with 50+ indicators, custom metrics system (5,458 LOC), risk models, broker integrations, full test suite (290+ tests).
The demo shows our engineering quality. The proprietary code is the business.
Repository: github.com/watthem/matchstick-trading
đ Critical Bugs Fixed
While preparing for the public launch, stress testing revealed three critical bugs in our order execution system:
1. Order Overfilling: The 5% Position Risk
What Happened: Race conditions in concurrent order processing allowed fills to exceed requested quantities.
Real-World Impact: A $100,000 order could become $105,000. In volatile markets, that extra 5% exposure could force margin calls or unwanted liquidations.
Why It Matters: Most trading platforms assume orders are atomic. Theyâre not. Under load, microseconds matter.
The Fix: Atomic validation before state changes. Added 6 concurrency stress tests simulating 100 threads hitting the same order.
2. Floating Point Position State
What Happened: Position checks used exact equality (quantity == 0.0), which fails after multiple trades due to floating point arithmetic.
Real-World Impact: After a round-trip trade (buy then sell same quantity), residual like 0.0000000001 shares makes the system think you still have a position. Wrong risk calculations, incorrect margin requirements, flawed strategy state.
Why It Matters: Floating-point math looks fine until it isnât. One missed epsilon comparison can corrupt position state across your entire system.
The Fix: Epsilon comparison (abs(quantity) < 1e-8) treats tiny residuals as zero throughout the codebase.
3. Average Fill Price Edge Cases
What Happened: Division by zero wasnât handled when calculating average fill price.
Why It Matters: Financial calculations should never panic. Period.
The Fix: Defensive programming with proper error handling throughout financial math.
Testing Philosophy: We donât test to hit coverage targets. We test to simulate failure modes. If it can break in production, it should fail in CI first.
đď¸ Code Reuse Without Microservice Hell
Weâre building multiple interfaces (CLI, TUI, web dashboard) that share the same trading logic. Most teams solve this with microservicesâwhich means distributed systems complexity, network latency, and deployment nightmares.
Weâre taking a different approach: write components once, combine them into single binaries for each interface. No network calls, no service meshes, no kubernetes YAML.
The Result: CLI and TUI share 80% of their code, but each ships as a standalone binary. Same correctness guarantees, zero operational overhead.
What We Shipped:
- Indicators library (16 technical indicators)
- Order management (shared across all interfaces)
- Risk validation (same rules everywhere)
- Core types (Position, market data primitives)
Next: Complete extraction of backtesting engine, metrics system.
đ Technical Indicators: When TradingView Gets It Wrong
We added 4 volume-based indicators, but more importantly, we found calculation errors in widely-used indicators.
Example: Stochastic %D was using the wrong smoothing method. ADX wasnât applying Wilderâs smoothing correctly.
The Problem: Most platforms copy formulas from tutorials and assume theyâre right. When TradingView and Bloomberg disagree, retail traders have no way to know which one is correct.
Our Approach: Verify against academic papers, test against published benchmarks, document every decision.
Result: Indicators that match institutional-grade calculations, not copy-pasted approximations.
𧪠If It Can Break in Production, It Should Fail in CI
Stress test example: 1,000 orders submitted across 100 threads. Half get canceled mid-fill. 20% get amended. Final position state must match expected exposure exactlyânot âclose enough.â
Why This Matters: Development environments are calm. Production has race conditions, network failures, and state corruption. Testing in production costs money. Testing in CI is free.
What We Learned Building This
Concurrency bugs are silent killers. They donât show up in development. You only find them when 100 orders hit the same execution path simultaneously. Write stress tests that mirror production load, not happy-path scenarios.
Floating-point math will betray you. After a round-trip trade (buy 1000, sell 1000), you donât have zero sharesâyou have 0.0000000001 shares. Use epsilon comparisons (abs(quantity) < 1e-8) everywhere. Check your position state after every operation.
Architecture decisions compound. Building for code reuse now means we wonât rewrite the entire system when we add web dashboards. The upfront cost of good architecture is always cheaper than the late cost of technical debt.
Solo founders ship late. Toddler nap strikes happen. Real life interrupts. Better to ship correct than fast. In trading, bugs cost real moneyâdelays just cost time.
Whatâs Next
v0.0.3 ships mid-October with short position edge case handling, backtesting engine preview, and full numerical accuracy verification for all 50+ indicators.
Who This Is For
If youâre a developer building trading systems: The public repo shows our engineering approach. Clone it, review the tests, see how we handle concurrency.
If youâre a trader evaluating platforms: Ask your vendors how they test for race conditions and floating-point errors. Most canât answer. We publish our tests.
If youâre an investor evaluating trading infrastructure: The demo proves engineering quality. The proprietary code (50+ indicators, custom metrics, risk models) is the business. Weâre building both.
Get Involved
git clone https://github.com/watthem/matchstick-trading
cd matchstick-trading
cargo build --release
./target/release/matchstick-cli playTechnical questions: GitHub Discussions
Partnership inquiries: hello@matchstick.trading
Security issues: security@matchstick.trading
v0.0.2 caught three production-breaking bugs before launch. v0.0.3 will catch more.
Matchstick ⢠Cross-platform trading engine ⢠matchstick.trading
đĽ Get Dev Updates
Breaking changes, new features, and critical updates delivered instantly
Real-time notifications when we ship. No fluff, just the code.