The matching-engine + order router side of perp DEX. we sit between your strategy and the venue — your stack reads the book and sends orders; we own the round-trip latency, the venue connectivity, and the kill-switches. On-chain perpetual exchange — order book, oracle, liquidation — but specifically, the trading infrastructure layer of it.
explicit deliverables for this use-case. additional trading infrastructure pieces stay in scope.
on-chain perpetual exchange — order book, oracle, liquidation.
the execution stack underneath your edge.
not what we built (we don't kiss-and-tell client work), but the shapes-of-the-problem we anchor scope against.
The matching-engine + order router side of perp DEX. Specifically: we sit between your strategy and the venue — your stack reads the book and sends orders; we own the round-trip latency, the venue connectivity, and the kill-switches.
Reference points we look at when scoping: Hyperliquid HLP-style vault structure, dYdX v4 keeper bots, Drift v2 JIT auctions. We don't copy them; they're shapes-of-the-problem.
perp DEX touches multiple disciplines. We split the work along service lines so each engagement has a single scope. If you need more than one side, we'll scope a second engagement (or a combined one) — but a single trading infrastructure pod is usually the right starting shape.
Book a call. 30 minutes, no NDA, no slide deck. We tell you what scope of work looks like or refer you elsewhere if we're not the right team.