A compute futures market cannot start with a ticker symbol. It first needs a defensible answer to what unit of compute is being priced, which transactions or quotes represent its cash market, and whether the resulting settlement index is public, timely, liquid, and resistant to influence by the same firms supplying the capacity.
That is the dependency hidden inside the CFTC's new request for comment. The agency has not approved a compute futures contract or endorsed a reference price. It is asking whether the fragmented inputs of provider, region, hardware, contract structure, delivery window, and possibly inference tokens can support a derivatives market under existing designated-contract-market obligations.
The question this map answers
What evidence would have to connect today's compute cash market to a listable, surveillable derivatives contract, and where does the CFTC's August 2026 request leave the critical definitions open?
MyMap observed the CFTC release and Federal Register text at 4:06 AM Pacific Time on August 24. The Commission issued the request on August 19, the Federal Register published it on August 21, and comments are due October 20. The source is a request for empirical input, not a final rule, guidance document, product approval, or finding that a mature compute derivatives market already exists.
Layer one: “compute” is not yet one fungible commodity
The CFTC says the cash market appears fragmented and that price formation primarily occurs in opaque bilateral transactions. It notes that prices can vary across providers, regions, and contract structures, while consensus is still forming around the appropriate underlying commodity.
The request gives two different examples. An underlier might be access to rented capacity from a named hardware class, such as an hourly rental price for a B200. It might instead be a compute-related output such as a stated volume of LLM inference tokens. Those are not interchangeable units: hardware access carries availability, location, interconnect, reservation, and performance conditions; tokens also depend on model, service, throughput, and provider rules.
The map therefore requires a contract designer to declare the unit before aggregating prices. A label like GPU-hour does not by itself specify accelerators, precision, utilization assumptions, region, networking, uptime, reservation length, or deliverability. The CFTC's document asks commenters for the standard definitions, quality grades, units of measurement, and adjustment mechanisms that might make heterogeneous capacity comparable.
Layer two: the reference price must survive its own contributors
The Commission says most early compute derivatives would likely be cash-settled because physically delivering the underlying capacity can create infrastructure challenges. In a cash-settled contract, the final payment depends on a reference price rather than delivery of racks or token capacity. That makes index governance part of the contract's economic substance.
The CFTC highlights a circular risk: some published compute series use posted rates administered by capacity providers, and a small number of participants may operate or dominate the remaining venues. A provider might affect an index through a posted-rate change, by moving capacity toward or away from a sampled venue, or by choosing whether to transact during the observation window.
A usable evidence record therefore needs more than an index value. It needs the calculation method, included venues, eligible transaction types, timestamps, contributor concentration, volume, frequency, outlier policy, fallback rules, publication timing, and governance. The request asks what thresholds for volume, transaction frequency, and concentration would be appropriate and whether a price series already meets the requirements.
The document does not answer that last question. “There is a public price page” and “there is a robust cash settlement index” remain different states.
Layer three: settlement design chooses which risks enter the contract
The request distinguishes cash settlement from physical settlement and also asks about fixed-date and perpetual futures. Each branch changes the evidence needed:
| Design branch | Required mapping question | Unresolved risk highlighted by the request |
|---|---|---|
| cash-settled | Which reliable, acceptable, public, and timely index determines final settlement? | a thin or provider-influenced cash series can transfer distortion into settlement |
| physically settled | What exact capacity is deliverable, where, when, and in what quantity? | infrastructure constraints, quality differences, and squeezes or corners |
| fixed-date future | Which observation and delivery window matches the commercial exposure? | maturity-specific liquidity and settlement representativeness |
| perpetual future | What mechanism keeps the contract tied to the underlying market without a fixed expiry? | additional safeguards and participant risks remain open questions |
These are design choices, not four CFTC-approved products. The visual uses separate branches because a good answer for a cash index does not establish adequate deliverable supply, and an inventory of data-center capacity does not validate a perpetual funding mechanism.
Layer four: listing and surveillance do not disappear for a novel commodity
A designated contract market, or DCM, can generally list a new derivative by self-certifying compliance or by requesting Commission approval. In either route, it must submit contract terms and prescribed supporting information before listing. The request emphasizes two existing duties.
Core Principle 3 requires a DCM to list only contracts that are not readily susceptible to manipulation. For a cash-settled compute future, that directs attention back to the reliability and liquidity of the underlying reference price. Core Principle 4 requires the DCM to prevent manipulation, price distortion, and disruption through surveillance, compliance, and enforcement capabilities.
The evidence chain therefore loops: the exchange cannot assess trading behavior without visibility into the cash inputs that settle the contract. The CFTC asks whether information-sharing arrangements would be needed with each venue and provider contributing transactions or posted rates. It also asks about position limits or accountability levels, deliverable-supply estimates, thin-market safeguards, and conduct particular to compute cash markets.
Customer protection is a parallel control lane. The request asks about BSA/AML and know-your-customer concerns, disclosure for a geopolitically sensitive commodity, retail protections, intermediary conduct, and idiosyncratic risks. It does not conclude that compute is uniquely subject to any specific illegal behavior; it asks commenters to identify and support the differences.
Confirmed, derived, and still unknown
The CFTC confirms the request's procedural status, October 20 deadline, existing DCM listing routes, Core Principle 3 and 4 duties, its preliminary view that early contracts would mostly be cash-settled, candidate underliers, observed fragmentation factors, and the four comment families: cash-market structure, manipulation and oversight, customer protection, and perpetual futures.
MyMap derives the four-layer dependency from cash inputs to unit, index, and contract plus controls. The diagram's return arrows show an analytical requirement: surveillance evidence must reach the cash contributors that affect settlement. They do not claim the CFTC has mandated a particular index architecture or information-sharing agreement.
The sources leave unknown the canonical unit of compute, whether provider rates or bilateral transactions can form a representative index, sufficient volume and concentration thresholds, deliverable supply, the right position-limit method, feasible surveillance access, retail safeguards, advantages or risks of perpetuals, and whether any DCM will submit a contract.
Reproducible mapping method
To assess a proposed compute derivative without inventing maturity, build one row per claim and keep observation dates:
- Define the commercial exposure the user wants to hedge.
- Specify the underlier's hardware or output, quality, region, delivery window, and contract type.
- Inventory raw cash observations and distinguish executed trades from posted or negotiated rates.
- Calculate volume, frequency, venue and contributor concentration, and missing-data periods.
- Document the index formula, governance, observation window, fallbacks, and publication latency.
- Map settlement and deliverability terms to the reference evidence.
- Attach DCM submission, manipulation tests, surveillance feeds, limits, and customer disclosures as separate controls.
- Label any threshold chosen by the analyst as derived until an authority or contract defines it.
An analyst can adapt this evidence chain in a MyMap concept map, keeping market observations, contract definitions, and regulatory tests as typed relationships. The editable map is not a price source or regulatory approval.
Practical next step and limitations
The most useful comment is not “compute futures are good” or “compute is too complex.” It is a reproducible dataset and method: exact unit, time window, venues, executed volume, contributor concentration, index calculation, known influence paths, and the commercial exposure that the contract would hedge.
This article is an infrastructure-and-source reading aid, not trading, legal, compliance, or investment advice. Update the map if the CFTC publishes additional docket materials, a DCM submits a compute contract, an index discloses a verifiable methodology, or the Commission issues rulemaking or guidance after the comment period.