Market design · Compute · 27 July 2026

Implied compute forward curves

Kalshi's compute contracts do not settle against Kalshi. They settle against Ornn's Compute Price Index — and that one fact is what turns a prediction market into a price curve. Each rung of the ladder is a digital option on an externally administered benchmark, a strip of digitals across strikes is a discretised probability distribution, and a distribution has a mean. A forward curve for compute has therefore existed since the day those contracts listed. Since 14 July 2026 Kalshi has been publishing it, and it is the first continuously published term structure for the commodity — sitting on the same index that ICE's and Architect's pending contracts will settle on when they arrive.

What follows works that construction end to end, prices the convenience yield it exposes against provider term sheets, calibrates the factor structure the curve implies, and then asks the question the construction raises: four instruments and the deepest event-contract ladder in the market now carry settlement weight on benchmarks whose administrators have published no calculation. The five-tier framework used here — and the partition rule that governs which contract sets can carry an index at all — is set out in Hedging corporate event risk inside a hierarchy.

01Where the ladder settles

Every rung of Kalshi's compute ladder resolves against an index somebody else administers. That is the detail most coverage skips, and everything downstream depends on it.

Kalshi's compute markets went live in March 2026 as spot contracts — a ladder of strikes on the per-hour rental price of an H100, H200, B200 or RTX 5090, each rung resolving at the end of its period. They do not resolve to a survey, to a provider rate card, or to Kalshi's own print. They resolve to Ornn's Compute Price Index, a third-party benchmark constructed from printed GPU rental transactions and distributed on the Bloomberg Terminal.

Change the settlement source and you change the object entirely. A binary that pays $1 if X > K is a digital option on X. If X is the listing venue's own trade print, the digital is self-referential and the ladder means nothing outside the venue that wrote it. If X is an externally administered index, the ladder is a strip of digital options on a real benchmark — and a strip of digitals spanning a range of strikes is a discretised risk-neutral distribution for that benchmark at that expiry.

What the ladder actually is

Not a betting market on compute. An options surface on OCPI. Each contract is a digital struck at K, expiring at T, on an index with an administrator, a data source and a publication schedule. Differencing adjacent strikes gives probability mass; the mass-weighted mean gives a forward. Kalshi never had to launch a forward market — listing the ladder created one implicitly, in the underlying's own units, across every tenor it lists.

On 14 July 2026 Kalshi began publishing that curve explicitly: weekly, monthly and quarterly points on B200, H200 and A100, bootstrapped from the ladders. It is the first continuously published forward curve for compute anywhere.

The alternatives are not close. FalconX printed the first OTC compute forward against OCPI H100 on 27 May 2026 — that established the trade exists, but a single bilateral print is not a curve, and nothing about it is observable to anyone who was not on the ticket. ICE's and CME's contracts, which would produce a proper exchange-traded curve, are both still pending approval. So the only observable term structure in compute today is implied out of an event market, and it is a term structure on the same index the listed contracts are going to settle on.

The consequence: one spread in this complex has no index basis inside it

Kalshi's ladders settle on OCPI. ICE's pending GPU compute futures settle on OCPI. Architect's AX perpetuals settle on OCPI. FalconX's OTC forward settled on OCPI. The moment ICE lists, the spread between the Kalshi-implied forward and the ICE future is the only cross-venue spread in compute with no methodology difference buried in it — same administrator, same index, same input data, same units. What is left is term premium, fee, and the liquidity differential between an event ladder and a futures book. That is a clean, interpretable, tradable basis.

Every other pair in the complex is not. A CME contract on Silicon Data against an AIE contract on Compute Desk carries a difference in construction that nobody outside those firms can size, because — as §04 works through — none of the three administrators has published a calculation.

The complex as it stands

Compute went from no financial market to a crowded one between January and July 2026 — eight instruments across six venues and three competing benchmark administrators. The settlement weight is not spread evenly among them. One administrator now sits underneath four of the eight, including the only one that is live.

All dates 2026. Note the two Architect rows — the same operator runs two venues on two different index providers, in two different regulatory regimes — and the Ornn column, which appears four times.
InstrumentVenue / dealerIndex providerStatus
Perpetual futures
GPU rental + DRAM
Architect — AX, 23 Jan
Bermuda Monetary Authority
Ornn — "first-in-kind indexes based on live transaction data"Pending approval
Compute futuresCME, 12 MaySilicon Data — SDB200RT, SDH100RT, SDA100RTPending regulatory review
GPU compute futures
USD cash-settled
ICE, 19 MayOrnn OCPI — H100, H200, B200, A100, RTX 5090Pending approval
OTC compute forwardFalconX, 27 May
counterparty Robert Leshner, Superstate
Ornn OCPI H100. First OTC swap on the forward price of computeExecuted
Futures & options
compute, plus metals, energy, power
Architect — American Innovation Exchange, 28 May
US DCM, via the IMX Health acquisition
Compute Desk indexes. Architect commits to "IOSCO- and EU BMR-certified indexes" specified to SKU levelPending regulatory review
ComputeConnect
exchange-for-physical
Architect (AIE) + Compute Desk, 8 JulConverts futures positions into real H100 / H200 / B200 / B300 capacity. Publishes standard basis tables by SKU, memory configuration and locationPending; futures legs book to AIE
Spot ladders
Mar
Compute Forward Curves
14 Jul
Kalshi
CFTC-regulated DCM
Ornn OCPI — H100 / H200 / B200 / RTX 5090 ladders resolve to OCPI. The published curve is bootstrapped from the weekly, monthly and quarterly B200 / H200 / A100 laddersLive. Deepest instance layer in the complex. Curve is a derived reference, not itself tradable
Provider term curveAWS, Azure, CoreWeaveReserved-tier discounts: 25–31% 1yr (AWS), ~30% (Azure), up to 60% for termLive, embedded in commercial contracts
The structure that has emerged, and it is not what the announcements suggest

Three benchmark administrators on paper; one reference price in practice. Ornn OCPI sits under ICE's pending futures, Architect's offshore AX perpetuals, the first OTC compute swap, and the entire Kalshi ladder — which is to say it sits under the deepest T3 layer in the market and the only continuously published curve. Silicon Data holds CME's contract. Compute Desk holds Architect's US venue. Architect is running AX on Ornn and the American Innovation Exchange on Compute Desk — two venues, two administrators, two regulatory regimes, one operator.

Kalshi is the part everyone has miscategorised. It is routinely described as a venue betting on compute prices against itself. It is not: its ladders are externally settled, which makes them the only live instrument in the complex anchored to a printed-transaction index. The derived curve is a second-order object on top of that — an analytic, not a benchmark — and it is the market's only observable term structure precisely because the instruments that would compete with it are still in the regulatory queue.

One party is also building the physical link. ComputeConnect is an exchange-for-physical mechanism: it converts a futures position into deliverable GPU capacity and — the detail that matters — publishes standard basis tables by SKU, memory configuration and location. That is the BTIC-style linking mechanism the framework piece argued has to be built in from day one, and it is the difference between a benchmark that anchors a complex and one that floats beside it. Architect is also the only venue in compute to have publicly committed to IOSCO- and EU BMR-certified indexes.

So the two hard structural problems — external settlement, and a physical delivery link — have each been solved once, by different parties, at different benchmarks. What is still missing is a T1 constant-maturity index anyone can trade, and any published account of how the three administrators calculate the numbers four instruments already depend on.

02Building the curve, and what falls out of it

Five steps: ladder to forward, forward against the provider term sheet, the factor structure that implies, the hierarchy that results, and the bases that are left over. The construction is standard; what it exposes has not been observable before.

Step 1 — Ladder to density to forward

The Kalshi ladder quotes P(price > K) at each strike. Adjacent differences are the probability mass in each bucket; the mass-weighted mean is a synthetic forward. This is the discrete Breeden–Litzenberger construction, and it is the whole of what turns an event market into a price curve.

mj = P(X > Kj−1) − P(X > Kj)   →   F(T) = Σj mj · cj where cj is the bucket midpoint. Enforce monotonicity on the survival function before differencing — tail strikes go stale and produce negative masses. Construct outward from the mode, as the Fed's own work on bracketed macro contracts does.

Implied distribution of B200 rental price, by tenor

Each bar is the probability mass the ladder assigns to that $0.50 bucket. Mass migrates left and spreads as tenor extends — the market prices decay in scarcity rent, with widening uncertainty.

1 week 3 month 12 month
Bucket ($/GPU-hr)1 week3 month12 month
4.00 – 4.506%12%28%
4.50 – 5.0016%20%19%
5.00 – 5.5031%27%20%
5.50 – 6.0028%21%14%
6.00 – 6.5013%12%9%
6.50 – 7.006%8%10%
Implied forward$5.47$5.38$5.19
Implied σ$0.62$0.71$0.82
Ladder quotes are illustrative and anchored to the observed April 2026 B200 on-demand level of $5.50/hr. The construction is the finding; the quotes are not market data.

Step 2 — The three-curve basis is a measurable convenience yield

Now put the curves side by side at the one-year point. The financial forward implies $5.19. The providers' own reserved-tier discounts imply $3.80–$4.13 for the same delivery period.

One-year B200 price: three curves, same underlying

The gap is not mispricing. A reserved contract bundles guaranteed capacity access, credit, and a commitment obligation that a cash-settled forward does not carry. That bundle has a price, and it has only just become observable.

Spot from Silicon Analysts (Apr 2026, Lambda on-demand). Reserved band from published AWS 1-year commitment discounts of 25–31%. Kalshi forward from the illustrative ladder above.
$1.23
Per GPU-hour gap, financial forward vs physical term
23.6% of the spot price. On 4.38M GPU-hours — 500 GPUs for a year — that is $5.4M of unexplained basis.
59.5%
Mean share of the rental price that is pure demand premium
H100 63.7%, H200 52.4%, B200 62.4%. Hardware amortisation and power are near-deterministic; the scarcity rent is the entire risk, and it is shared.
0.91
Correlation of an expected-count index to its latent factor
The Class B result — a simple sum of probabilities across independent events tracks the common driver almost perfectly.
This is the framework's first genuinely new output

In commodities, F = S·e(r+u−y)T, where y is the convenience yield — the benefit of holding the physical rather than a claim on it. Compute has an enormous convenience yield: a reserved cluster you can actually schedule against is worth more than a cash settlement. Until this year there was no financial leg to measure it against.

Now there are two, and they are the same index. FalconX printed the first OTC compute forward on 27 May 2026 against OCPI H100 — a financial leg, but bilateral, single-print, and no observable curve. Kalshi's ladders, which also settle on OCPI, give the first continuously published one. Set either against the provider term sheet and you get the term structure of compute scarcity — a price that is economically central to every hyperscaler and AI lab and that nobody has previously been able to observe. Because both legs reference the same administered index, the measurement is not contaminated by benchmark differences; whatever is left in the gap is economics.

Step 3 — The factor structure, calibrated rather than assumed

The published cost decomposition does the work here. A GPU-hour is hardware amortisation plus power and facility plus demand premium — and the first two are near-deterministic. So the risk is entirely in the premium, and the premium is a common scarcity factor with observable loadings.

Δlog Pi,t = βi·Ftscarcity + γi·Gtgeneration + εi,t βi is the SKU's premium share — 0.637 (H100), 0.524 (H200), 0.624 (B200) — because only the premium moves. G is a Blackwell-vs-Hopper supply factor. ε is SKU-specific: allocation, a single provider's outage, a driver release.

Hedging effectiveness by SKU — benchmark alone, and benchmark plus sub-index

R² of a minimum-variance hedge against the tradable index. The sub-index tier is again where the cheap variance reduction is, exactly as in the framework piece.

Benchmark only + generation sub-index
Assumes scarcity-factor vol of 35% and idiosyncratic vol of 12% annualised. Loadings are the observed premium shares. Mean R² rises from 74.8% to 81.1%.

Step 4 — The resulting hierarchy, and what trades at each rung

Every rung below T1b already has a listed instrument, and the bottom rung is externally settled. T0 and a tradable T1 do not exist and are the build.
TierInstrumentUnitsToday
T0 RegimeAggregate accelerator supply / power availability: "US datacentre capacity additions in 2027 ≥ N GW", "export-control regime change"BinaryAbsent
T1 BenchmarkConstant-maturity compute index — capacity-weighted across SKUs, interpolated to 1M / 3M / 12M$/GPU-hrOCPI anchors spot; no tradable constant-maturity index
T1b Sub-indexBy generation (Blackwell / Hopper / Ampere) and by tier (neocloud / hyperscaler)$/GPU-hrSilicon Data publishes; not tradable
T2 NamePer-SKU forward, quoted as spread to T1b$/GPU-hrCME futures pending
T3 InstanceSKU × week binary ladder — KXB200WS-26JUL17BinaryLive on Kalshi, settling on OCPI

Step 5 — The four tradable bases, and what they must clear

Fees and the collateral carry wedge set a no-arbitrage band. Nothing inside the band is a trade.

Band = round-trip taker fee at Kalshi's 0.07·p(1−p) schedule, plus the zero-coupon carry wedge 1−e−rT at 4%. Maker execution on both legs roughly halves the fee component.
BasisLegsWhat it measuresMust clear
Ladder-internalAdjacent strikes in one ladderMonotonicity and mass conservation. Pure logical arbitrage1.8–4.5¢
Venue skew
same index
Kalshi-implied forward vs ICE OCPI futureThe CDS-skew analogue, in its cleanest available form. Both legs settle on OCPI, so there is no index basis in the spread — only term premium, fee and the ladder-vs-book liquidity differential~5–7¢
Administrator basisICE/OCPI future vs CME/Silicon Data future vs AIE/Compute Desk futurePure methodology difference between benchmarks on the same underlying. Currently unmeasurable — no administrator has published a calculationunknown
Convenience yieldFinancial forward vs provider reserved tierThe price of guaranteed physical capacity. Not arbitrage — a risk premium to be estimated and tradedwide
Factor residualSKU forward vs β-weighted indexRealised β diverging from implied β. Cross-sectional relative value~5¢ + β error

At a 50¢ contract with one year to run the band is 7.4¢ — 3.5¢ of round-trip taker fee and 3.9¢ of carry. That is wide enough that small logical inconsistencies survive indefinitely, which is consistent with the published finding that best-YES plus best-NO on Kalshi always sums to more than $1. Long-dated tail nodes are the worst affected, and they are where the hedging value is.

03Generalising — the four-step recipe

The compute example is one instantiation. The procedure is category-agnostic, provided the contract set is sorted correctly first.

Two classes, and the class decides the mathematics. Class A — bracketed continuous: a strike ladder over a real-valued underlying (GPU rental price, CPI, Fed funds, temperature). The ladder is a discretised CDF, adjacent differences are probability mass, and the natural benchmark is a synthetic forward in the underlying's own units. Compute is Class A, which is why the construction above works. Class B — categorical: discrete outcomes with no underlying continuum (election winner, game result, court ruling). There is no CDF to difference; the prices are the object, the factor space is log-odds rather than price, and the natural benchmark is an expected-count index. The full treatment of both, and of the partition rule that decides where either can exist, is in the framework piece.

 StepClass A (bracketed continuous)Class B (categorical)
1Define the collection — never a partitionAll ladders on the same underlying across tenorsContracts across independent events sharing a driver
2Map to a common spaceLadder → CDF → forward F(T), in the underlying's unitsyi = logit(pi). Level index = Σpi (expected count)
3Extract the factorPCA on Δlog F. PC1 = the level factor; PC2 = slopePCA on Δy. PC1 = the regime factor
4List the benchmark, quote the rest as basisConstant-maturity index; constituents quoted as spreadExpected-count index; single events quoted as spread
Weighting: do it in log-odds, not price

A binary's sensitivity to a shift in the latent factor is dp/dy = p(1−p) — maximal at 50¢, near zero in the tails. So an equal-price-weighted index of seven contracts spanning 3¢ to 97¢ gives the mid-priced contract 29% of the index's factor sensitivity and the 3¢ contract 3.4% — an 8.6× spread, and the index goes structurally blind to exactly the tail events it should be measuring. Equal-weighting in log-odds space restores 14.3% each.

This is the direct analogue of equal-weighting CDX in spread rather than in price, and it is the single most consequential construction choice in the whole exercise.

04Index governance — IOSCO

A note on the reference, because two different standards are in play and only one is about index construction.

IOSCO Principles for Financial Benchmarks (FR07/13, 2013)

This is the index-construction standard. 19 principles in four groups — Governance (1–5), Quality of the Benchmark (6–10), Quality of the Methodology (11–15), Accountability (16–19). It governs the T1 layer: what the index represents, what data anchors it, and who is accountable for it.

CPSS–IOSCO PFMI (2012)

The CPSS–IOSCO output is the Principles for Financial Market Infrastructures — 24 principles for CCPs, settlement systems and trade repositories. Not an index standard, but directly binding on this design: Principle 6 (Margin) and Principle 3 (Risk management) are what the framework piece's "net collateral across the tree" recommendation actually has to satisfy. Cross-tier margin offsets require validated, back-tested correlation assumptions — a hierarchy is a margin model, not just a taxonomy.

Settlement weight — who bears it, and for whom

Assess the principles in the order that matters: an index's governance obligations scale with what settles on it. Analytics can be undocumented. A settlement source cannot.

Principle 2 — Oversight of Third Parties — makes each instrument responsible for the governance of the benchmark it uses. Every entry in the right-hand column inherits its administrator's controls wholesale. Note the concentration: one administrator carries four of the five live or pending references, including the only instrument actually trading.
BenchmarkAdministratorAnchored inInstrumentsWhich
OCPIOrnn Data LLCPrinted transactions — negotiated levels between data centres and buyers4Kalshi spot ladders (live) · ICE futures · Architect AX perpetuals · FalconX OTC Compute Forward
Compute Desk indexesCompute Desk"Real, privately settled transactions." Paired with Compute Clear for delivery integrity1 + physicalArchitect American Innovation Exchange futures, plus the ComputeConnect EFP leg
Silicon Data indicesSilicon DataCollected rental and private transaction data1CME compute futures
Kalshi implied curve
derived analytic
Kalshi (the listing venue)Its own ladder prices — which themselves settle on OCPI. A second-order object on an administered index, not an independent benchmark0Published as analytics; nothing settles on it. Its data-sufficiency posture is OCPI's, one step removed

The benchmark principles against what exists today

Assessed against publicly available methodology documents and press releases as of 27 July 2026. Absence of published detail is not evidence of absent practice — but under Principles 9, 11 and 12 the publication is the obligation, so an undisclosed control is a gap on its own terms.
Principle Ornn OCPI · 4 instruments, incl. the live Kalshi ladder Compute Desk · AIE + physical Silicon Data · CME Kalshi curve · derived analytic on OCPI
1–5 Governance
Named administrator; conflicts framework; internal oversight
Gap Administrator named (Ornn Data LLC), but no published oversight committee, conflicts policy or control framework — while carrying, by a wide margin, the most settlement weight in the complex Committed, unevidenced The venue commits to "IOSCO- and EU BMR-certified indexes." No certification, administrator registration or oversight document located Undisclosed No published oversight function Venue-published The contracts settle externally, so the listing conflict that would otherwise apply does not. But the venue that lists them is also the sole publisher of the derived curve, with no oversight function over that derivation
2 Third parties
Users must assess the benchmark they reference
Open across the complex, with one exception None of Kalshi, ICE or FalconX has published an assessment of Ornn's controls, and each inherits OCPI's governance entirely while adding none of its own — the OTC forward and the live ladder most directly. Architect's AIE is the only venue to have stated a governance standard for the index it will reference, which is the right instinct and is not yet the same as evidence
6 Benchmark Design
"accurate and reliable representation" of the economic reality measured
Strong Normalised across hardware configuration, provider and deployment context; 400+ operators, investors and AI companies on the platform Strong Indexes paired with a delivery layer and published basis tables by SKU, memory configuration and location — design tied to deliverable reality Strong Claims 95% of neo-cloud providers, 100% of major hyperscalers, ~80% of the global rental market Partial by design Represents market expectations of OCPI, not transacted rental rates. That is the correct thing for a forward curve to represent — but it is a forecast of a benchmark, not a benchmark, and should not be described as one
7 Data Sufficiency
"anchored by observable transactions entered into at arm's length between buyers and sellers in the market"
Strongest claim "the first compute index to be built only from printed transactions." If accurate, the best P7 posture available — caveat below Strong "referencing real, privately settled transactions." The EFP leg is corroborating evidence — an index you must deliver against is disciplined by the physical market Strong Real-time rental and private transaction data Inherited Anchored, at one remove, in OCPI's printed transactions — the ladder it is bootstrapped from settles there. Its P7 posture is exactly Ornn's, no better and no worse, plus an undisclosed bootstrap. The derived-curve problem — below
8 Hierarchy of Data Inputs
Published guidelines on input priority and the use of expert judgment
Not published Normalisation across "provider and deployment context" is judgment; the rules governing it are not disclosed Partial Basis tables are a published normalisation grid — the closest thing to a disclosed input hierarchy in the complex. Contributor eligibility still undisclosed Not published n/a
9 Transparency of Determinations
Publish enough with each determination to understand how it was produced
Partial Distributed via Bloomberg Terminal; publication frequency and cut-off time not stated in any release located Partial No determination-level disclosure located Partial Describes "robust standardisation" and "outlier removal" without specifying either Partial Describes bootstrapping weekly, monthly and quarterly markets; no construction detail, no stated cut-off, no statement of how stale or crossed rungs are handled
11 Content of Methodology
Document and publish the methodology
Gap No methodology document located. Calculation technique, normalisation model and contributor eligibility all undisclosed Gap No methodology document located, though a BMR-certified administrator would be obliged to publish one Gap Calculation technique — median, VWAP, trimmed mean — not disclosed Not published Explicitly withheld: "users don't need to understand the full machinery"
12–13 Changes & Transition
Rationale for material change; cessation and fallback plan
Gap No revision or cessation policy located. Three instruments would be stranded by an unannounced change Undisclosed A physical delivery obligation makes a cessation plan materially more urgent, not less Undisclosed No revision policy found Exposed Nothing settles on the curve — but the ladders underneath it settle on OCPI, so an unannounced OCPI methodology change reprices the entire published curve and every live contract on the venue. Neither party has published a fallback
16–19 Accountability
Complaints procedure, external audit, full audit trail
UndisclosedUndisclosed UndisclosedUndisclosed
The inversion buried in that table

The index with the best design has the thinnest disclosure, and it is the one carrying the whole complex. Ornn's transaction-only anchoring is the strongest Principle 7 posture available — better, on its face, than a scraped or surveyed alternative. But Principle 7 requires data sufficiency to be demonstrable, and Principles 9 and 11 require the methodology to be published. A transaction-based index whose contributor set, normalisation model and calculation technique are all undisclosed is asking users to take the best part of its design on trust — at exactly the moment a live event-contract ladder, a pending listed future, a perpetuals contract and an executed OTC swap are all relying on it, and a published forward curve is being derived from it. The concentration is the risk. A single undisclosed methodology change would move four instruments and the only term structure the market can see.

Note also that the administrators are in open methodological dispute — Ornn's own material argues that "scraped indices can misstate where transactions actually clear," a direct claim about a competitor. Nobody can adjudicate it, because none of the three has published a calculation. That is precisely the condition Principle 11 exists to prevent, and it is a live commercial problem: a hedger choosing between a CME contract, an ICE contract and an AIE contract is choosing among three indices whose differences cannot currently be measured.

Compute Desk is the partial exception, and the reason is structural rather than editorial. It publishes basis tables by SKU, memory configuration and location because ComputeConnect has to deliver against them. A physical settlement obligation forces disclosure that a cash-settled index can defer indefinitely — which is an argument, on governance grounds alone, for building the exchange-for-physical leg early rather than treating it as a phase-two feature.

The derived-curve problem — what a forward curve inherits, and what it adds

The obvious criticism of Kalshi's curve is that it is circular: a venue publishing a price derived from its own order book. That criticism is wrong, and it is worth being precise about why. The ladders the curve is bootstrapped from settle on OCPI. Kalshi's order book determines who wins each contract; it does not determine the number the contract pays against. The external anchor Principle 7 exists to require is present.

What is actually going on is inheritance. The curve is a second-order object: a risk-neutral expectation of a third-party benchmark, extracted by a method the venue has not published. So it carries OCPI's governance profile wholesale — every Principle 7, 9 and 11 gap in Ornn's column is also a gap in Kalshi's, one step removed — and then adds a bootstrap of its own on top, which is where the genuinely new disclosure obligation sits. How are crossed or stale rungs handled? What enforces monotonicity on the survival function before differencing? Is the tail extrapolated, and how? Those choices move the printed forward by cents at the long end, which is precisely where the hedging value is.

The hierarchy resolves this cleanly. T1 must be externally administered and anchored in physical transactions — OCPI and the Silicon Data indices both qualify on substance. T3 settles on T1, which is now the case. The remaining move is not to fix the settlement source, which is already right; it is to treat the curve as what it has become. A continuously published forward curve that market participants price against is a benchmark in function whatever it is called in the disclaimer, and the moment anything settles on it — an ETF, a swap, a term sheet marked to it — it needs an administrator, a published bootstrap, and a cessation plan. Publishing the construction now, while nothing settles on it, is cheap. Publishing it afterwards is a remediation.

What a compliant T1 looks like

Design choiceSpecificationPrinciple
AdministratorThird party, separate from any listing venue; published oversight committee with user representation1, 3, 5
Input hierarchy(i) executed rental transactions, (ii) firm quotes, (iii) indicative provider rate cards, (iv) expert judgment — each tier published, each use logged7, 8
CalculationVolume-weighted trimmed mean, trim band published; capacity weights across SKUs fixed at each reconstitution9, 11
Weighting spaceLog-odds for Class B constituents; log-price for Class A. Never equal-weight in raw probability6
Term structureConstant maturity by linear interpolation between the two bracketing expiries, VIX-style; roll on a published calendar6, 11
RevisionsFirst print settles. Restatements published separately and never reopen a determination9, 12
ReconstitutionFixed calendar, pre-announced; constituent turnover disclosed each roll10, 12, 13
CessationPublished fallback and transition plan before first listing, not after13
AuditAnnual external audit of methodology adherence; full audit trail of expert-judgment applications17, 18

05Where this leaves it

Three claims, in descending order of confidence.

1 — The extension is real, and it is mostly aggregation work

Kalshi has a deep, externally settled instance layer and no tradable benchmark above it. Because the constituents already trade and already resolve to a real index, a benchmark on top of them is a construction and governance problem, not a market-creation problem. The compute case shows it end-to-end: an existing ladder yields a forward curve, an observable cost decomposition yields the factor loadings, and a two-factor hedge reaches 81% R² without listing a single new instance contract. The complex has assembled every tier except a tradable T1 and any published account of how the numbers underneath it are calculated.

2 — The partition rule is the constraint that decides feasibility

Benchmarks exist only across events, never within one — because a partition (a mutually exclusive, exhaustive set whose probabilities sum to one by construction) has no level factor inside it to index. In compute that constraint is easy to satisfy — the ladder strip across tenors is a collection, not a partition — which is part of why compute is the category where a benchmark arrived first. The same algebraic fact bites much harder elsewhere: it is why sports, the largest event-market category by volume, can only support a benchmark in totals and never in game sides. Working that mapping across the other live categories is a separate piece.

3 — The most valuable output may not be the hedge at all

It is the convenience yield. Compute has a large one and, until this year, no financial leg to measure it against. It now has two, both on the same index — an OTC forward from May and a continuously published curve from July. The spread between the implied forward and the provider term sheet is a price nobody has ever observed, it is economically meaningful to every hyperscaler and AI lab, and it falls out of the construction as a by-product rather than requiring anything new to be listed. That is a weaker claim than the other two — the two legs differ in credit, commitment and deliverability as well as in convenience, and decomposing the gap properly is genuine work rather than a subtraction.