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 eventually discovers the same truth: the strategy is reproducible, the execution is not. Two firms running the same model get different results because they run different execution stacks. The architecture between the signal and the fill is where the actual edge lives.

The market is fragmented by design

Liquidity for the same instrument sits across dozens of venues: centralized exchanges, decentralized exchanges, aggregators, OTC desks, cross-chain bridges. No two venues have the same API, the same fee model, the same order types, or the same reliability characteristics. An order book on one exchange is a different object from an order book on another, even for the same pair.

A trading system that treats these venues as interchangeable is guaranteed to underperform. A system that treats them as distinct — with their own connectors, their own failure modes, their own latency profiles — has the option to route intelligently. That option is the edge.

State is inconsistent by default

When an order is submitted to a venue, three things happen that the system has to reconcile:

1. The order reaches the venue — or does not.
2. The venue acknowledges — or times out.
3. The order fills, partially or fully, in some order that may or may not match the system's view of time.

Multiply this across five venues running simultaneously, and the system is a distributed system with no global clock, no shared state, and components that routinely disagree. This is not an exotic failure mode. It is Tuesday.

The systems that handle this well do three things:

• They sequence events locally. Every fill, acknowledgement, and cancellation is ordered by when the system receives it, not by when the venue claims it happened. Divergence between the two is itself an event.
• They reconcile continuously. Every position the system believes it holds is compared against the venue's own report, at an interval the firm can tolerate. Drift triggers reconciliation, not panic.
• They keep state local. The system's own state store is the source of truth for trading decisions. The venues are authoritative only for their own slice.

Venues fail in asymmetric ways

An exchange going down is the obvious case. The less obvious cases are where the real damage happens:

• An exchange accepts orders but delays fills by 10 seconds.
• An exchange acknowledges an order, then later denies it ever received it.
• An exchange's WebSocket reports one position while its REST API reports another.
• An exchange's rate limit kicks in during a market move — exactly when the system needs to act.

A trading system that does not model these cases treats them as exceptions to log. A trading system that does model them treats each one as a signal to reroute, to reduce exposure, or to halt. The difference is not code. The difference is assumptions.

The hot path must be dumb

In a well-designed execution system, the hot path — the path from signal to order — is as simple as possible. It does not validate deeply. It does not reconcile. It does not think. It checks a small set of invariants, submits the order, and records what it did.

Everything else runs in the cold path: reconciliation, exposure calculation, P&L, monitoring, compliance. The cold path is allowed to be slow, durable, and complex. The hot path is fast, narrow, and allowed to fail, because the cold path is watching.

Systems that mix these paths fail in two ways. Either they become slow because the hot path is doing cold-path work — and lose trades to latency. Or they skip cold-path work because it slowed them down — and accumulate silent drift until something breaks.

The edge is in the architecture

Strategies get copied. Models get replicated. The public information edge in crypto is thin and getting thinner. What does not get copied is the execution architecture — because it is invisible, it is expensive to build, and it takes years of production incidents to tune.

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

A firm with a mediocre model and great execution outperforms a firm with a great model and mediocre execution, over any interesting timeframe. This is not opinion. It is what the P&L shows when you decompose it.

What to build first

If you are building a crypto trading system from scratch, build the execution stack first. Strategy research can use paper trading or a small live sleeve. The execution architecture — connectors, state, reconciliation, risk layer — is the part that takes six months to build and two years to harden. Start with it.

If you already have a system and it is losing money in ways you cannot attribute to the signal, the problem is almost certainly in the execution stack. That is where to look. That is 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.