A Compute Commodity Clearinghouse

admin

The AI compute market is, by most measures, a mess. GPU rental prices fluctuate by an order of magnitude across providers. Procurement is opaque — often involving phone calls, NDAs, and negotiated contracts rather than transparent price discovery. Large clusters are rarely available on-demand, and buyers have no standardized way to compare an H100 against a B200 or an Apple M2 Ultra. Meanwhile, capacity sits idle somewhere while buyers overpay or go without.

This is not a novel problem in commodity markets. Energy, oil, natural gas, agricultural products — all were similarly fragmented before the emergence of standardized exchanges. The solution, historically, has been clearinghouses: neutral financial intermediaries that standardize the commodity, provide price discovery, clear contracts, and guarantee settlement. The exchange does not move oil; it clears the financial transaction while the oil moves independently.

The AI compute market is reaching the point where the same infrastructure is not just desirable but necessary. Compute Exchange has built the market’s first transparent GPU marketplace, aggregating pricing across 100+ providers and launching the world’s first GPU Pricing Intelligence Calculator for real-time and historical price benchmarking. Prime Intellect has pioneered the aggregation and orchestration of global GPU resources, with a mission to commoditize compute and democratize access — correctly identifying that the market lacks the efficiency of real exchanges, with H100 spot prices ranging from $1.20 to $18/hour for equivalent resources. Both are building critical infrastructure. What has been missing is the clearinghouse layer: standardized contracts, a published price index, derivative instruments for hedging, and a delivery mechanism that does not require the exchange to hold the keys to every data center it touches.

This paper describes that clearinghouse architecture.

The Fragmentation Problem

The GPU compute market has several structural deficiencies that a clearinghouse architecture directly addresses.

Price opacity and fragmentation. There is no authoritative published price for a given GPU configuration. Prices differ wildly across providers, and the same hardware at different facilities has meaningfully different performance characteristics that buyers cannot easily compare. Recent data from ICE’s Ornn index shows Nvidia Blackwell spot rental prices surging 48% in just two months — from $2.75 to $4.08 per GPU-hour between mid-February and mid-April 2026. Without standardized contracts and a published index, this volatility is unhedgeable.

Missing derivative instruments. Cloud providers offer spot pricing, but there are no standardized futures, options, or swap contracts for compute. Operators building large training runs or inference infrastructure cannot hedge their compute costs the way an airline hedges jet fuel. This exposes them to input cost volatility that can destabilize project economics.

Centralized credential architectures. Prior proposed exchange architectures for compute act as technical gateways: they hold SSH keypairs, API tokens, or other credentials on behalf of providers, and route compute sessions through exchange infrastructure. This creates unacceptable security exposure (a single breach exposes all contracted compute), scaling constraints (exchange infrastructure must scale with compute transaction volume), and reduced provider autonomy. It also mismatches established commodity exchange precedent — a futures exchange for natural gas does not operate the pipelines.

Heterogeneous hardware. An H100 SXM5 and a cluster of consumer-grade GPUs are not directly comparable without a normalization framework. The absence of standardized units makes contract specification, price comparison, and index construction difficult.

Clearinghouse Architecture

The proposed Compute Commodity Exchange (CCE) is modeled explicitly on financial clearinghouses rather than technical intermediaries. The exchange’s role is to clear the financial transaction; the physical compute delivery happens directly between the buyer (Consumer) and the seller (Authorized Compute Marketer, or ACM). The CCE holds no SSH keypairs, API tokens, or any form of compute infrastructure credentials at any time.

This architectural choice is not merely a security preference — it is the correct structural analogy. A stock exchange does not custody the shares it trades. A futures exchange for crude oil does not operate the pipelines or storage terminals. The CCE clears contracts and generates delivery tokens; ACMs operate the compute infrastructure and verify those tokens.

The Standardized Compute Unit (SCU)

Motivation

To write standardized contracts, you need a standardized unit of account. The SCU is a normalized scalar measure of AI compute capacity that enables price comparison across heterogeneous hardware — dedicated GPU architectures, unified memory architectures (Apple Silicon, AMD APUs), and future AI-specific silicon (TPUs, Trainium, Inferentia).

Formula

The SCU is computed as a normalized weighted dot product over four performance dimensions:

where:

SCU=(WG⋅G)+(WC⋅C)+(WM⋅M)+(WB⋅B)K\text{SCU} = \frac{(W_G \cdot G) + (W_C \cdot C) + (W_M \cdot M) + (W_B \cdot B)}{K}

  • G — GPU matrix compute throughput (TFLOPS at BF16 precision)
  • C — CPU floating-point throughput (GFLOPS at FP64)
  • M — Total addressable memory (GB)
  • B — Peak memory bandwidth (GB/s)
  • A — Memory Architecture Coefficient, a dimensionless scalar in (0, 1] capturing memory exclusivity, efficiency, and interconnect topology
  • K — Normalization constant, set so that the NVIDIA H100 SXM5 yields SCU = 1.00

Dimension weights and their rationale:

DimensionWeightRationale
GPU throughput (G)0.50Dominates AI training and inference via matrix multiply
CPU throughput (C)0.10Supporting role; rarely the bottleneck in GPU-accelerated workloads
Memory capacity (M)0.20Determines maximum model and batch size; binding for frontier models
Memory bandwidth (B)0.20Frequently binding for transformer inference and attention-heavy training

The normalization constant K is computed from NVIDIA H100 SXM5 reference specifications:

K=(0.50×989)+(0.10×120)+(0.20×80)+(0.20×3350)=1192.5K = (0.50 \times 989) + (0.10 \times 120) + (0.20 \times 80) + (0.20 \times 3350) = 1192.5

The Memory Architecture Coefficient A captures distinctions that raw throughput numbers miss. Dedicated HBM with exclusive GPU access receives A = 1.00. Unified memory architectures sharing a memory pool between CPU and GPU receive A = 0.85, reflecting the reduced exclusivity. Consumer GDDR with PCIe interconnect receives A = 0.75 to reflect the bandwidth penalty relative to NVLink/SXM configurations.

SCU-Normalized Pricing

The SCU-normalized price for any hardware configuration is simply:

PSCU=PrawSCUP_{\text{SCU}} = \frac{P_{\text{raw}}}{\text{SCU}}

where PrawP_{\text{raw}} is the provider’s quoted price per GPU-hour in USD. This gives a comparable $/SCU-hour figure across all hardware, enabling the CCE to publish meaningful price indices and enabling buyers to make apples-to-apples comparisons across fundamentally different architectures.

Compute Grade Classification

Beyond the scalar SCU, the CCE assigns each certified compute configuration a structured Compute Grade designation: [GPU-CLASS]-[INTERCONNECT-TIER]-[STORAGE-TIER]-[REDUNDANCY-LEVEL]-[LOCATION-ZONE]. This captures delivery-relevant specifications — interconnect topology, storage class, redundancy — that a scalar value alone cannot represent. Grades are used as contract delivery specifications, analogous to grade specifications for commodity contracts (e.g., WTI crude vs. Brent, or CBOT #2 yellow corn).

The Time-Bounded Access Pass (TAP)

The Delivery Problem

The central challenge in compute commodity exchange is delivery. Unlike a futures contract for gold, where delivery involves transferring title to a warehouse receipt, compute delivery requires provisioning real computational resources to a specific consumer at a specific time. The naive solution — having the exchange hold access credentials and route sessions — creates the security and scaling problems described in Section 2.

The TAP is a cryptographic solution that enables authenticated delivery without the exchange touching either the compute session or the credentials.

TAP Design

The TAP is a compact, cryptographically authenticated, time-bounded, single-use access token. It encodes:

  • Contract reference number
  • Consumer participant identifier
  • ACM identifier
  • Compute Grade specification
  • Contracted SCU quantity
  • Delivery window start and end timestamps
  • Interruptibility tier flag
  • Renewable Compute Certification flag (where applicable)
  • A unique nonce

The CCE generates the TAP by computing an HMAC-SHA256 digest over the serialized payload using a shared secret (the ACM Authentication Key, ACMK) established with the ACM at registration. The CCE encodes the payload and digest as a compact URL-safe string, transmits it to the consumer via TLS 1.3, and does not retain it.

Verification

TAP verification by the ACM is entirely self-contained — it requires no network connection to the CCE:

  1. Parse the TAP to extract payload and HMAC digest
  2. Recompute the HMAC-SHA256 over the payload using the locally stored ACMK
  3. Compare digests; reject if mismatch
  4. Verify current timestamp is within the delivery window; reject if outside
  5. Verify ACM identifier matches; reject if mismatch
  6. Verify nonce has not previously been presented (single-use enforcement via local nonce cache); reject if replay detected
  7. If all checks pass, provision the contracted compute resources for the delivery window

Upon completion of the delivery window, the ACM transmits a signed Delivery Attestation back to the CCE confirming delivered SCU quantity and any SLA deviations, enabling settlement finalization.

Security Properties

The TAP architecture provides several security properties that credential-escrow approaches cannot:

No credentials at the exchange. A complete compromise of the CCE’s systems reveals no access credentials to any ACM’s infrastructure. The ACMK stored at the CCE is not a compute credential; it is a signing key used to generate tokens.

No stored tokens. TAPs are not persisted by the CCE after transmission. There is no token database to exfiltrate.

Bounded blast radius. An intercepted TAP is valid only for specific contracted resources, for a specific time window, for a single use. It cannot be replayed, extended, or used to access other resources.

Offline verifiability. Verification by the ACM requires no CCE connectivity, eliminating a class of availability attacks in which CCE outages would block compute delivery.

Provider infrastructure autonomy. ACMs retain complete control of their own security posture. The only exchange-generated artifact they accept is the TAP.

Alternative Encodings

The TAP mechanism is not tied to a specific encoding. Alternative embodiments include JWT (RFC 7519) with HMAC-SHA256 signature and contract parameters as claims, TOTP (RFC 6238) with contract-specific shared secrets, and blockchain anchoring in which a hash commitment of TAP parameters is published to a distributed ledger at settlement, enabling trustless verification against the on-chain record.

The Standardized Compute Access Specification (SCAS)

For the TAP mechanism to function, ACMs must expose a standardized interface. The Standardized Compute Access Specification (SCAS) defines the minimum interface standards that ACMs must implement:

  • A consumer-facing access endpoint accepting TAP-bearing connection requests
  • A CUDA-compatible GPU programming interface at the contracted version
  • Standard networking (SSH or equivalent)
  • Container runtime support
  • A Delivery Attestation interface for post-delivery settlement confirmation

The SCAS serves the same function as standardized pipeline interface specifications in energy markets — it ensures that a cleared contract results in consistent, verifiable delivery regardless of which ACM is the counterparty. ACM certification requires successful completion of a test protocol in which the CCE generates test TAPs and verifies correct acceptance and rejection behavior.

Market Structure and Trading Instruments

Market Tiers

The CCE operates a two-tier market structure. The Primary Market is restricted to Registered ACMs and qualified Consumer Direct Market Participants; physical delivery via TAP occurs exclusively at this tier. The Secondary Market extends access to Registered Broker-Dealers, Institutional Investors, and Market Makers, trading compute contracts as financial instruments. An information barrier prevents individual primary market transaction data from reaching secondary market participants before settlement.

Within each tier, the CCE operates a Day-Ahead Market (hourly supply and demand cleared by economic dispatch, producing a Day-Ahead SCU Clearing Price) and a Real-Time Market (sub-hourly, managing deviations from DAM commitments, producing the Real-Time SCU Clearing Price — the primary reference rate for derivative settlement).

An annual Capacity Market allows ACMs to commit future SCU availability in exchange for capacity payments, providing revenue certainty to incentivize long-term GPU infrastructure investment.

Trading Instruments

The CCE supports a comprehensive suite of instruments:

Spot contracts. Delivery of a specified SCU quantity within a short settlement window. Physically-settled spot contracts result in TAP generation.

Futures contracts. Standardized agreements to deliver or receive a specified SCU quantity at a defined future date. Physically-settled futures result in TAP generation at the delivery window commencement.

Fixed-for-floating swap contracts. One counterparty pays a fixed $/SCU-hour rate; the other pays the floating RT-SCP index rate for a defined notional SCU quantity over a defined tenor. Cash-settled at each payment date.

Energy-for-compute cross-commodity swap contracts. A novel instrument specifying a notional energy commodity quantity and reference energy price index (e.g., ERCOT North Hub, Henry Hub, renewable energy indices) on one leg, and a notional SCU quantity and compute price index on the other. This instrument enables compute providers to hedge energy input costs against compute revenue, and energy producers to gain compute market exposure, in a single structure. The correlation between energy costs and compute costs is a fundamental economic relationship — the energy-for-compute swap makes it tradeable.

Call and put options. European, American, Asian (average price), and barrier-style variants, supporting vanilla options, straddles, strangles, collars, and calendar spreads.

Capacity options and basis contracts. Capacity options confer the right to purchase compute capacity commitments at a fixed capacity price. Basis contracts represent price differentials between GPU classes, provider locations, or time periods — enabling fine-grained hedging of grade and location risk.

FIX Protocol Gateway

The CCE operates a Secondary Market FIX Protocol Gateway (SMFPG) providing Registered Broker-Dealers and Institutional Investors with programmatic access to the secondary market via FIX protocol versions 4.2, 4.4, 5.0, and 5.0 SP2. This provides the same connectivity interface used in equity, fixed income, and commodity derivatives markets, enabling integration with existing institutional trading infrastructure without bespoke development.

Carbon Credit Integration

The CCE integrates renewable energy and carbon credit infrastructure at the contract level:

Renewable Compute Certificates (RCCs). ACMs demonstrating renewable energy sourcing receive RCCs, each representing one SCU-hour of compute powered by certified renewable energy. RCCs are tradeable instruments with associated vintage, geography, and technology metadata.

Green Compute Marketers. A specialized ACM subclass that sources a minimum defined percentage of wholesale compute from RCC-certified providers, retires RCCs upon delivery, and publishes real-time renewable percentage metrics. TAPs for Green ACM contracts carry an embedded renewable flag.

Carbon-Paired Compute Contracts. Compute contracts that optionally pair delivery with retirement of verified carbon offset credits, enabling buyers to procure compute with embedded carbon neutrality guarantees. The CCE also supports standalone carbon credit spot and forward contracts, enabling carbon credit trading alongside compute contracts.

A Green Compute Price Index tracks RCC-certified compute pricing separately, enabling buyers to observe the green premium (or discount) and enabling price discovery for sustainable compute infrastructure.

Multi-Currency Settlement

The CCE settlement layer supports fiat currencies (USD, EUR, GBP, JPY), fiat-pegged stablecoins (USDC, USDT, DAI), cryptocurrencies (BTC, ETH), and central bank digital currencies (CBDCs) as they become available. Real-time FX conversion is integrated, with positions margined in a designated base currency. This design reflects the global and borderless nature of compute supply — data centers are in Singapore, Iceland, Texas, and Kenya — and enables participation by counterparties operating in different financial systems.

Interruptibility Tiers

The CCE defines standardized interruptibility tiers incorporated as contract specifications across all instruments:

TierDescription
FIRM_RESERVEDNo preemption; guaranteed delivery for the full window
BEST_EFFORTNo preemption unless extraordinary circumstances
INTERRUPTIBLEProvider may interrupt with advance notice
SPOTMay be interrupted immediately; lowest cost

TAPs for FIRM_RESERVED contracts carry embedded flags that prohibit ACM-side preemption; TAPs for SPOT contracts carry flags permitting interruption. This mirrors the interruptibility structures of electricity markets, where firm capacity, interruptible service, and spot capacity trade at different prices and serve different buyer needs.

Relationship to Existing Market Infrastructure

The CCE architecture is designed to be additive rather than competitive to existing compute marketplaces. Platforms like Compute Exchange — which aggregates pricing across more than 100 providers and provides transparent market pricing intelligence — and Prime Intellect — which has aggregated GPU resources from 12+ clouds and built orchestration infrastructure for global distributed training — are building the supply aggregation and demand access layers. The CCE provides the clearing, standardization, and derivative infrastructure that sits above those layers.

The analogy is to energy markets: brokers, aggregators, and bilateral trading desks coexist with organized exchanges. The exchange provides price discovery, standardized contracts, and counterparty risk management; the brokers provide market access, customized deal structures, and relationship capital. Both are necessary.

The establishment of major financial exchange operators in this space — CME Group’s announced compute futures in partnership with Silicon Data, and ICE’s announced GPU compute futures with Ornn — confirms that institutional infrastructure for compute as a commodity is arriving. The CCE architecture described here is designed to be that infrastructure at the layer closest to physical delivery.

Discussion

Several design choices merit explicit discussion.

SCU as a simplification. The SCU formula is a weighted linear combination over four dimensions with fixed weights. Real AI workloads are not linear in these dimensions — inference latency depends on memory bandwidth in ways that differ from training throughput. The formula is a practical approximation that enables standardized contracts, not a precise performance predictor. The CCE governance process can update dimension weights prospectively, with continuity adjustments to maintain index time-series comparability.

HMAC vs. asymmetric cryptography. The TAP uses HMAC-SHA256 with a shared secret. An alternative using asymmetric signatures (e.g., ECDSA) would allow any party to verify TAP authenticity without a shared secret, at the cost of additional complexity in key management. The HMAC approach is sufficient given the bilateral relationship between the CCE and each ACM, and avoids the need for a public key infrastructure.

Decentralized alternatives. The architecture can be implemented with on-chain TAP commitment publication via smart contracts, enabling trustless verification of the TAP commitment against a distributed ledger. This is a natural extension for a market where some participants prefer not to trust a central clearinghouse, and reflects the tokenized compute futures contracts now entering the market.

Inference-specific SCU. The current SCU is optimized for training workloads (BF16 throughput dominant). An inference-specific SCU defined in tokens per second for a reference model would better serve inference buyers. This is a natural extension as the market matures and inference demand grows relative to training demand.

Conclusion

The AI compute market is undergoing the same structural transition that energy, agricultural, and financial commodity markets underwent decades ago: from fragmented bilateral trading to organized exchange infrastructure with standardized contracts, published price indices, and derivative instruments for risk management.

The CCE architecture described here makes three specific contributions toward that transition. The SCU provides a normalized unit of account enabling price comparison and contract standardization across heterogeneous hardware. The TAP provides a cryptographic delivery mechanism that scales the clearinghouse model to compute without requiring the exchange to hold infrastructure credentials. The derivative instrument suite — including the novel energy-for-compute cross-commodity swap — provides the hedging tools that large-scale compute buyers and sellers need to manage input cost and revenue volatility.

The infrastructure for compute commodity markets is being assembled in parallel across multiple organizations. Pioneers like Compute Exchange and Prime Intellect are building the marketplace and aggregation layers. Traditional commodity exchanges are building futures products. The clearing, standardization, and delivery infrastructure described here completes the stack.

References