The Compute Market Is Building in the Wrong Order
Every commodity market needs a standard unit of measurement
I’ve written a lot about the need for compute derivatives. Infrastructure providers want to hedge revenue uncertainty. Lenders want to hedge collateral exposure. Hyperscalers want to lock in capacity. Startups want predictable costs. Every sophisticated participant in the compute market wants forward curves, standardized contracts, and the financial plumbing that every other commodity market of comparable economic significance already has.
But there’s a problem that almost nobody in the compute derivatives conversation is talking about. Before you can build a forward curve, you need a unit of measurement for the thing you’re trading. And compute doesn’t have one.
This sounds like a dry, esoteric point. It is. It’s also the single largest structural obstacle between where the compute market is today and where it needs to be.
The Administration’s Metrology Gambit
The Trump Administration released its non-binding AI Action Plan in July 2025. Buried in it is a passage that didn’t get enough attention. The plan states that America has solved resource accessibility problems before “through financial markets, such as spot and forward markets for commodities,” and calls for federal collaboration with NIST, OSTP, and NSF’s NAIRR pilot to “accelerate the maturation of a healthy financial market for compute.”
Read that sentence carefully. It explicitly names commodity spot and forward markets as the template. It explicitly puts NIST in the lead. This is the administration pointing at the electricity playbook and saying: do this again, but for compute.
Whether this leads anywhere depends on execution. Federal policy documents describe aspirations more often than they describe commitments. But the signal matters. Someone in the administration understands the market infrastructure gap and has identified a plausible institutional path for closing it. The question is what that path actually requires—and the answer starts with how every other commodity market in the country was built.
What Every Other Commodity Market Has That Compute Doesn’t
Every commodity derivatives market in the United States rests on a measurement foundation built by the National Institute of Standards and Technology. When natural gas trades on NYMEX, the contract specifies delivery in MMBtu—millions of British thermal units. The ability to measure an MMBtu accurately and consistently across thousands of delivery points, under varying temperature and pressure conditions, traces back to NIST. NIST developed the national calibration standards for gas flow meters. Those meters are the cash registers of the natural gas economy. Every physical delivery, every storage injection, every pipeline nomination references measurements that are traceable to NIST standards. Without that traceability, the Henry Hub price is just a number with no defensible physical referent.
NIST Handbook 44 is instructive here. First published in 1949, updated annually for seventy-six consecutive years, and adopted by most state and local weights and measures authorities across the country, it specifies the tolerances and testing procedures for commercial measuring devices—everything from gas pumps to grain scales to electric meters. That handbook represents seventy-six years of continuous institutional investment in the proposition that if you’re going to trade something, you need to be able to measure it. The gallon of gas you pump at a filling station is measured by equipment calibrated against NIST standards, inspected by state officials trained by NIST, under tolerances published in that handbook. The infrastructure is invisible precisely because it works.
Electricity is an even stronger precedent, because electricity—like compute—is a non-storable flow commodity. You can’t warehouse a megawatt-hour the way you can store a barrel of oil. When wholesale power markets emerged after deregulation in the 1990s, NIST’s role was foundational. The Energy Independence and Security Act of 2007 gave NIST explicit statutory responsibility for smart grid interoperability standards. Under that mandate, NIST coordinated the national effort on interoperability standards for the smart grid devices and systems that made it possible for FERC to build a regulatory framework and for exchanges to build trading platforms. You can’t have a MWh forward contract if participants can’t agree on what a MWh is or how to verify delivery.
The pattern repeats across every commodity class. Petroleum products reference NIST-traceable volume and density measurements. Agricultural commodities reference NIST-traceable weight standards. The architecture is always the same: NIST defines the unit and the measurement methodology. FERC, CFTC, SEC, and the other regulatory agencies build their frameworks. Exchanges build the market infrastructure. Nobody confuses those roles. And you cannot skip step one and expect steps two and three to work.
The Measurement Gap
Now consider where compute stands. There is no standardized unit of compute capacity. There is no equivalent of the MMBtu, the MWh, or the troy ounce. There is no agreed-upon methodology for comparing an H100 to a B200 to an MI300X to a TPU v5p in terms that a contract could reference.
What we have instead is GPU-hours—a unit so imprecise it’s almost useless for financial purposes. A GPU-hour of what? At what utilization? With what memory bandwidth? Under what interconnect topology? An H100 GPU-hour and an A100 GPU-hour are not the same product, but the industry routinely talks about them as if they were, and pricing data frequently conflates them.
The nascent GPU indices are a genuine and important first step: daily reference prices for specific hardware, aggregating data across providers. As price transparency tools, they work. Institutional desks can pull them up and compare rental costs across providers for a given chip. But each index tracks a particular piece of silicon—an H100 index, a B200 index—and there is no conversion framework between them. No dimensionless ratio that lets you express one in terms of the other. No way to mark a mixed fleet to a single benchmark. The indices give you price transparency within a hardware generation. They don’t give you a unit of measurement across hardware generations.
What a Real Compute Standard Looks Like
If NIST took this mandate seriously, the work product would look like what NIST has produced for every other commodity: a measurement standard, a classification system, and a verification methodology.
Start with a standardized unit of compute capacity. The critical design requirement is that it must be dimensionless—a ratio normalized to a reference configuration, not an absolute number tied to a specific chip. This is what makes it survive hardware transitions. Define it as a weighted composite of floating-point throughput, memory bandwidth, interconnect bandwidth, and energy efficiency, measured against a fixed reference. Publish the weights. Make the methodology transparent. Let industry argue about whether memory bandwidth should be 25% of the composite or 30%. That argument is productive. It’s the kind of technical debate that converges on something useful, the same way the natural gas industry converged on BTU content as the standard measure despite decades of prior volumetric trading.
The key is that the number must mean the same thing regardless of what silicon produced it. An H100 delivering 1.0 Compute Units and a B200 delivering 1.0 Compute Units and a future Rubin GPU delivering 1.0 Compute Units all represent the same quantity of verified capacity. The unit outlives the hardware. That’s the whole point.
Then build a classification taxonomy that’s vendor-agnostic and extensible. Not “Nvidia GPUs” and “AMD GPUs”—rather, Resource Classes and Resource Families with standardized identifiers that a contract can reference without being rendered obsolete when the next architecture ships.
Then a benchmark suite for capacity verification: executed under specified conditions, independently verifiable, with confidence intervals. This is how you answer the question, “Did the seller actually deliver what the contract specified?” It’s the compute equivalent of the gas flow meter inspection, or the smart meter calibration that NIST’s Electric Power Metrology group provides for the electricity market.
Note what NIST would not do: set depreciation schedules (that’s management discretion or IRS prescription), mandate financial reporting (SEC), design contract terms (exchanges and the CFTC), or prescribe collateral haircuts (OCC and the bank regulators). NIST’s role is measurement. That confinement is precisely what gives it credibility across all the downstream domains.
The Sequencing Problem
All of this points to a conclusion that should make the people building compute derivatives uncomfortable: the market has the sequencing backwards.
Exchanges are being designed. Indices are being published. Infrastructure providers are writing bespoke forward contracts. All of that work is necessary. But the different layers of this emerging market have very different exposure to the missing measurement standard, and the people building the most exposed layers are the ones moving the fastest.
The data layer can tolerate the gap. Each hardware-specific index is useful on its own terms. When the next chip ships, you publish a new index. If a cross-hardware standard eventually arrives, it provides connective tissue between indices but isn’t a prerequisite for any single index to function.
The contract layer cannot. This is a mechanical problem, not an execution problem, and it stems from the interaction between hardware-specific units and GPU generation cycles. A twelve-month forward on H100 GPU-hours works as long as H100s remain the relevant hardware. But Nvidia ships new architectures on roughly two-year cycles, and the market is already rotating from H100s to B200s. This is one reason longer-tenor forwards haven’t emerged. Nobody wants to write a twelve-month contract on H100 GPU-hours when there’s no framework for what happens as the underlying hardware rotates out of the market’s marginal demand. There is no mechanism for rolling an H100-denominated contract to a B200-denominated one, because there is no agreed-upon ratio between an H100-hour and a B200-hour. The absence of the instrument is itself evidence of the gap.
Without a cross-hardware measurement standard, every forward contract carries embedded obsolescence risk. Every hardware transition is a potential liquidity crisis. An exchange whose product suite is denominated in specific GPU models faces an existential repricing event every eighteen to twenty-four months.
Who This Hurts and Who It Doesn’t
The measurement gap is not equally distributed. Index providers are the least exposed—they can add new hardware trackers as chips ship and their existing data remains useful. Exchange operators carry the most risk, because their contract specifications bake in hardware assumptions that have a two-year shelf life. Infrastructure lenders fall somewhere in the middle: their collateral models reference specific hardware today, but they have at least some ability to adjust haircuts and covenants as the fleet turns over.
The participants who should be most concerned are the ones writing long-dated contracts. Anything beyond the current hardware cycle—call it eighteen months—is implicitly taking a position on a conversion ratio that doesn’t exist yet. If you’re an infrastructure provider selling twelve-month forwards on H100 capacity and the market rotates to B200s in month eight, you’re delivering a product that’s settling against a benchmark with declining liquidity. If you’re a lender with a three-year term loan collateralized by H100 clusters, you’re underwriting a technology asset with no standardized framework for comparing its value to the next generation.
The electricity market followed exactly this arc. Early bilateral power trading after deregulation was full of smart people writing clever contracts on non-standardized products. It worked until it didn’t. The California energy crisis of 2000-2001 exposed what happens when you build a market on inconsistent measurement and verification infrastructure. Enron’s trading desk exploited precisely the gaps that standardization was supposed to prevent. The federal standardization push came after the crisis, not before it.
The question for compute is whether we learn from that history or repeat it, and how expensive the gap between the ideal sequence and the actual one turns out to be. My bet is that we repeat it—not because the people involved are unaware of the problem, but because NIST operates on a timeline measured in years of stakeholder convening, public comment, and calibration, and that timeline is not congruent with venture capital cycles, exchange launch schedules, or the urgency of infrastructure providers who need hedging tools now.
The market will develop in the wrong order. Hardware-specific indices first, hardware-specific derivatives next, and then—after some pain—the cross-hardware measurement standard that should have come first. The smart move for institutional participants is to understand exactly where in that sequence they’re taking risk, and to price the gap accordingly.
If you enjoy this newsletter, consider sharing it with a colleague.
I’m always happy to receive comments, questions, and pushback. If you want to connect with me directly, you can:
Really enjoyed this. I think your electricity analogy actually points toward a resolution though. The kWh didn't become fungible because NIST published a spec. It became fungible because ISOs like PJM Interconnection built the dispatch layer that made heterogeneous generation sources (gas, nuclear, wind) deliverable as a standardized output at a given node. The measurement standard followed the operational infrastructure, not the other way around.
The same path is available for compute. A scheduling and reliability layer that dispatches inference requests across heterogeneous GPU hardware (H100s, B200s, whatever ships next) while enforcing contractual latency, throughput, and availability targets would be the compute equivalent of grid dispatch. If the scheduler delivers identical SLO performance regardless of which silicon is underneath, the financial contract references the SLO, not the GPU model. The unit outlives the hardware because the delivery mechanism does.
Compute is harder than electricity here because the output isn't physically identical across hardware. Workloads have hardware-specific optimization dependencies that electrons don't. But for inference, which is the bulk of enterprise demand, the abstraction is feasible.
Lending against serialized GPU hardware is useful but it's still equipment finance, and the bond inherits the 2-3 year obsolescence cycle. Securitizing cash flows from hardware-agnostic performance SLAs instead, where the operator can rotate underlying GPUs across generations without breaking the contract, gets you something closer to PPA ABS.
So the sequencing may not be as stuck as you suggest. It might be that the missing step isn't metrology, it's the dispatch and reliability infrastructure that makes heterogeneous compute fungible at the delivery point. Right now you go to CoreWeave or Lambda the same way you bought power from Edison or Westinghouse in the early 1900s: incompatible systems, proprietary hardware, no interconnection, no grid. Whoever builds the compute equivalent of PJM defines the standard unit as a byproduct.
Thanks for a clear and cogent explanation of the issue. I heard the same argument applied to strategic arms negotiations a few decades ago - the two sides had to agree what a I and a 0 were.