How the Rillor Compute Index is computed, field by field.

A settlement source is only as good as the math behind it, and the math should be legible to the people who settle against it. Most reference prices in the world are licensed first and explained second. We think that is backward. If an exchange is going to list a cash-settled product against the Rillor Compute Index, or a fund is going to mark a book to it, the methodology should be auditable before anyone signs anything. This piece is that audit. It walks the entire computation for a single standardized SKU, field by field, from the executed forward contracts that feed it to the JSON your systems will read off the API.

The product here is not the number, which is easy to publish. The product is the methodology: a transparent, reproducible procedure that turns real, physically settled forward contracts into one defensible forward price per SKU per day. Everything below is that procedure, and nothing in it is a black box.

What the index is, precisely

The Rillor Compute Index is a daily forward price for each standardized Rillor SKU. Take RIL-GX-B300-2T, the SKU that abstracts a complete OEM HGX B300 system. That underlying is a real, deliverable product with a defined envelope: a single B300 (Blackwell Ultra) GPU carries 288 GB of HBM3e at roughly 8 TB/s, delivers about 15 PFLOPS of dense FP4, runs at a configurable 1000 to 1400W TDP, and connects over NVLink 5 at roughly 1.8 TB/s. The same architecture scales to the rack as the GB300 NVL72, which Supermicro ships under model number SRS-GB300-NVL72 (72 B300 GPUs, 36 Grace CPUs, 20 TB of GPU memory) and which Rillor abstracts as RIL-NVL72-GB300. The index prices the standardized system a buyer takes delivery of, not a tray of loose accelerators.

Two properties define the index and bound everything that follows.

First, it is computed only from active Rillor forward contracts. There is no survey input, no dealer poll, no scraped spot listing. Every number that enters the calculation is a price two KYC'd counterparties actually agreed to, behind a 10% deposit at execution and a seller performance bond. The integrity of the index is inherited entirely from the integrity of the contracts, which is why physical delivery matters so much here. We cover how those prices accumulate into a curve in how a forward curve forms from real contracts.

Second, it is owned and controlled by Rillor, which computes it, governs the methodology, and licenses it as a settlement feed and API. That ownership is the asset, a point we make in full in the index is the moat. Rillor itself never settles a contract against the index: its own contracts are physical-delivery forwards, always, and the index is the downstream layer that lets other venues build cash-settled products. That line is deliberate and load-bearing, and we return to it below.

The inputs: what counts as a constituent

A constituent is a single executed Rillor forward contract on the target SKU, observed within the trailing 30-day window. Each contributes four things to the computation:

• its executed forward price, per complete system, in USD;
• its delivery month, which assigns it to a bucket (front-month or next-month);
• its notional, the executed price multiplied by the number of systems;
• its execution timestamp, used for recency weighting and the rolling window.

The window is a trailing 30 calendar days ending at the 17:00 UTC stamp: a contract executed 29 days ago is still a constituent, one executed 31 days ago has rolled out. This is a deliberately short memory, because compute prices move with the obsolescence clock, and a 30-day window keeps the index responsive to the live curve rather than anchoring it to stale levels from a prior supply regime.

Delivery month sorts constituents into the two buckets the blend weights. The front-month bucket holds contracts for the nearest standardized delivery month; the next-month bucket holds the one after it. Contracts further out inform the broader forward curve but do not enter the headline value, which is, by construction, a near-curve forward price.

The blend: front-month and next-month into one value

Within each bucket, constituent prices are aggregated into a single bucket price by a notional-and-recency-weighted average. Larger and more recent contracts carry more weight, so that one small or one stale print neither sets the level nor is discarded. This is the same discipline a volume-weighted exchange settlement uses: CME Group sets most equity index front-month daily settlements from a volume-weighted average price, with documented fallbacks when volume is thin. The Rillor bucket price applies that idea to executed forward notional rather than exchange volume.

The two bucket prices are then blended into the headline index value, index_value = (0.50 * front_month_price) + (0.50 * next_month_price), using the published sample 0.50 / 0.50 weighting. So for RIL-GX-B300-2T, if the front-month bucket aggregates to $596,000 per system and the next-month bucket to $582,800, the headline value is:

(0.50 * 596,000) + (0.50 * 582,800) = 589,400

That $589,400 is the published index value for the day, stamped as-of 17:00 UTC. The stamp is fixed so that every consumer of the feed, in every timezone, references the same daily print computed from the same window cutoff. A settlement source has to be unambiguous about its as-of time, and a single global stamp delivers that.

Why a blend rather than a single front-month print

The obvious alternative is to publish the front-month price alone. We rejected that for two reasons, both rooted in how forward markets behave.

The first is roll discontinuity. As a delivery month approaches its cutoff, the front-month bucket empties and what was the next month becomes the new front month. If the index tracked the front month alone, it would jump on the day of the roll, not because the market repriced anything but because the reference point moved, and a cash product settling on the wrong side of that jump would book a phantom gain or loss. Every serious commodity index avoids this the same way, rolling exposure from the lead contract into the next over a defined period rather than in one step. The S&P GSCI rolls its constituents across multiple business days specifically to smooth that transition. The Rillor 0.50 / 0.50 blend is the continuous analog: because both buckets always contribute, the index slides across the roll instead of stepping over it.

The second is single-trade noise. Forward contracts on a given SKU execute at irregular intervals and in different sizes, and a lone large contract at an off-market price can distort a thin front month. Blending two notional-weighted buckets means no single print can wrench the headline value, while a genuine repricing that shows up across both buckets flows through immediately. The blend is the smallest amount of smoothing that kills both artifacts (the roll jump and the single-print spike) without dulling the index's response to the real curve. More smoothing would make the index lag the market; less would let it twitch.

The weights are a published parameter, not a hidden one. A licensee sees the weights, the window length, and the as-of stamp up front, and can reproduce the headline value from the constituents we ship alongside it.

The depth fields: seeing behind the print

A single number is not enough to settle against responsibly. A desk needs to know how much conviction stands behind the level on a given day, so every index value carries its depth, exposed as two fields on every print:

• constituent_trades, the count of executed contracts in the 30-day window that fed the value;
• constituent_notional_usd, the total executed notional those contracts represent.

For the published RIL-GX-B300-2T sample, that is 18 constituent trades and $10.62M of notional behind a $589,400 print. Those two fields turn the index from an opaque number into an auditable one: the day's level rests on 18 real forward contracts and over ten million dollars of committed notional, not a single thin trade. The depth travels with the price so a risk desk never has to guess at the conviction behind a mark.

Depth is also the basis for the freshness logic in the next section. A print is fresh only when its depth clears defined thresholds. When it does not, the same two fields make the thinness visible rather than hiding it.

Freshness: thresholds, stale flags, and gaps

Not every SKU trades enough every day to support a fresh, liquid print. The methodology handles thin days explicitly rather than pretending they are normal. Two thresholds govern freshness.

A SKU prints fresh for the day only when both hold:

• constituent_trades is at or above the minimum-constituent threshold, so the value rests on more than one or two contracts;
• constituent_notional_usd is at or above the minimum-notional threshold, so a few tiny contracts cannot constitute a liquid print on their own.

When either threshold is missed, the SKU does not go dark and it does not fabricate a number. It prints stale-flagged: the value carries forward the last fresh computation, the print is tagged stale, and the depth fields report the sub-threshold activity actually observed in the window. A consumer sees immediately that the level is a carry-forward, not a fresh mark, and can apply its own policy (widen a band, defer a settlement, fall back to a longer window) accordingly. The principle is borrowed directly from exchange practice, where a settlement that fails its minimum-volume test falls back to a defined alternative and anomalous activity that would make a print unrepresentative can be overridden rather than published as fair value.

Gaps are the limiting case. If a SKU records no qualifying constituents at all for a stamp, it prints stale-flagged with the last fresh value, zeroed depth fields, and a stale status, until fresh activity resumes. The two failure modes a settlement source must avoid (a hole in the series, and a thin day dressed up as a liquid one) are both closed by the same flag.

This is also a manipulation defense, because a fresh print requires real notional from real physical forwards across multiple constituents: you cannot conjure a liquid-looking level out of one engineered trade. We go deeper on that property in what makes the Rillor Compute Index hard to manipulate.

Reading the API: GET /v1/forward/curve/RIL-GX-B300-2T

Licensees consume the index over a versioned HTTP API. The canonical endpoint for a single SKU is a GET against its curve resource:

GET /v1/forward/curve/RIL-GX-B300-2T

The response is JSON. The shape, for the sample print above:

{
  "sku": "RIL-GX-B300-2T",
  "as_of": "2026-06-02T17:00:00Z",
  "currency": "USD",
  "index_value": 589400,
  "unit": "per_system",
  "status": "fresh",
  "window_days": 30,
  "blend": {
    "front_month": {
      "delivery_month": "2026-07",
      "price": 596000
    },
    "next_month": {
      "delivery_month": "2026-08",
      "price": 582800
    },
    "weights": {
      "front_month": 0.50,
      "next_month": 0.50
    }
  },
  "constituent_trades": 18,
  "constituent_notional_usd": 10620000
}

Every field maps to something in this article. sku is the standardized Rillor SKU; as_of is the 17:00 UTC stamp; index_value is the blended headline price, in the currency and unit named beside it (USD, per complete system); status is fresh here and would read stale on a sub-threshold day; window_days is the 30-day rolling window. The blend object exposes the two bucket prices, their delivery months, and the published weights, so you can recompute index_value yourself: (0.50 * 596000) + (0.50 * 582800) = 589400. And constituent_trades and constituent_notional_usd are the depth behind the print. Nothing in the payload is opaque, which is the deliverable. Teams building the consuming side, an on-chain feed or an internal mark, will find the design notes in how to design a price oracle from the Rillor settlement feed, and the full set of standardized SKUs is catalogued on the SKU index.

Where the line sits: Rillor never cash-settles

The boundary is the feature that makes the index trustworthy as a settlement source. Every Rillor contract is a bilateral OTC forward executed by commercial counterparties who intend that physical transfer of the actual systems will occur, which is the regulator's own definition of a forward contract and the reason these sit under the forward-contract exclusion rather than being exchange-listed futures. Rillor does not net contracts to cash against any reference price, including its own index.

Cash settlement is a different operation: at expiry, only the net cash difference between a reference price and the contract price changes hands, and no party is ever at risk of making or taking delivery. That is precisely what third-party venues do when they build a perpetual or a future against the Rillor Compute Index. Rillor is the source they reference, never the operator of those cash products. Keeping the physical market that discovers the price separate from the cash venues that settle to it is exactly what lets a venue trust the print: the index cannot be steered by the people settling against it, because they are not the people executing the underlying physical forwards. We make the full case for physical-only settlement in why Rillor settles physically and never cash-settles.

What you are actually evaluating

For an exchange, fund, or quant desk, the thing under evaluation is this methodology, not a single day's level. The whole machine in one breath: executed physical forwards on a standardized SKU, collected over a trailing 30-day window, blended 0.50 / 0.50 across front-month and next-month bucket prices into one daily value stamped at 17:00 UTC, gated by minimum-constituent and minimum-notional thresholds, shipped with the trade count and notional that back it, over a versioned API whose JSON you can recompute by hand. It is auditable on purpose, because a settlement source you cannot audit should not be one you settle against. What it takes to license the feed and list a product is on the markets page and, step by step, in what it takes to license the index and list a compute product.