Technology for Crypto Exchanges and ECNs

What a venue operator has to build

An exchange or ECN is mostly a set of systems that must agree with each other under load.

• A matching engine that applies price and time rules to incoming orders.
• Order entry and market data connectivity that participants can integrate against.
• Pre-trade risk controls that stop bad orders before they reach the book.
• A ledger and settlement process, tied to custody.
• A front end for the traders who use the venue.

An ECN, or electronic communication network, is a venue that matches buyers and sellers directly without acting as the counterparty itself. Liquid Mercury, the Chicago-based institutional digital asset infrastructure provider, builds this layer for operators; the operator runs the venue and holds any licenses it needs. For regulated venue questions see alternative trading systems. In the EU, trading venues are regulated under MiFID II and MiFIR.

The matching engine

The matching core is the order-matching engine that Mercury OTC and Mercury Pro can each run on. It handles single-leg and multi-leg orders across spot, futures, perpetuals and options.

The engine maintains implied quotes in both directions, so multi-leg orders imply single-leg markets and single-leg markets imply multi-leg markets. When the best bid or offer changes in one book, the related implied quote is updated directly from the difference rather than being recalculated from scratch. Implied quotes are top of book only and are calculated outside the matching engine.

Three tiers

Order flow moves through three tiers that scale independently of each other.

Connection tier

The connection tier takes orders in over REST, WebSocket and FIX 4.4 APIs. It supports order entry, RFQ and block-type workflows. Before an order reaches the book, pre-trade checks cover order size, price reasonability and rate limits. The same tier supports spot, futures, perpetuals and options. See venue connectivity for protocol detail and the FIX protocol glossary entry.

Order book tier

The order book tier does the matching. It holds single-leg and multi-leg books and keeps implied markets in step between them. The design keeps the minimum logic necessary in the order book, with pre-processing and post-processing pipelined to increase capacity while preserving message sequence.

Market data tier

The market data tier sends results back out to participants. It disseminates aggregated market data over a unicast connection, with top-of-book implied quotes. Mercury Pro displays Level II and Level III order book depth to its users.

Horizontal scaling and resilience

The connection, order book and market data tiers can scale horizontally and independently. Load balancing and failover are available in each tier, and the Playbook describes each tier mirroring its state to secondary and disaster-recovery instances.

Performance, as reported from a broker-dealer build

Published throughput and latency figures for any matching engine should come with test conditions. Ask any vendor for the message rate, the per-order latency, the hardware used and whether the figures come from a crypto venue or from another market.

Participants, orders and risk

Entities and users are managed in a flexible hierarchy that supports nested entities. Users and entities can be created, enabled and disabled but are never deleted, only marked disabled and archived, which preserves the audit trail. Orders, legs and order reports follow the same rule.

Orders can be single or multi-leg, with FIX-format order and execution report messages. Status and report types are recorded for each event, including fills, cancels, rejects and trade cancels.

Risk sits in front of the book. The Risk Engine rejects an order if any configured threshold or limit is breached, and the kill switch lets authorized administrators halt trading across supported exchanges and accounts. Ask any vendor whether market state changes and circuit breakers that pause a market on a price move are shipped or still in development.

Ledger, custody and front end

Mercury Ledger provides real-time position keeping and reconciliation across fiat and tokens, with BitGo custody integration and delivery versus payment settlement in the tokenized asset stack. Traders can reach a venue through Mercury Pro, which supplies order management, smart order routing and algos on top of the venue's matching infrastructure. If you are planning a white-labeled venue, see white label crypto exchange. The BIS Principles for financial market infrastructures explain why linking the two legs of a trade matters.

How the pieces fit together

The platform is modular. Each component works independently or together, so a venue operator can adopt the matching core, the front end and the ledger separately. Mercury OTC adds RFQ, RFS and streaming quotes for venues that want a dealer workflow next to the book.