Most institutional desks trading digital-asset derivatives should buy the venue connectivity and risk layer, then build only where they hold a genuine edge, usually pricing models and trading signals. A full in-house build is justified for a narrow group: high-frequency firms and market makers whose advantage is execution latency on one or two venues. For everyone else the build becomes a permanent maintenance commitment that competes with trading for engineering time.

What building in-house requires

A first prototype that sends an order to one exchange is quick to build. A production system that a risk manager will sign off on across several venues is a different project. These are the components a desk ends up owning.

• Per-venue adapters. Deribit, OKX, Binance, Coinbase and the rest each use their own authentication and request signing, their own symbology and their own instrument metadata. The same BTC option has a different name, tick size and contract multiplier on each venue, and your adapter has to map all of it to one internal model.
• Inverse versus linear contracts. Some venues settle options and futures in the underlying coin, others in a stablecoin. Margin, PnL and delta are computed differently for each. Ignore the distinction and the aggregated delta is wrong.
• Rate limits vary by venue, by endpoint and sometimes by account tier. Throttling has to be per venue and hold up in volatile markets, when request volume peaks.
• WebSocket reconnection and order-state reconciliation. Reconnecting a dropped socket is easy. Knowing what your orders did while you were disconnected is hard. You need to reconcile open orders, fills and positions against REST snapshots and handle fills that landed during the gap.
• Venue API changes and new listings. Venues deprecate endpoints, change payloads and list new expiries and instruments constantly. A reference-data pipeline has to pick these up before a trader asks why a strike is missing.
• Multi-leg execution. Where a venue has no native combo order, spreads and structures get legged in. Legging risk is the market moving between fills, so the system needs rules for partial fills, retries and unwinds.
• RFQ integration per network. Deribit Block RFQ, Paradigm and Derive each have their own quote lifecycle and hedge-leg conventions. If the desk also wants to quote as a maker, that is a second integration on each network.
• A hedging engine that decides when delta has drifted far enough, which instrument to hedge with and on which venue.
• Normalized risk. Greeks and exposure expressed in one unit across venues, collateral currencies and contract types.
• An audit trail of every order, amendment, cancel and quote, with who did it and when.
• Key security. Encrypted storage, scoping, rotation and a policy that refuses API keys with withdrawal permission.
• SOC 2 controls. If allocators or counterparties run security reviews, your in-house system falls under access reviews, change management and vulnerability remediation like any other production system.

The maintenance burden is the larger cost

The initial build is the visible part. The ongoing work is what decides whether it was a good idea. Every venue added multiplies the surface: another auth scheme, another set of quirks, another reconnection path to test. Venue API changes arrive on the venue’s schedule, sometimes with short notice, and an adapter that breaks during a volatile session is a trading problem rather than an engineering ticket.

In practice this means a dedicated engineering team with on-call coverage, whose roadmap is set largely by exchanges. That tradeoff is worth making only if connectivity itself is where the desk wins.

When building makes sense

• Your edge is execution latency. High-frequency firms and market makers who colocate and compete on microseconds need control of every line of the order path, and a vendor layer in between works against them.
• You trade one venue, or two at most, with a stable instrument set. Most of the multi-venue complexity above does not apply.
• An engineering organization already exists, already runs production trading systems in other asset classes, and can absorb digital-asset venues without new hires.

If none of those describe your desk, building tends to reproduce commodity infrastructure at a high ongoing cost.

When buying makes sense

Buying fits desks that take structured positions across several venues, where the edge lies in the view and the structuring rather than in queue position. It fits desks that want to add a venue or an asset class, such as event contracts alongside options, without a new engineering project. And it fits teams whose engineers should be working on models and research rather than on websocket heartbeats.

The hybrid most desks end up with

The common answer is to split the stack. Buy the venue and risk layer: adapters, reference data, order-state handling, RFQ connectivity, hedging and the consolidated book. Keep proprietary pricing, volatility surfaces and signals in-house, and drive the bought layer programmatically.

With Kemet, that means calling the REST and WebSocket API from your own systems, or connecting AI agents through Kemet’s MCP server. Your models decide what to trade. Kemet handles how the order reaches each venue, how fills are reconciled and how the resulting risk is aggregated. Venue accounts and API keys stay yours throughout. Market makers can apply the same split on the maker side, answering inbound RFQs with their own pricing while Kemet manages quoting and hedging across networks.

Vendor evaluation checklist

A useful checklist is one a vendor can fail. Ask each question, require a demonstration where possible, and treat vague answers as a no.

• Does the vendor ever take custody of assets, or accept an API key that carries withdrawal rights? Either one is a no.
• Which venues are live in production today? Ask to see an order placed on each venue you trade, not a roadmap slide.
• Are inverse and linear contracts normalized into one risk view, with delta reported in a single unit?
• After a dropped connection, how is order state reconciled? A specific answer about snapshots and gap fills is a pass. “We reconnect automatically” is not.
• How quickly do new listings and expiries appear on the platform?
• Which RFQ networks are supported, and is it taker side only or maker side as well?
• Can auto-hedging be configured with your own thresholds and choice of hedge venue?
• Is there an API for programmatic control, and does it cover execution and positions rather than market data alone?
• Can the vendor share a SOC 2 Type II report with its observation period under NDA? A Type I report or a self-assessment is a weaker answer.
• Is the vendor an exchange, broker or counterparty to your trades? A technology provider with no position in your flow has fewer conflicts to manage.

How Kemet fits

Kemet is an institutional trading platform for digital-asset derivatives and event contracts, covering the full trade lifecycle from discovery through execution to position management. It is a technology provider, not an exchange, broker or counterparty, and it never holds client assets. Clients connect their own venue accounts with their own keys, and Kemet rejects any API key with withdrawal rights. Kemet is SOC 2 Type II compliant.

Connected venues include Deribit, Coinbase Exchange, Coinbase Derivatives Exchange, Coinbase International Exchange, OKX, Binance, Bullish, Hyperliquid and Derive, plus Kalshi and Polymarket for event contracts. Desks get multi-venue options execution with execution algorithms and a multi-leg package builder, RFQ on Deribit, Paradigm and Derive on both the taker and maker sides, auto-hedging with configurable thresholds, and a unified portfolio and risk view across venues. New listings sync the same day they go live. See the platform overview for the full picture, or read what a crypto derivatives EMS does for the category definition.

FAQ

How do I evaluate a digital asset derivatives provider?

Start with custody and keys: the provider should never hold your assets or accept withdrawal-enabled keys. Then confirm live venue coverage with a demonstration, check how inverse and linear contracts are normalized, ask how order state is reconciled after disconnects, and request a SOC 2 Type II report with its observation period.

What features should I look for in a compliant digital asset platform for institutional trading?

Look for trading through your own venue accounts, key permissions that exclude withdrawals, an audit trail of orders and quotes, an independent SOC 2 Type II examination, and clarity that the platform is not acting as your broker or counterparty.

What capabilities should an institutional trader evaluate when assessing electronic derivatives execution?

Venue coverage, multi-leg execution and how legging risk is handled, RFQ access across networks, auto-hedging controls, normalized portfolio risk, and API access for programmatic trading. Our comparison of options venues for institutions covers the venue side in more depth.

Can we buy infrastructure and still keep our pricing models proprietary?

Yes. In the hybrid model your pricing, volatility surface and signals stay in your own systems, and you drive execution through the vendor’s API. Kemet supports this through REST and WebSocket APIs and an MCP server for AI agents.

Which institutional-grade platforms deliver trading infrastructure built for digital assets?

Options fall into three groups: tools provided by individual exchanges, multi-asset generalist platforms that added crypto, and derivatives-focused platforms built for digital-asset venues from the start. Kemet sits in the last group. Whichever you consider, run the checklist above and ask for live demonstrations on the venues you trade.

Talk to us

If your desk is weighing a build against a buy, we can walk through your venue mix and workflow and show where the line falls. Book a demo.