Skip to content
All insights
MANIFESTO

Standardized forwards versus bespoke supply agreements.

Mar 9, 2026 | 10 min read | Rillor
STANDARDIZEDCLAUSE

Two buyers each commit to forty HGX B200 systems for Q4 delivery. The first signs a bespoke master supply agreement: forty pages of negotiated language, a delivery schedule keyed to that buyer's facility readiness, a payment ladder a lawyer spent three weeks shaping, indemnities and acceptance criteria written for one relationship. The second executes a standardized Rillor forward: the same SKU, the same quantity, the same delivery month, on a contract that is identical in form to every other contract on the platform. Both buyers locked their hardware. Only one of them holds something a market can recognize.

That is the entire argument, and it is worth being precise about why. The bespoke agreement is a private artifact. It cannot be compared to the contract next to it, because there is no contract next to it that is shaped the same way. It cannot be priced against the market, because its terms are entangled with one buyer's circumstances. And it cannot be handed to someone else, because the document is a portrait of a single counterparty. The standardized forward gives up a sliver of customization and gets back the three things a bespoke deal can never produce: an observable price, comparability, and a real exit.

What standardization actually means here

The financial vocabulary for this is old and the regulator is unusually clear about it. The CFTC defines a forward contract as one whose terms "may be more personalized than is the case with standardized futures contracts," with delivery time and amount set between the buyer and the seller. A futures contract is the standardized, exchange-traded version of the same idea. The thing that separates the two is not the underlying commodity. It is whether the contract is shaped to one relationship or shaped to a specification.

Rillor contracts are bilateral OTC forwards with intent of physical delivery, which keeps them inside the CFTC forward-contract exclusion rather than making them exchange-listed futures. But they borrow the discipline of the futures world: standardization. Every contract on the platform is defined by the same six fields, and only those six fields vary.

FieldWhat it fixesWhy it has to be standard
SKUThe exact OEM systemA named SKU is a precise, comparable unit. Two contracts on the same SKU describe the same machine.
QuantityNumber of systemsComparable price per unit only exists when the unit is identical.
Delivery monthWhen physical delivery occursTerm structure (the forward curve) is organized by delivery month.
Deposit percentage10% at executionUniform credit terms make positions interchangeable.
Settlement currencyUSDA single currency removes a hidden variable from every price.
Channel-of-recordEnd-customer captured for NVIDIA channel complianceKeeps every contract legitimately transferable inside the OEM channel.

Notice what is not on this list. There is no negotiated indemnity schedule, no buyer-specific acceptance protocol, no payment ladder unique to one balance sheet. The deposit is 10% at execution with the balance at delivery, the same on every contract. An independent escrow agent holds the deposit, the same on every contract. The seller posts a performance bond, the same on every contract. Those mechanics are not negotiable precisely because their uniformity is the product. We walk all six fields in detail in the anatomy of a Rillor forward contract; here the point is narrower, that the form is fixed so the content can be compared.

The SKU field carries more weight than it looks. When the contract says HGX B200 180GB, it is not a category. It is a fixed, named OEM unit: Lenovo's ThinkSystem NVIDIA HGX B200 180GB 1000W 8-GPU board, 180 GB HBM3e per GPU, 7.7 TB/s of memory bandwidth, 900 GB/s NVLink, 1000W TGP, SXM6 form factor. Supermicro's SYS-A22GA-NBRT, Gigabyte's G894-AD1-AAX5, and Dell's PowerEdge XE9680L describe systems built to the same NVIDIA HGX board specification. The internal Rillor SKU (RIL-GX-B200-2T, for instance) is the standardized handle the market trades on. Because the SKU is precise, one contract is priceable against another. Browse the SKU catalog and you are looking at the set of units the market has agreed to make comparable.

Why bespoke cannot be compared, priced, or transferred

Take the forty-page master supply agreement. Suppose a second buyer signs a different one for the same forty systems and the same quarter. Are they paying the same price? You cannot tell. One agreement might bundle on-site installation and a longer acceptance window; the other might carry a tighter penalty for late delivery and a different deposit structure. The number on the signature page is not a price for the hardware. It is the resolved value of an entire negotiated relationship. Two such numbers are not comparable, because they are not measuring the same thing.

This is not a small inconvenience. It is the reason a market never forms around bespoke agreements. The CFTC describes the function of standardized contract terms plainly: exchanges set contract size, delivery months, delivery locations, and acceptable grades, and "this standardization enhances liquidity by making it possible for large numbers of market participants to trade the same instrument." Trade the same instrument is the operative phrase. Bespoke agreements are, by construction, never the same instrument.

Transfer is where the gap becomes physical. A standardized contract can be transferred pre-delivery to another verified buyer, with Rillor and OEM approval, because the obligation that gets handed over is uniform. The new buyer is stepping into the same six fields. Nothing has to be renegotiated, because there is nothing personalized to renegotiate. A bespoke agreement offers no such path. As one plain-language treatment puts it, forward contracts are illiquid and not transferable, and exiting early means renegotiating with the original counterparty. That is the bespoke buyer's reality. If your facility timeline slips or your capacity plan changes, your only counterparty is the seller you signed with, and your only tool is a renegotiation you have no leverage to win. We lay out the mechanics of moving a position in pre-delivery transfer of a forward contract, step by step; the precondition for all of it is that the contract is standard.

The analogy that clarifies it is the oldest standardized commodity contract running. CME Group's Light Sweet Crude Oil future fixes a 1,000-barrel unit, defined deliverable grades, a single delivery point at Cushing, Oklahoma, listed monthly contracts, and physical delivery. No one renegotiates a WTI contract to exit it. They transfer the position, because the contract is the same for everyone. Compute is moving the same direction: a named GPU SKU, a fixed quantity, a delivery month, physical delivery. The fields differ; the logic is identical.

Standardization is the precondition for the curve and the index

Here is the part bespoke buyers do not get to participate in at all. A forward curve is a price plotted across delivery months. The Rillor Compute Index is a 30-day rolling-blend forward price per SKU, computed from active Rillor contracts, owned and controlled by Rillor, and licensed as a settlement feed and API to exchanges, funds, and researchers. Both of those objects require that the inputs be the same instrument. You cannot blend prices across contracts that are not the same contract. You cannot draw a curve through points that measure different things.

This is why standardization is not a convenience feature. It is the substrate. Strip the bespoke language off a hundred GPU supply agreements and you have a hundred private numbers that mean a hundred different things. Standardize the form and you have a hundred observations of the same instrument, which is exactly what a price discovery process consumes. The CFTC frames the two economic functions of organized markets as price discovery and risk transfer, and notes that the prices established affect trillions of dollars in commercial activity. Compute has reached that scale. The infrastructure for pricing it is arriving in real time.

6
Standardized fields per contract
30 days
Rolling blend window for the index
2%
All-in take rate, buyer plus seller

The broader market is now openly building on this premise. Silicon Data introduced the first GPU forward curve with term-structure pricing across a 36-month horizon, initially covering A100, H100, and B200 GPU classes. None of that is possible against bespoke agreements. It is only possible against standardized references.

Rillor's place in that picture is specific and worth stating cleanly. Rillor runs the physical-delivery forward market and owns the index computed from it. Rillor does not operate cash-settled venues and never cash-settles its own contracts; third-party exchanges and funds license the index and build cash-settled products against it downstream. The index is the moat, for reasons we argue in full in the index is the moat, not the marketplace. But the moat has a foundation, and the foundation is that every contract feeding the index is the same contract. Researchers and venues evaluating the feed can read the licensing path on the index page.

What the bespoke buyer gives up

It helps to name the cost in concrete terms, because the bespoke path rarely advertises its downside at signing. The forty-page agreement feels like control. It is, in a narrow sense. But against a standardized forward it surrenders three things.

No exit

If your plans change between signing and delivery, the standardized buyer can transfer the position to another KYC'd buyer. The bespoke buyer cannot. Their position is a one-to-one obligation with no secondary path, so a change in circumstance becomes a stranded commitment or a weak renegotiation. In a market where a fleet's value is dominated by the trajectory of depreciation, the ability to move a position before delivery is not a luxury. It is risk management, and it is the subject of depreciation is the biggest risk in a GPU fleet, and now it is tradable.

No observable price

The bespoke buyer has a number on a page and no way to know whether it is good. There is no curve to check it against, because their contract is not on any curve. The standardized buyer's price sits inside a visible market and can be referenced against the forward curve for the same SKU and month. One is buying in the dark. The other is buying in the light.

No comparability

The bespoke buyer cannot benchmark their own deal, cannot ask whether the next buyer paid more or less for the same systems, cannot use their position as collateral the way a standardized, transferable contract can be financed. Comparability is what makes a contract legible to a lender, a counterparty, or a treasury team, and bespoke language is precisely what destroys it.

Where bespoke still belongs

This is an opinion piece, not a denial of reality. Bespoke supply agreements have a genuine place, and it is the case of genuinely unique configurations. If you are commissioning a one-off system with non-standard interconnect, a custom cooling envelope built for a specific facility, or an integration that no other buyer on earth will ever replicate, you are not buying a commodity and you should not pretend to. A bespoke agreement is the right instrument for a bespoke object.

The honest observation is that almost no GPU procurement is that. The overwhelming majority of buyers are acquiring the same named OEM SKUs that other buyers are also acquiring: an HGX B200 180GB system from Supermicro, Gigabyte, Dell, HPE, or Lenovo ISG, paired with the same class of Intel Xeon 6980P or AMD EPYC Turin head node, the same ConnectX-7 or ConnectX-8 NICs, the same Quantum-2 or Spectrum-X fabric. When the unit is standard, wrapping it in bespoke legal language does not add control. It subtracts liquidity, price discovery, and an exit, and it gives back nothing the standard contract did not already provide. The choice between a forward contract, spot, and OEM allocation is a real one; the choice between standardized and bespoke, for a commodity unit, is not close.

The trade, stated plainly

A standardized forward asks you to accept slightly less customization. The contract is the same six fields as everyone else's, and the mechanics (10% deposit, independent escrow, performance bond, channel-of-record, physical delivery) are fixed rather than negotiated. In exchange you get a position a market can recognize: an observable price, comparability against every other contract on the same SKU, and a transfer path to another verified buyer before delivery. That is the precondition for a forward curve and for the index that prices the entire asset class.

The bespoke agreement asks you to accept the opposite trade. You get full customization of language you mostly do not need, and you give up the price, the comparability, and the exit. For a genuinely unique system, that is a fair deal. For the standard OEM SKU the rest of the market is also buying, it is a bad one. Standardization, not custom language, is what turns a one-off purchase agreement into a liquid, transferable, price-discovering market. That is the whole thesis, and the six fields are the proof.

Access to the market is invite only, on both sides. Verified buyers and sellers transact the standard contract; nobody negotiates a private version of it, because the standard version is the point.

GET ACCESS

Trade the forward curve on Rillor.

Rillor is invite only. Verified buyers and sellers transact standardized forward contracts on OEM GPU systems, with physical delivery and independent escrow on every contract.

Become a Partner
Sources & further reading
GET ACCESS

Trade the forward curve on Rillor.

Rillor is invite only. Verified buyers and sellers transact standardized forward contracts on OEM GPU systems, with physical delivery and independent escrow on every contract.

Become a Partner
NEWSLETTER

Get Rillor market reports in your inbox.

Allocation signals, forward-curve commentary, and product updates. No filler.