What it takes to license the index and list a compute product.

There is now a clean, public reference price for the most consequential capital good in technology: a complete OEM GPU system, by SKU, on a forward curve. Exchanges, regulated venues, and DEX teams have started asking the obvious next question. Can we list a product on that. The answer is yes, with a precise set of requirements and one boundary that does not move. This piece is the go-to-market explainer for the business teams who would build a cash-settled perp, future, or option referencing a Rillor SKU. It covers the licensing relationship, who tends to license, how you must attribute the source, which reference SKU to pick, the operational dependencies your product has to respect, and why a live cash product makes the underlying physical market deeper rather than thinner.

The relationship, in one sentence

You license the Rillor Compute Index, take it as a settlement feed and API, and reference it in the rules of a cash-settled product that you list and run. Rillor stays the administrator of the price. That separation is not a courtesy. It is the entire structure.

The index itself is a 30-day rolling-blend forward price per SKU, computed from active forward contracts transacting on Rillor, and owned and controlled by Rillor. We publish a methodology, run the calculation on a fixed schedule, and license the output. You consume it the same way a venue consumes the CME CF Bitcoin Reference Rate to cash-settle a listed future, or the way an energy desk references a published benchmark. The mechanics are familiar from every commodity and rate market that came before this one. What is new is the underlying: complete, deliverable GPU systems instead of a barrel of crude or a troy ounce.

Access is invite only, and it starts as a conversation rather than a form. There is a reason for that beyond exclusivity. A reference price that settles real money carries governance obligations to everyone downstream of it. Before we license the feed into a product, we want to understand the product, the venue, the rulebook, the audience, and the failure modes. That is the licensing conversation, and it is where the relationship is defined. You can open it through for markets or become a partner.

Who licenses a compute price, and what the precedent looks like

The candidate licensee is anyone who can responsibly list and clear a cash-settled product and who has an audience that wants exposure to compute hardware price without taking physical delivery. In practice that is three profiles.

The first is the regulated derivatives venue. A CME-style listing of a cash-settled future or option on a RIL- SKU is the cleanest precedent, because the entire apparatus already exists: a published reference rate fixes at a set time, listed contracts cash-settle to that fix, and the administrator of the rate is structurally separate from the exchange. The CME CF Bitcoin Reference Rate is the template. It is calculated once daily over a fixed observation window and serves as the official settlement price to which CME's listed crypto futures and options cash-settle. Swap the underlying and the architecture transfers directly. Nothing about that pattern is specific to crypto. It is the same separation of administrator and venue that energy, rates, and metals benchmarks have run on for decades.

The second is the perpetual-futures venue. The perpetual, a futures-style contract with no fixed expiry that holds its mark to an underlying reference through a periodic funding mechanism, has been the dominant instrument in offshore compute-adjacent and crypto trading for years, and the structural question it raises is the one that matters here. A perpetual marking to a reference price is a third party listing a cash-settled product against a number it does not itself produce. A B300 or MI355X perp on a venue, marking against the Rillor fix at each funding interval, sits squarely inside that structure. The venue runs the funding, the margin, and the settlement; Rillor supplies only the reference level the funding rate is computed against.

The third is the DEX or on-chain venue that wants an oracle-grade price for a synthetic or margined product. The feed is the same. The integration is an API and an oracle design rather than a clearing rulebook: the venue pulls the published fix, posts it on-chain through whatever oracle pattern it already trusts, and references that on-chain value in the contract logic that settles or liquidates positions. The discipline that matters is the same discipline a regulated venue carries, just expressed in smart-contract terms instead of a rulebook.

What unites all three is that they build and run the cash product. We do not. We administer the number.

Attribution and display: source, never operator

Licensing the index comes with display requirements, and they are not branding niceties. They protect the integrity of the price for every party referencing it, and they protect both of us legally.

The rule is simple to state. You present Rillor as the reference-price source. You never present Rillor as the venue operator, the listing entity, the clearer, or the counterparty to any trade. Your product is yours. The price is ours, and it is cited as such.

Concretely, that means your contract specifications, marketing, and settlement notices identify the settlement reference as the Rillor Compute Index for the named SKU, attribute it to Rillor as administrator, and link the published methodology. It means you do not imply Rillor endorses, guarantees, or stands behind your product's performance, because we do not. And it means your disclosures make clear that Rillor's own market is physical-delivery forward only, so a reader cannot confuse your cash-settled product with a Rillor contract.

This mirrors the governance standard that benchmark administrators operate under globally. IOSCO's Principles for Financial Benchmarks, endorsed by the Financial Stability Board as best practice, require a benchmark administrator to maintain a published methodology, robust governance, an oversight function, and conflict-of-interest controls. Those are exactly the controls that keep an administrator a reference-price source rather than a market operator or a counterparty. Holding that line in your attribution is how the index stays clean enough to be worth referencing.

The hard boundary: you cash-settle, we never do

This is the part to internalize before anything else, because it shapes the whole product. Rillor runs a physical-delivery forward market. We do not cash-settle, we will not cash-settle, and we do not operate the venues that do.

The distinction is the one CME draws plainly. In a cash-settled contract no participant is ever compelled to make or take delivery. At expiry a final settlement price is determined and each party simply pays or is owed money. A physically delivered contract is the opposite: it ties the contract directly to the underlying physical market through the delivery mechanism. Rillor lives entirely on the physical side. Every Rillor contract is a standardized OTC forward on a complete OEM GPU system, with physical delivery always, a 10% deposit at execution, balance at delivery, an independent escrow agent, seller performance bonds, and NVIDIA channel compliance with the end customer of record captured on every contract. Under the CFTC's own definitions, a forward is a commercial transaction between commercial counterparties in which the parties intend that physical transfer of the actual commodity will occur. That intent is real on Rillor. It is what keeps these contracts forwards rather than futures, and it is why a Rillor contract is not, and will never be, a cash-settled instrument.

So the labor divides cleanly. You build the cash-settled perp, future, or option. You list it, margin it, clear it, and settle it in money against the Rillor fix. We compute and license the fix, and we keep transacting the physical forwards that produce it. Nobody is doing both jobs, and that is the point. The reason the index can be trusted as a settlement reference is precisely that its administrator has no position in your cash market and no incentive to move the number for or against your open interest. An administrator that also ran a cash venue against its own number would be conflicted on its face. Rillor structurally is not, because the only place Rillor takes a position is the physical forward book, and that book is what the index is computed from, not bet against.

Choosing your reference SKU

The published SKU set lets you match the reference price to your audience. The index is computed per SKU, so the contract you list inherits the character of whatever underlying you point it at. Four are the natural starting candidates.

RIL-GX-B300-2T is the frontier price. Each Blackwell Ultra GPU carries 288 GB of HBM3e, 50% more than the original B200's 192 GB, built on 12-high stacks. If your audience wants exposure to where the training market is actually clearing, this is the contract to reference. RIL-NVL72-GB300 points at the full GB300 NVL72 rack, a liquid-cooled system unifying 72 Blackwell Ultra GPUs and 36 Grace CPUs with 20 TB of GPU memory and 1,440 PFLOPS of dense FP4, for products aimed at rack-scale and hyperscaler thinking.

RIL-MI355X-2T is the choice for a venue building an alternative-silicon book. The MI355X delivers 288 GB of HBM3e at 8 TB/s on 4th Gen CDNA with native FP4 and FP6, and its price moves on a different supply story than NVIDIA's. A product that references it gives traders a way to express a view on the AMD curve specifically. RIL-H200-2T points at the broad, prior-generation installed base, where depth tends to be highest and price history is longest, which can be the right call for a first listing that needs steady reference liquidity. The full published set, including RIL-NVL72-GB200, RIL-NVL36-GB300, and the rest, lives on the SKU catalog, and the live tape is on the marketplace.

Operational dependencies your product must respect

Once you license the feed, your contract rules inherit a set of operational facts about how the index behaves. Bake these into the rulebook from day one.

Cadence. The index fixes once daily, at 17:00 UTC, per SKU. This is the operational analog of a single daily benchmark fixing, the same shape as a reference rate that calculates over a fixed window and publishes one official number that listed products settle to. Your settlement and mark-to-market logic has to align to that 17:00 UTC fix. A perp that funds continuously still has to anchor its index reference to the published value and define exactly how it interpolates between fixes. A dated future settles to the fix on its expiry date. The cadence is the heartbeat your product schedules against.

Depth gating. The index will not publish a value for a SKU on a day when the underlying forward activity is too thin to compute a robust number. This protects everyone downstream from a fix set by one stale or unrepresentative contract, and it is part of what makes the index hard to manipulate. Your rulebook needs a defined behavior for a gated day: hold the prior fix, widen a band, or pause settlement, chosen deliberately rather than left undefined.

Staleness handling. Related to depth gating, your product needs an explicit answer for what happens when a fresh value is unavailable for a SKU, whether from gating, a calculation hold, or a feed interruption. Define the fallback in the contract specs, not in an operations runbook discovered during an incident. The thinner-liquidity SKUs need this most, so a venue listing on RIL-H200-2T inherits a different staleness profile than one listing on RIL-GX-B300-2T, and the rules should reflect it.

These three, cadence, depth gating, and staleness, are the operational contract you take on when you license the feed. They are not obstacles. They are the same disciplines that make any settlement benchmark dependable enough to clear money against.

Why listing deepens both sides

There is a flywheel here, and it is the reason this is worth doing for everyone involved. A live cash-settled product on a RIL- SKU pulls liquidity toward the physical forward that computes the index, which deepens both markets at once.

The mechanism is straightforward. When a venue lists a cash-settled B300 product, it creates a population of participants who want exposure to the B300 price but do not want to take delivery of a rack: speculators, funds hedging compute exposure, and venues themselves arbitraging the basis. Their activity sharpens the cash price, and the cleanest place to express or hedge a view formed in the cash market is against the physical forward that the index is computed from. More eyes on the price, more hedging flow into the forward, a deeper and more representative forward book, and a more robust index as a result. The cash product and the physical market reinforce each other. This is also why the index, not the marketplace, is the durable asset, and why Rillor treats the index program as the center of the franchise rather than a side feed.

None of that changes Rillor's lane. The deepening flows entirely to the physical forward, where actual buyers and sellers transact deliverable systems. The speculative interest stays in your cash venue, where it belongs, and never touches a Rillor contract. That is the system working as designed: your product gives the market a price-discovery and hedging surface, and Rillor keeps delivering hardware.

Where to start

If you run a venue and want to list a compute product, the next step is the licensing conversation, not an integration ticket. We will want to understand your product design, your rulebook, your audience, and how you intend to attribute the source and handle the cadence, depth gating, and staleness requirements. From there we scope the feed, the API, and the license terms, and you build.