Order execution engine
Limit, stop, DCA and TWAP orders on EVM and Solana, now in Rust.
- Role
- Main author; led the TypeScript-to-Rust migration
- Stack
- TypeScriptRustaxumRedis StreamsTurnkey
Boba's order engine watches prices and executes limit, stop-loss, take-profit, DCA and TWAP orders on users' behalf — including cross-chain orders through Relay and LiFi — signing server-side with Turnkey.
I wrote most of the TypeScript engine, then, after a teammate scaffolded a Rust port, aligned it with production behavior, hardened the execution pipeline, and cut deploys over to it.
Decisions
Rust, for throughput at flat memory
The order logic worked in TypeScript; the runtime was the limit. An order engine watches prices for every open order and has to react the instant one crosses, so I moved it to Rust: high throughput with flat memory, no garbage-collector pause mid-trigger, one binary.
It also sets up the next step. The engine and the Solana sender now share a language, so the send path can move in-process, putting price watching, signing and landing in one service with one less network hop per trade.
We benchmarked it honestly. Rust was slower at one thing, serializing orders to match V8's number formatting for the shared Redis schema, at about 2µs per order. That's noise next to a network round trip. The real ceiling is Redis round trips, not the language.
Zero downtime by design
The Rust engine reads and writes the same Redis schema as the TypeScript one, so both ran side by side on live orders. Rollback meant stopping one process.
What I built
- A mainnet "snipe mode" for Ethereum: fan-out to block builders, p75 priority fees, gas margin, pre-flight balance checks and a public-mempool fallback.
- Retry logic that only widens slippage for slippage failures — up to 3×, capped at 50%, and never loosening a tolerance the user set themselves.
- Per-wallet nonce lanes, revert-reason decoding, bundle simulation, and gas caps when a bridge quote asks for too much.