Execution is the real problem in crypto

The model is not the hard part. In crypto trading, the hard part is turning a decision into a fill — across venues that lie, disconnect, and disagree with each other. Execution is where the edge is won or lost.

Every crypto trading firm I've worked with eventually runs into the same wall: you can reproduce a strategy, but you can't reproduce an execution stack. Hand two desks the exact same model and they'll post different numbers, because everything between the signal and the fill is built differently. That gap is where the real edge lives, and it's the part nobody can copy off a whitepaper.

The market is fragmented by design

Liquidity for one instrument is scattered across dozens of venues — centralized exchanges, DEXs, aggregators, OTC desks, cross-chain bridges. No two of them share an API, a fee model, or the same set of order types, and they certainly don't break in the same way. An order book on one exchange isn't really the same kind of object as the order book on another, even when it's nominally the same pair.

Treat these venues as interchangeable and you'll underperform, full stop. Treat each one as its own animal — its own connector, its own failure modes, its own latency profile — and now you've got the option to route where it actually makes sense. That option is the edge.

State is inconsistent by default

Submit one order to one venue and there are already three separate things your system has to reconcile afterward:

1. The order reaches the venue. Or it doesn't.
2. The venue acknowledges it. Or it times out and leaves you guessing.
3. The order fills — partially or fully — in a sequence that may or may not line up with your system's view of when things happened.

Now run that across five venues at once. What you've built is a distributed system with no global clock and no shared state, full of components that disagree with each other as a matter of routine. None of that is an exotic edge case — it's the normal weather of running infrastructure, and it shows up on an ordinary Tuesday.

The systems that cope with this well tend to share a few habits:

• They sequence events locally. Fills, acks, cancellations — all of it gets ordered by when your system saw it, not by whatever timestamp the venue swears by. And when those two disagree, that disagreement is itself an event worth recording.
• They reconcile continuously. Every position you think you hold gets checked against what the venue reports, on an interval the desk can live with. When the two drift apart, that kicks off reconciliation. It shouldn't kick off panic.
• They keep state local. Your own state store is the source of truth for trading decisions. A venue is only authoritative about its own slice of the world, nothing more.

Venues fail in asymmetric ways

An exchange going fully dark is the easy case — you notice it immediately. The quieter failures are the ones that actually cost you money:

• An exchange keeps accepting orders but quietly delays the fills by ten seconds.
• An exchange acks an order, then later acts like it never saw it.
• An exchange's WebSocket feed shows you one position while its REST endpoint shows another.
• An exchange's rate limit trips right in the middle of a fast move — exactly when you need to be doing something.

If your system never modelled these cases, it'll just log them as exceptions and move on. If it did model them, each one becomes a trigger — reroute, cut exposure, or halt. What separates the two systems isn't the code. It's the assumptions you baked in before you wrote a line of it.

The hot path must be dumb

In a well-built execution system the hot path — signal to order — should be as boring as you can make it. It doesn't validate deeply, it doesn't reconcile, and it definitely doesn't sit there thinking. It checks a handful of invariants, fires the order, and writes down what it just did. That's it.

Everything else lives on the cold path — reconciliation, exposure, P&L, monitoring, compliance. The cold path gets to be slow, durable, and as complicated as it needs to be. The hot path stays fast and narrow, and it's allowed to fail, precisely because the cold path is sitting behind it watching.

When people mix the two, it goes wrong in one of two directions. Either the hot path starts doing cold-path work and gets slow, so you lose trades to latency. Or someone strips out the cold-path work because it was slowing things down, and now silent drift piles up until something finally snaps. I've watched both happen, and the second one is worse because it stays invisible right up to the moment it isn't.

The edge is in the architecture

Strategies get copied. Models get replicated. The public information edge in crypto is thin and getting thinner by the month. The one thing nobody copies is your execution architecture — it's invisible from the outside, expensive to build, and it only really gets good after years of production incidents have beaten the rough edges off it.

Alpha compounds through execution. Bad execution subtracts more than good signals add.

Over any timeframe worth caring about, a desk with a so-so model and great execution beats a desk with a great model and sloppy execution. That's not a hot take. Decompose the P&L and it's right there in the numbers.

What to build first

Building a crypto trading system from scratch? Build the execution stack first. Strategy research can limp along on paper trading or a small live sleeve for a while. The execution architecture — connectors, state, reconciliation, the risk layer — is the part that takes six months to stand up and a couple of years to actually harden. So start there, while you still have the patience for it.

And if you already have a system that's bleeding money in ways you can't pin on the signal, I'd bet the problem is in the execution stack. That's where I'd look first. That's almost always where the leaks are.

Ignacio Montoya is a systems architect specializing in algorithmic trading infrastructure, financial systems, and digital asset platforms. He designs and operates crypto execution systems with unified state, multi-venue routing, and programmatic risk controls.