The OTC compute market today is large, active, growing, and entirely improvised.

A buyer needs 512 H100s for nine months, starting in three weeks. A seller has capacity coming free at month-end. Somewhere between those two facts is a deal, and that deal will move through email, WhatsApp, Telegram, four spreadsheets, two competing proposals, a half-remembered conversation with a salesperson who left six weeks ago, and finally a paperwork sprint that no one wants to do. 

This post is about what an OTC compute deal actually involves, and what changes when the workflow underneath those deals stops being an inbox.

What a deal actually involves

An OTC compute deal moves through five distinct stages. They don't always happen in order, and some of them happen four times before the deal closes.

The RFQ (request for quote). A buy-side counterparty (usually a Director of Procurement at a frontier lab, an inference provider, or an AIaaS operator) defines what they need. GPU type. Quantity. Tenor. Region. Interconnect. Configuration. Start date and flexibility on start date. They send it out to a list of sell-side counterparties they know.

The listings. On the other side, sell-side counterparties (Directors of Sales at hyperscaler compute-rental teams, neoclouds, regional GPU operators, or AIaaS providers placing capacity) keep an internal view of what they have available and when. Capacity comes free, gets retained, gets recommitted. The list changes weekly. Sometimes daily.

Counterparty matching. The RFQ goes to a subset of sell-side counterparties: the ones with plausibly relevant capacity, the ones who paid attention last time, the ones on speaking terms. The buy side knows roughly who fits. So does the sell side, in reverse. But the knowledge lives in heads, not systems.

Negotiation. Counter-offers, conditions, prepayment terms, allocation flexibility, termination rights, configuration trade-offs. State accumulates. Some of it lives in email. Some in chat threads. Some on a call no one logged. The deal evolves; the record doesn't.

Execution. When terms settle, paperwork runs: purchase agreement, prepayment, capacity reservation, confirmations. The deal lives across two legal teams, two finance teams, and a procurement function that has to verify what arrived against what was promised.

That's one deal. Most counterparties run several at any given moment.

Why the current setup breaks

Three things happen as deal volume grows.

First, coordination work doesn't scale linearly with deals. It scales worse. Each active deal multiplies the number of threads, the number of counterparties to track, the number of negotiation states to keep current in someone's head. Two parallel deals are not twice the work of one. They're closer to four times.

Second, counterparty knowledge walks out the door. Who responded fast last quarter, who countered low and closed, who never closes: that lives in the relationships of the salespeople and procurement leads who built it. When they leave, it leaves. The desk starts from scratch.

Third, pipeline status isn't visible inside the team. The Director of Sales running 10 active deals knows where each one stands. The CFO trying to forecast doesn't. The new hire trying to spin up doesn't. The team functions around one person's memory of the state of the book.

None of this is an indictment of the people doing the work. It's a description of what the tools force them to do.

At the market level, the same opacity shows up as intermediation. The buyer doesn't have visibility into who has capacity. The seller doesn't have visibility into who needs it. The gap gets filled by brokers: a single deal often passes through three or four of them before it settles, each one bridging a step the market doesn't connect on its own. The chain widens spreads, obscures pricing, and adds days to execution. It isn't a feature of the underlying market. It's what the market looks like in the absence of an operational layer.

Compute Trader: the workflow layer

Compute Trader is the workflow layer that runs your OTC compute deals.

You send Compute Desk an RFQ, or a piece of capacity to place. We route it, coordinate the counterparties, manage negotiation state, and walk the deal through execution. The work is on our side. The visibility is on yours.

That's the service-plus-software model: Compute Trader is the software underneath the deals; Compute Desk is the team running them. Counterparties don't operate the product directly. They get visibility into every deal moving through it, and the operational layer currently unavailable to them.

Deals stay private and bilateral. You choose who you transact with. We don't run an order book. We don't run a marketplace. Pricing isn't broadcast to the market. The structure of an OTC compute deal (negotiated, private, customized) is the structure we built for, not the structure we're trying to replace.

How a deal moves through Compute Trader

Listings management keeps capacity, terms, configurations, and availability windows current. Sell-side inventory is structured and live. 

RFQ orchestration routes each request to the right counterparties based on capacity, prior deals, and (where it exists) response history. The list of who sees what is a function of who's plausibly relevant on this particular deal, not a guess.

Negotiation coordination keeps counter-offers, conditions, and decisions visible to the people on the deal, and only to them. The state of the deal lives with the deal. 

Pipeline visibility shows every active transaction in one view. What's moving. What's stuck. What's about to close.

Execution coordination keeps paperwork, allocations, and confirmations in one place. The deal closes. The history stays. The next one starts with more context than the last.

What changes with Compute Trader

Counterparty history stays with your desk. When a salesperson or procurement lead moves on, who responded fast, who countered low and closed, and what the last three deals with that firm looked like compounds in the system.

Deals and the paperwork attached to them sit in one place. Purchase agreements, prepayments, capacity reservations, confirmations: same deal, same record. The next deal with the same counterparty starts from what worked last time.

The contract layer in OTC compute is bespoke per deal today. Running every deal through one operational layer is what makes the templates underneath standardizable, and the legal lift per deal compressible.

Throughput is the other consequence. Coordination cost per deal drops once the workflow is real infrastructure instead of an inbox. The same desk can run more deals. Tenors that don't pencil today, like six weeks or three months, start to pencil because the operational drag stops eating the margin.

Intermediation compresses too. The three or four broker hops a typical deal takes today are a function of opacity, not a fixed structure of the market. As more counterparties run deals through the same operational layer, more of the matching happens directly. The chain shortens. Spreads compress with it.

Compute Desk: one business, two layers

Compute Trader is one piece of Compute Desk's infrastructure. Compute Desk also publishes live OTC compute prices to ~350,000 Bloomberg terminals under tickers CIBLKWUS, CIHOPUS, and CIHOPEU.

That matters because a working compute market needs two layers underpinning the long-term contract world: a liquid physical market, and a financial layer on top of it. Compute Trader is the workflow infrastructure for the physical layer. The Bloomberg distribution is the financial-layer plumbing, already in place.

Both layers are part of the same business, vertically integrated.

Get on Compute Trader

Access is limited to active OTC compute counterparties: buy side, sell side, or both. We screen counterparties.

If you coordinate reserved-compute deals (running RFQs, placing inventory, managing forward exposure on either side), request access and we'll get back to you within a business day.