[00]Projects
The work, with the hard parts left in.
Contract work, start to finish. Real numbers, named stacks, and the problem in each one that took the longest to solve.
Ostium
Contract senior engineer · 2026 – ongoingA hedging engine holding market exposure for a $38B exchange.
- volume
- $38B+volume
- end to end
- <50msend to end
- broker integrations
- 6+broker integrations
- assets and tick rate
- 10×assets and tick rate
Context
Perpetual futures exchange backed by General Catalyst and Jump Crypto. I architected the Go hedging engine from zero to one: the system that manages the exchange’s market exposure.
The part that was hard
Always-on inside a 50ms ceiling leaves no room for a human to step in. It degrades correctly on its own or it loses money. Then the same system had to carry ten times the assets at ten times the tick rate, on the same latency budget.
What I built
- Hedging engine from 0 to 1, running 24/7 with end-to-end execution under 50ms
- Scaled the pricing system from a 100-asset cap to 1000+, and the tick rate from 1/second to 10+/second: 10× on both axes
- High-throughput ingestion for real-time order flow and pricing
- Modular, fault-tolerant architecture so core logic could iterate while market-maker integrations scaled in parallel
- Async data pipelines feeding high-fidelity market data to risk for backtesting
- Automated reconciliation and circuit breakers for extreme volatility
- Go
- AWS
- Postgres
- WebSockets
QA agent pipeline
Contract · Jan – Mar 2026PRDs in, reviewed test plans out. 60% of the cases run without a human.
- fewer production bugs
- 40%fewer production bugs
- fewer regression bugs
- 30%fewer regression bugs
- cases run without a human
- 60%cases run without a human
- LLM calls in CI
- zeroLLM calls in CI
Context
A games studio where QA read every PRD by hand and wrote the test cases from it. That’s slow, so a full regression pass only happened near release. Which is exactly when a bug costs the most to fix.
The part that was hard
The classification. Every case gets labelled automated, AI-manual or human before anything runs, and being wrong either way kills the tool. Over-automate and QA stops trusting the results. Under-automate and you’ve built an expensive way to write documents. Get that line right and the rest follows: tests cheap enough to run constantly, and QA spending their hours on the cases that needed a person.
What I built
- Knowledge base ingest over Confluence (photos, renders, past PRDs and supporting docs) so generated cases matched how the product actually behaves
- Incremental PRDs: each revision generated against what changed, not the whole spec every time
- Every case emitted with a title, steps, acceptance criteria and a run type: automated, AI-manual or human
- A parallel path pulling the relevant regression cases out of the existing corpus rather than regenerating them
- Both paths assembled into one test plan a human reviews and edits (add, remove, update) before anything runs
- Three execution lanes in parallel: automated tests generated and run, AI-manual runs executed and documented, human cases routed to people
- Approved automated tests promoted into CI, where they run with no model in the loop
- Cost controls throughout: per-stage model selection through OpenRouter, prompt caching over the stable knowledge-base context, runs traced in LangSmith
- Python
- LangGraph
- LangSmith
- OpenRouter
- AWS
- pytest
Rage Trade
Contract tech lead · 2021 – 2025$6B+ in trades routed across 8+ exchanges.
- volume routed
- $6B+volume routed
- exchanges
- 8+exchanges
- latency cut
- 50%latency cut
- TVL in vaults
- $15M+TVL in vaults
Context
Perpetual futures aggregator routing across 8+ exchanges on EVM and SVM chains, investors including OKX and Zee Prime Cap. I owned full-stack architecture and delivery, joining as a smart contract engineer and leaving as tech lead.
The part that was hard
Eight venues that disagree about settlement, precision and failure semantics, all surfaced to users as one interface. Adding a venue was the bottleneck. I built reusable tooling and automated tests around it and roughly halved that time.
What I built
- NodeJS microservices platform on AWS ECS with zero-downtime CI/CD
- Data layer moved to event-driven WebSockets, cutting trade latency 50%
- Modular SDK decoupling UI from exchange logic, enabling parallel work
- Seeded USDC liquidity mechanism for Hyperliquid’s HIP-2, part of the core protocol
- Technical execution of a token sale that raised $6M in under 30 minutes
- ERC-4626 vaults integrating GMX, Aevo and Uniswap, holding $15M+ TVL
- TypeScript
- Node
- AWS ECS
- Solidity
- Postgres
octomux
Built and maintained · 2026 – presentMulti-agent orchestration, in the open.
- lines TypeScript
- 158klines TypeScript
- commits
- 1,655commits
- test files
- 399test files
- agent harnesses
- 2agent harnesses
Context
A platform for running autonomous coding agents on real repositories: an isolated git worktree and tmux session per task, pluggable harnesses, automated PR review gating merges, and scheduled crews that run unattended.
The part that was hard
Agents that write code are only useful if you can trust the diff. Almost none of the work is the agent itself. It’s isolation, review gates, spend caps and recovery, which is the same discipline as trading infrastructure: evals are risk controls, guardrails are limit monitoring, spend caps are position limits.
What I built
- Task orchestration with one isolated workspace per run, so parallel agents cannot collide
- Pluggable harness layer: Claude Code and Cursor, swappable
- Multi-lens automated PR review before anything merges
- Scheduled agent crews, cron-driven, unattended
- Per-task model routing and crash-resume for in-flight work
- TypeScript
- Node
- SQLite
- tmux
- git
Have something like this to build?
Scope and cost get decided on the call, against your actual problem. Thirty minutes is usually enough to tell whether it’s worth either of our time.