Nairobi, Kenya · UTC+3 · Open to senior and staff-level systems roles
I am a systems engineer focused on Rust, Solana infrastructure, low-latency DeFi execution, and concurrent software.
For the past three years, I have designed and evolved a proprietary multi-DEX arbitrage platform that owns the complete path from a market update to a landed transaction: streaming data, coherent state, AMM integration, route discovery, sizing, local simulation, transaction construction, leader-aware delivery, and post-trade forensics.
I enjoy systems where correctness has a deadline and where “fast” is meaningless unless the state, economic assumptions, and final outcome can still be justified.
shreds / gRPC / WebSocket
│
▼
transaction-aware settlement
│
▼
immutable market snapshots + version vectors
│
▼
newest-wins scheduling ──► sizing / SIMD / LiteSVM
│
▼
commit-time revalidation ──► v0 tx / ALTs / landing
│
▼
inclusion + realized PnL + causal forensics
let principles = [
"coherent state > fast incoherence",
"bounded work > perfectly processed stale backlogs",
"measured ownership > unexplained RSS",
"on-chain invariants > off-chain confidence",
"landed outcomes > send acknowledgements",
];| System | What I worked on | Evidence |
|---|---|---|
| iQuant arbitrage engine | A large Rust/Solana execution platform spanning ingest, AMM models, concurrent evaluation, local SVM simulation, transaction landing, safety controls, and forensics. | Engineering case study |
| Marginal Price Optimization | Translated AMM routing research into Rust with curve abstractions, log-price Newton solving, SVD fallback, replay feeds, and explicit convergence gates. | Applied research case study |
| Aegis / Athena OS installer | Native Linux installation workflows with Svelte, Tauri, Rust, disk operations, configuration validation, and asynchronous progress reporting. | System case study · Repository |
| Basicrum ingestion service | Deployed and operated a Go real-user-monitoring ingestion boundary covering normalization, ClickHouse persistence, recovery archives, TLS, and container delivery. | Operations case study · Repository |
The private trading-system repository currently represents approximately:
- 86k+ lines of Rust in the core engine.
- 197 core source modules and 450+ core test functions.
- 1,070+ commits across three years of sustained development.
- 48 protocol integration directories, covering heterogeneous AMM and execution models.
These numbers describe engineering scope—not trading performance. I do not publish revenue, win rate, or latency figures that cannot be independently reproduced.
Hot path: Rust, Tokio, atomics, ArcSwap, bounded channels, Rayon, SIMD, custom allocators
Solana: accounts, transactions, Anchor, SPL, ALTs, durable nonces, Yellowstone gRPC, ShredStream, LiteSVM
Operations: Linux, Axum, ClickHouse, Redis, PostgreSQL, Docker, Kubernetes, observability, memory and failure forensics
I write about the engineering behind latency-sensitive blockchain systems:
- A Blockchain Trading Engine Is a Distributed Systems Problem
- Building Coherent Solana Market State
- Choosing Rust Concurrency Primitives for a Trading Engine
- MEV Forensics: Determining Why an Opportunity Died
- A Leak Is a Slope
- Put the Final Profit Guard On-Chain
If you are building trading infrastructure, protocol software, low-latency services, or difficult stateful systems, I would be glad to talk.
Email: mwaurawakati@gmail.com
LinkedIn: linkedin.com/in/mwaurawakati
Portfolio: github.com/mwaurawakati/portifolio
observe → model → constrain → execute → verify



