Futures sit atop a delivery chain
Waylon Jepsen: Seb and I work at the San Francisco Compute Company. We see a lot of bad behavior in compute markets, and we have made many of the same mistakes and assumptions ourselves.
A lot of people want to build a price index because they want GPU futures. In theory, those are useful commodity futures for the same reason a farmer uses crop futures: institutional buyers need to hedge their risk. But if you want to build a futures product, contracts have to price risk correctly and that means you need a liquid spot price. A liquid spot price means you need to be able to do delivery; delivery in a resale market means you need to build a secure multi-tenant cloud.
“Your contracts need to price risk correctly, which means you need a liquid spot price, which means you need to be able to do delivery, which means you need to build multi-tenant cloud.”
If you are selling a price index without doing those things, I do not think you will garner institutional volume. Retail volume is easier; there are plenty of degenerate gamblers who will gamble money on almost anything. Institutions are different. They need confidence that the contract resolves against capacity somebody can buy, sell, and actually receive.
Both shortcuts put the cart first
I canonicalize the two approaches as an East Coast and a West Coast crowd. The East Coast version starts with a synthetic index and derivative: publish an index, wrap a derivative around it, and hope people trade. Without a delivery market, that is a little bit of a cart before the horse.
“Let’s just purely financialize it right off the bat.”
The West Coast version is to build a regular neocloud. Neoclouds can be profitable businesses, but if they are not built correctly, they cannot support a GPU index.
These approaches fail on different layers. Pure financialization has no delivery underneath its price; a regular neocloud does single-tenant deals and does not support resale or multi-tenancy. The missing middle is a cloud built for market activity: deliver capacity, let a buyer resell excess compute, and isolate each new tenant securely. Those real transfers are what begin to create a spot price.
A market-ready cloud needs resale
Delivery comes first. Building a cloud is not entirely trivial: GPUs have different reliability than CPUs, and their margins are super thin because AI product quality scales with more weights, GPUs, and compute.
The second ingredient is resale. We learned it the hard way: SF Compute initially trained models, acquired a cluster, then realized that its idle capacity had to be resold. Other labs face the same risk when they buy too much compute. Letting them resell excess capacity removes a huge amount of that risk. It also turns a reservation into something the holder can transfer, rather than an idle cluster the buyer must carry until the contract ends.
“We’re going to go bankrupt every month unless we sell this cluster.”
Resale means you have to build secure multi-tenancy into the cloud. Most neoclouds do single-tenant deals: they sell a full GPU cluster to one customer for years. With resale, multiple people land on nodes in the same cluster, so networking, InfiniBand, and other services must be configured dynamically. One customer's nodes must talk to the same customer's nodes without talking to other tenants.
Direct cash indices need rare conditions
Sebastien La Duca: Waylon hands the talk to me to substantiate why delivery is needed for a good price index. The alternative is direct to cash: collect data, publish an index, and hope people trade it.
Direct to cash has worked only when one of three things is true. First, a central entity can force an industry to use its index, as in power markets. Second, transparency makes transaction data universally available and verifiable, as in crypto. Third, there is a well-defined fungible unit standard across the entire industry, as with iron ore. Authority can impose the reference; transparent markets expose the transactions; or a mature standard tells everyone exactly which unit the index prices.
The problem is that none of these are true for compute. Collecting prices and publishing an average cannot fix that; it only combines contracts whose underlying products may be very different.
Compute is not one fungible unit
With compute, contract term matters. On-demand rates can exceed twice the price of reserved contracts; guaranteed and preemptible capacity differ; and one-month, six-month, and two-year reservations have different prices.
Contiguity matters too. Three contracts for one hundred GPUs each could place the machines anywhere, when what the buyer actually wants is a single interconnected cluster of three hundred GPUs. Those are different products with different prices. The industry is also nascent, so clusters lack standards for networking, storage relative to compute, and physical security. We even toured a data center that was literally a chicken coop. A chip name plus an hourly count does not tell a buyer what fabric, facility, or guarantee sits underneath.
That variance belongs in the contract. Adding GPU counts cannot make scattered machines equivalent to one interconnected cluster, and averaging their prices cannot create a well-defined fungible unit.
Delivery creates trustworthy price discovery
Oil shows how a market developed around a commodity with many grades. When the chemistry and uses were still being figured out, a producer in the North Sea learned what its customers were buying. It began selling bespoke over-the-counter forward contracts with the relevant ins and outs baked into the terms. Those physical trades taught the market which grades, schedules, and penalties mattered before a financial reference tried to summarize them.
Those contracts served as the basis for a physically delivered futures market. Only after that market became widely used did cash settlement arrive.
The merchant makes this work in practice. An oil buyer signs a bespoke contract with specific terms for delivery, lateness, and quality. The merchant decides what that obligation costs and hedges the exposure in the derivatives market. People actually buying the thing still want delivery of the thing; they are not trading only the financialized version. For compute, physical delivery has to come first. That creates price discovery, and then you have an index that people actually trust.
“It’s always physical delivery first. That creates price discovery, and then you have an index that people actually trust.”
What would make a compute market cohere?
Could compute go straight to a price index if everyone aligned on one centralized price, as participants do in electricity markets?
Yes—if a central authority can force everyone to say, “That is the price.” In power markets, a utility authority such as ERCOT can make everyone play in the auction that produces the reference. There is not really such a thing in the compute market, so the shortcut is unavailable.
Could the complexity be abstracted away at a higher level by specifying a computation and performance bounds, then assembling GPUs that meet those requirements?
You could imagine that for actual end customers. But for a deep liquid market, you want a very standardized coordination interface: a relatively small number of atomic contracts that can be bundled and unbundled into whatever shape and size the customer wants. Standardize where the bulk of commercial activity and pricing happens.
Instead of solving for fungibility, could the market standardize auditability—certification and verification that the delivered unit meets particular requirements, perhaps with selective disclosure?
That is what happens in industries without a unified unit. Standards live at the OTC level: the buyer specifies quality, timelines, and penalties. A merchant asks what exposure it takes by signing the other end, then uses the derivatives market to hedge it. The cost of that position shapes the customer's price. It could be done programmatically or by humans.
Is this still an experimental market, or is it an important product direction for SF Compute now?
What we have right now is a cloud that lets customers buy and sell capacity. First build dollar volume, then partner with someone who has a CME license: they deliver with us, but settle on our marketplace.
That volume starts the collective bargaining process. Right now providers do this in silos and self-contract; the marketplace begins bringing those negotiations together.
Glossary
futures contract — A standardized agreement creating obligations tied to a future date and specified underlying product. Depending on its rules, expiry may require physical delivery or a cash payment based on a settlement price. Standardization defines the obligation; it does not guarantee liquidity.[4]
spot price — A price for near-term exchange of the underlying asset or service. SF Compute currently describes reservations, resale, and subleasing, but its product pages do not independently establish a liquid GPU spot price. A quoted index may still lack executable depth.[4][2]
physical delivery — Settlement by providing the contract’s specified underlying asset or service rather than paying only a price difference. For compute, the delivered capacity must also satisfy the contract’s operational attributes. Acceptance rules make the product concrete.[4][5]
cash settlement — Settlement through a monetary payment derived from a final reference price, without transferring the underlying asset. Its credibility therefore depends heavily on the reference price and contract specification.[5]
secure multi-tenancy — Several customers share physical infrastructure while networks and resources remain isolated between tenants. NVIDIA documents isolation across Ethernet, InfiniBand, and NVLink domains; implementation quality still determines the actual boundary.[6]