A few days ago, Kelly Littlepage, OneChronos’ CEO, walked me through what his company is building in compute markets. In July 2025, it announced a partnership with Auctionomics to bring auctions to the compute market, and what I heard during our conversation expanded on the news and the company’s plans. The July release described an off-exchange marketplace built on bilateral forward and bundled compute-and-power capacity. That’s only part of it, and the conversation we had described something more ambitious and more abstract: a swap referenced to dollar spend on frontier workloads.
One of the big unsolved problems in the compute market is defining what, exactly, is being bought and sold in compute markets. OneChronos has not solved this standardization problem, but it has relocated the problem from silicon heterogeneity, where the rest of the ecosystem is fighting it, to the cost of serving specific workloads, where it is a different and arguably more tractable problem.
Combinatorial auctions, briefly
OneChronos’ DNA is combinatorial auction technology. The technique was deployed in the spectrum-licensing context, and the broader theoretical work on auction design earned Paul Milgrom and Robert Wilson the 2020 Nobel in economics. Auctionomics, OneChronos’ partner on the compute market, was co-founded by Milgrom.
Until recently, combinatorial auctions could not be used in capital markets for a simple reason: clearing them is a computationally hard optimization problem, and you could not solve one at the latency that capital markets demand. That changed as technology improved.
OneChronos was founded in 2016, when advances in machine learning made running these auctions at capital markets speed feasible, and its U.S. equities ATS, which today runs auctions roughly ten to twenty times per second, is live proof that the matching machinery works in production.
Why combinatorial auctions for compute? Because today’s compute contracts clear in one of two regimes, and neither works well. Bilateral trades are bespoke, papered by lawyers, priced at whatever the room agrees to, and produce no observable price. All-to-all central limit order book (CLOB)-style markets, which predominates in the equities markets, requires a fungible unit and continuous two-sided liquidity.
Combinatorial auctions sit between these two regimes. Participants can bid on packages, meaning capacity over months, contingent on other legs, at a maximum aggregate price, and the optimizer clears the whole thing as a joint problem. It is a mechanism that produces a print worth publishing as a reference rate.
The instrument is the interesting part
The public July release talks about bilateral forwards on bundles of compute, power, and upstream resources. The conversation I had was more specific. The flagship instrument Littlepage described in our conversation is a total return swap. The underlying is workload output at the frontier, not hardware throughput. That is a meaningfully different abstraction than anything else in the compute derivatives space.
Every project trying to produce something H100-denominated runs into the fungibility problem I have written about repeatedly. H100s are not H200s, which are not B200s, which are not GB200s. Training, inference, and long-tail workloads sit on three different obsolescence curves, and collateral values bifurcate with them. You can build a reference rate on top of that mess, but you inherit the mess.
OneChronos’ instrument moves up a layer. If the thing being traded is dollar exposure to frontier workloads being run, the chip underneath matters less. Workload exposure is more plausibly standardizable than hardware exposure. Importantly, it’s not fungible in any final sense, because model versioning, latency, reliability, and provider quality all still matter. But it is standardizable in the sense that a notional spend basket abstracts over the dimensions that make hardware reference rates so brittle. The fungibility problem does not disappear. It moves to a new location, and whether that new location better depends entirely on what happens there.
The oracle is the market’s hidden constitution
Any workload-reference instrument has to solve a definition problem. The frontier is a moving target. Sonnet 4.6 is frontier today; when the next wave of models ships, it may not be. If the instrument has no stable denominator, it has no stable settlement.
The architectural answer is an oracle that publishes the Pareto frontier of models at time t with notional weights–five percent Sonnet, ten percent Opus, and so on–rolling up to a dollar-spend-weighted index of frontier compute consumption. The instrument settles against the basket. The basket gets rebalanced as the frontier moves. This is architecturally clean, and practically fraught.
A structure like this creates a number of incentives problems. Who economically benefits when the definition of the frontier changes? Once a contract settles against a governed basket, the index committee is a locus of basis risk creation. Every rebalance moves money. Every inclusion or exclusion creates winners and losers among existing position holders.
The adoption problem, and the only path that plausibly solves it
Compute buyers and sellers historically view compute through a procurement lens, not a risk management lens. A CFO at a neocloud or a procurement lead at a hyperscaler does not wake up thinking about basis risk and hedge ratios. They wake up thinking about capacity, vendor relationships, delivery timelines, and unit economics. Getting that buyer to view compute exposure as a position to be hedged rather than a contract to be negotiated is a cultural reorientation of the kind that took natural gas markets twenty years. The entire compute derivatives ecosystem is implicitly assuming this reorientation happens in a handful of years because the underlying asset class is growing fast enough to force it. Maybe. But this is the load-bearing assumption for the entire compute derivatives thesis, and nobody is stress-testing it in public.
One possibility here is that direct conversion of procurement organizations into derivatives counterparties is not the realistic adoption path. The realistic path might run in the opposite direction, through financing. A handful of sophisticated participants, including prop trading shops, foundation labs with real treasury functions, and one or two hyperscaler hedging desks, provide enough first-wave liquidity that cleared prints become credible. The reference rate then does the customer acquisition work for itself. The structured credit market starts referencing the rate. The rate shows up in term sheets for GPU-backed paper, in covenant baskets, in pricing grids. Procurement buyers get dragged into risk-management thinking through the back door of their own financing conditions rather than through the front door of the auction.
The bottom line
OneChronos may have identified the least bad reference layer yet proposed for compute risk: dollar spend on frontier workloads. That is a serious conceptual advance, and it deserves to be recognized as one. But it does not eliminate basis risk so much as relocate it. The hard part is getting financing markets, procurement organizations, and a governed reference basket to line up at the same time.
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:
Given OneChronos' strength in combinatorics, I initially expected a multi-asset hardware portfolio matching - e.g., a portfolio of 2x H100 with 80GB memory, 4x B200 with 180GB, 2x GB200 with 192GB within a NVL72 server rack. But that may lead to too many variations when considering not just the server, interconnect, and memory setup but also latency, TPS, TTFT, etc.
Using workload makes sense, given that it enables a higher level of abstraction that makes standardization easier. I'm now curious what that looks like in the context of TPS and TTFT, or whether that is somehow abstracted away as well, with the workload being some type of a deliverable like finishing a specific task.
Great piece - lots of food for thought.