The parts of building an exchange nobody warns you about

A founder's guide to what's actually hard, and what it costs when you get it wrong.

Building a crypto exchange looks deceptively simple on a whiteboard. Users deposit funds, place buy and sell orders, the system matches them, everyone gets their fills. A small team, a few months, and you're live. That's the plan almost everyone starts with.

Then you start building the matching engine, and the whiteboard falls apart.

The order-matching core, the thing that pairs buyers with sellers, is where most of the real engineering risk of an exchange lives. It's also the part founders consistently underestimate, because "match a buy order with a sell order" sounds like a sorting problem you'd solve in an afternoon. It isn't. Here's what's hiding underneath, and what each hidden cost actually looks like when it goes wrong.

Orders you cannot afford to lose

An exchange makes a promise: when you place an order, it counts. Not "usually." Always. The moment a trader can't tell whether their order went through, you have a support nightmare, a trust problem, and potentially a financial liability, because they may have hedged, re-ordered, or moved size elsewhere assuming the first order was live.

Now add the reality that servers fail. Hardware dies, processes crash, networks partition. A serious exchange has to keep running through a node failure without dropping a single in-flight order. That means consensus across multiple machines, automatic failover, and a replayable log: distributed systems work that is genuinely hard to get right and unforgiving when you don't. Teams routinely spend months here and still ship subtle bugs that only surface under real load.

Money math that has to be exact

Here's a mistake that has taken down real systems: representing money as a floating-point number. Use a normal double for balances and prices, and tiny rounding errors accumulate. Over millions of trades, the books stop balancing. Someone's balance is off by a fraction of a cent, then a cent, then enough that an auditor notices.

Exact money math means integer-based, fixed-point arithmetic throughout: every price, every quantity, every fee, calculated so that what the buyer pays and what the seller receives reconcile perfectly, forever. It sounds pedantic until it isn't. And it has to be threaded through every calculation in the system, not bolted on later.

The day volume spikes

Your exchange will have its best day and its worst day on the same day: the day it goes viral, or a market moves violently and everyone trades at once. That's precisely when a naively built engine falls over: memory balloons as queues back up, latency climbs, and the system either crashes or grinds to a halt at the worst possible moment.

Building for predictable behavior under overload (shedding load gracefully, staying inside a fixed memory budget, never letting a traffic spike become an outage) is a different discipline from making something work in a demo. It's the difference between a system that survives its own success and one that doesn't.

The checks that stop a catastrophe

Before an order ever reaches the book, it should pass through a gauntlet: does the user have the balance? Are they within position limits? Is the price sane, or a fat-fingered order three orders of magnitude off? Are they hammering the system faster than allowed? Is the market in a state where trading should be halted?

Skip these pre-trade risk checks and a single bad order (malicious or accidental) can drain an account, crater a market, or expose you to losses you can't recover. This is safety-critical code, and it has to run in the same sub-millisecond budget as everything else.

The cost you feel last: time

Add it up. Distributed consensus and failover. Exact money math. Overload behavior. A real risk pipeline. Market data that streams a consistent view to every trader at once. Each of these is months of specialist work, and they all have to be correct, not "mostly working," but correct, because they sit directly on top of other people's money.

The true cost isn't just the engineering hours. It's the opportunity cost: every month your best people spend rebuilding a matching engine is a month they're not spending on the things that actually differentiate your exchange: your markets, your product, your customers, your path to being compliant and licensed. Nobody chooses your exchange because your order book is array-backed. They choose it for the experience and the trust you build around it.

The reframe

The hard, risky, undifferentiated core is the part to not build from scratch. Your edge is everywhere else.

That's why we built Open Exchange and made the core open source under Apache 2.0. It's the matching engine, the pre-trade risk pipeline, an internal double-entry ledger, and real-time market data: the parts that are brutally hard to build and dangerous to get wrong. In our own benchmarks it matches orders in a fraction of a microsecond and sustains hundreds of thousands of orders per second at full load, survives node failures without losing an order, and stays inside a fixed memory budget under overload. (Those numbers come from a single-box development rig, not a production deployment; we publish the setup and the caveats openly, including a bug we found pushing it to its limits.)

It's beta software (v0.4.0-beta, with a frozen public API), and it should have an external security audit before it ever handles real money. And to be clear about the boundary: Open Exchange gives you the engine. Identity, custody, fiat rails, and regulatory compliance are still yours to own and integrate, though helping with those is where we're headed next.

What you get today is the ability to skip the riskiest year of the build and start from a core that already works, in the open, with no black box and no vendor lock-in. You read the code, run it yourself, and put your time where it counts.

If you're weighing whether to build or borrow the core of your exchange, read the code, try the live demo, or dig into the engineering deep-dive on how the order book actually works.