Crypto Venue Connectivity: FIX, REST and WebSocket

Supported venues, liquidity providers and custodians

The table below is the page's answer to the qualifying question. It reproduces the connectivity list Liquid Mercury publishes on its Mercury Pro page, which also states "50+ Venues Connected" across exchanges, OTC desks and liquidity providers. Connection type and the date each connection was last confirmed are not published, so they are not stated here.

The roster was read from the Mercury Pro page on 2026-10-14 and checked against venue notices on 2026-10-20. GFO-X is excluded because it ceased activities and revoked participant, vendor and client connectivity in September 2026 (GFO-X Market Notice 013/2026). Confirm active connections and instrument coverage for your deployment.

If a venue you need is not on the list, ask any vendor how a new connection is requested and how long it takes. Desks that run an OTC business should also read Mercury OTC, which covers custody, KYC and liquidity provider connections for white-label desks.

Why connectivity is the hard part of crypto execution

Most of the work in running a multi-venue desk is not placing an order. It is placing the same kind of order on many venues that each speak a slightly different language.

Crypto liquidity is fragmented. Spot, perpetuals, futures and options trade on different exchanges, and large size often trades with OTC liquidity providers instead. Each venue has its own API conventions, its own order types, its own rate limits and its own way of reporting a fill. Contract sizes, quantity units and position conventions differ from one venue to the next.

Markets also never close. A connection that drops overnight, or a venue that changes an endpoint, becomes a trading problem immediately. A platform that handles connectivity well hides these differences, so a trader sees one order ticket and one set of positions. A platform that does not leaves the desk to write and maintain adapters for every venue.

Three questions follow from this. How will the desk talk to the platform? How does the platform talk to each venue? And are risk and positions calculated the same way everywhere?

API types and when to use each

The Mercury Pro API suite offers FIX, Binary, REST and WebSocket APIs for buy-side and sell-side workflow automation. The connection tier described in the Liquid Mercury architecture takes inbound connections over REST, WebSocket and FIX 4.4 for order entry, RFQ and block-type workflows, with support for spot, futures, perpetuals and options. FIX is maintained by the FIX Trading Community. It also publishes work on the FIX session layer.

For background on the protocol itself, see the FIX protocol glossary entry. The FIX Orchestra standard describes a machine-readable way to document how a venue uses FIX.

Choosing between them

• A systematic desk that streams prices and trades often typically uses WebSocket for market data and either WebSocket or FIX for orders.
• A broker with existing sell-side systems typically uses FIX, because its other systems already speak it.
• An operations tool that reads balances or submits occasional orders typically uses REST.
• A desk moving between OTC and exchange venues often mixes them: FIX or REST for order entry and WebSocket for the price stream. Whether a platform supports both on the same account is a fair question to ask any vendor.

What to connect to

A desk's connection list falls into three groups.

Exchanges. Venues with central order books for spot, perpetuals, futures and options. Some also offer request-for-quote (RFQ) functions for block trades.

OTC liquidity providers. Dealers and market makers who quote firm prices for larger size, by RFQ, request for stream or streaming quotes. See liquidity aggregation.

Custodians. Where the assets are held, and the source of balances and transfer instructions.

The names are in the supported venues table above. The same three groups appear in every multi-venue setup: exchanges for order books, OTC liquidity providers for streaming and RFQ prices, and custodians for balances and transfers.

Mercury OTC separately names custody and KYC partners and liquidity providers as current integrations, and says new integrations can be added at a client's request. Ask any vendor for its current integration list in writing and check it against the venues, LPs and custodians you use.

How smart order routing uses these connections

Smart order routing for crypto only works as far as the platform's connections reach. A router compares prices, fees and available size across the connected venues and liquidity providers, and sends an order, or parts of it, to the best place for the trader's rules. The more venues and providers are connected, the more the router has to choose from, and the more that failures on any one connection matter. Liquid Mercury's Sweep algo is built on this idea; see the Algo Suite and the smart order routing glossary entry.

Market data depth

Connectivity covers data as well as orders. Ask any vendor which order book depth, real-time feeds and historical data it offers for each venue.

Depth matters because a router or an algo can only act on what it sees. A desk that sees only the top of book will misjudge how much size a venue can absorb before the price moves. See smart order routing.

Normalized risk across venues

Connecting to many venues creates a second problem: exposure has to be measured the same way everywhere, or limits mean different things on different exchanges.

The Liquid Mercury Risk Engine standardizes this by calculating notional value with one formula per instrument type.

Position size and quantity follow each exchange's own convention, for example contracts or quote units, and the system is configured per venue so limits behave as intended. Max Quantity, for instance, is always counted in contracts. A venue that defines one contract as a fixed dollar amount is checked against the number of contracts, not the dollar amount.

When a limit is breached, new orders are rejected automatically until exposure returns within the defined thresholds. For the emergency controls that sit on top of these limits, see kill switch.

Latency and co-location

Distance to the venue affects latency. Mercury Pro describes geographically optimized infrastructure and co-location options. Ask any vendor which venues and locations its co-location covers.

No latency figures are published here. Any number a vendor quotes should come with how it was measured: from where, to where, at what load and at which percentile.

How Liquid Mercury connects

Mercury Pro connects to custodians, OTC liquidity providers and exchanges from one platform. A trader sees a centralized order book and aggregated positions, risk and balances across all connected venues. Algos such as Sweep use that connectivity to read order books from several exchanges and liquidity providers at once. See the Algo Suite.

Mercury OTC is fully white-labeled, so an OTC broker can offer clients a branded electronic desk while Liquid Mercury handles the connectivity underneath. For the technical overview, see technology.

Questions to ask any connectivity vendor

• Which API styles are supported for order entry, and can they be mixed on one account?
• Which venues are live in production today, not on a roadmap?
• How are fills and positions normalized across venues?
• What depth of market data is available, and is history included?
• What happens to open orders if a connection drops?
• How is exposure calculated, and is it the same on every venue?