## Benchmark statement Version 2026-09-27. This page is the governance statement for the corpusAI Cloud Pricing indices: who runs them, what they measure, how they are computed and changed, and how a published fixing can be verified. This statement follows the structure of a benchmark statement under the EU Benchmarks Regulation (BMR) and IOSCO's Principles for Financial Benchmarks. corpusAI is not a registered benchmark administrator, and the indices are not used, and may not be used, as the reference for any regulated financial contract without a written agreement; the structure is adopted because it is what data buyers, exchanges and integrators ask for when they decide whether a number can be relied on and cited. ## 1. Administrator and scope The administrator is corpusAI, operated by Julian Traversa, contact hello@trycorpus.ai. This statement covers every series published under a `CX.` ticker: - GPU rental fixings, `CX..`, one per GPU model and segment. - Hyperscaler spot legs, `CX..SPOT` and `CX..SPOT.`. - LLM token fixings, `CX.TOK..IN|OUT|BLEND` and the frontier basket `CX.TOK.FRONTIER.`. - The capacity stress score per GPU model. - The term structure per instance and per GPU. The methodology for each is published at `/methodology` and versioned; this statement governs how that methodology is set, changed and applied. ## 2. What the indices represent Each GPU fixing is the median USD price per GPU-hour that a buyer could have paid, on the fixing day, for the named GPU in the named market segment, computed from the latest snapshot of every provider quoting it. Fixings are observed list and executed prices, not transactions cleared by corpusAI, and not a forecast. The token fixings are medians of published per-million-token prices across hosting providers. The capacity score is a diagnostic composite, not a price. The economic reality measured is the rental market for accelerated compute, across neo-clouds, marketplaces, aggregators and hyperscalers, as it is offered to the public. The indices are designed to be representative of what an agent or buyer can act on today, and to be reproducible from the published inputs. ## 3. Inputs and hierarchy Inputs, in order of preference: 1. **Executed prices** where a venue publishes them: Nosana completed jobs, Akash active leases, Vast.ai offers observed to disappear and reappear rented (the `EXE` segment). 2. **Quoted prices** read from provider APIs, taken as published, with the source URL stored on every quote. 3. **Quoted prices** parsed from provider web pages where no API exists; the methodology names each such provider. 4. **Hyperscaler spot prices** from corpusAI's own price-change event collectors, plus labelled third-party archives for history before those collectors ran, each row carrying its source. No input is ever entered by hand, estimated, or interpolated. Where an input is missing the fixing is published with a smaller `n`. A fixing computed from fewer than three eligible quotes is published with `indicative: true` and should be read as one or two providers' prices, not a market level. No discretion is exercised in the daily computation. ## 4. Eligibility and exclusions The eligibility rules on the methodology page are applied identically every day: unavailable listings, placeholder prices, variants excluded by market type, and stale snapshots are dropped before aggregation. The complete member list of each segment is published, and every fixing reports `members` so a reader can see which providers were present. ## 5. Calculation and timing Fixings are computed once per UTC day from the day's snapshots after 00:00 UTC, as described under Timing on the methodology page, and never recomputed for a past day under the same methodology version. Intraday snapshots (hourly for Vast.ai) feed the executed-price and supply inputs only. The software that computes the fixings is the same software that serves them. ## 6. Methodology changes and versioning - Every change to inputs, eligibility, segment membership, aggregation or timing ships as a new methodology version string, `YYYY.MM.DD-n`, served on every fixing and listed in the Revisions section of the methodology page with what changed and why. - A fixing never changes under the same version. If a computation error is found, the corrected series is published under a new version and the erroneous one stays retrievable by version. - Material changes (a new segment, a change to aggregation, removal of a provider that supplied more than a fifth of a segment's quotes) are announced on the feed and the methodology page at least 7 days before they take effect. Additions of providers and GPU models are not material. - Changes are announced, with a written rationale, rather than put to consultation. If an index becomes the reference for a contract or an on-chain integration, a consultation window will be added for material changes to that index. ## 7. Conflicts of interest corpusAI sells access to the data the indices are computed from and receives payment per call. It does not rent, sell or trade compute, does not hold positions whose value depends on the indices, and receives no payment from any provider for inclusion, ranking or price. Providers can request correction of a misread quote; they cannot request exclusion of a valid quote. Any commercial relationship with a provider that supplies inputs will be disclosed on this page. Financial interests of the operator in companies whose prices appear as inputs are listed on the [disclosures page](https://cloud.trycorpus.ai/disclosures). Inclusion and treatment of every provider are identical and mechanical. ## 8. Signed fixings and record keeping Every fixing served by the API carries an EIP-712 signature by the corpusAI publisher key, so a quoted number can be verified against corpusAI without trusting the channel it arrived by, off-chain or on-chain. This is not required by any benchmark standard; it is offered because it is cheap and removes a class of disputes. - Publisher address: `0x1b77aE05cd23C514A1De304b6b771513f6eFa780`. Any change is announced here at least 7 days ahead, and the retired address stays listed with its validity period. - Domain: `{{ "name": "corpusAI Cloud Pricing", "version": "1" }}`, no chainId, so the attestation is valid on every chain. A domain bound to an oracle contract would be published as version 2 alongside it. - Primary type `Fixing`: `string ticker`, `string day`, `uint256 valueE18` (USD per unit × 10^18, the same scale as an 18-decimal ERC-20), `uint32 n` (eligible quotes), `string methodology`. - Every fixing response includes `attestation` with the domain, the types, the message and the signature. Signatures are deterministic (RFC 6979). **Verifying a fixing.** Off-chain, with any EIP-712 library, recover the signer from the domain, types and message and compare it with the publisher address. With viem: ``` verifyTypedData({ address: attestation.publisher, domain: attestation.domain, types: attestation.types, primaryType: 'Fixing', message: { ...attestation.message, valueE18: BigInt(attestation.message.valueE18) }, signature: attestation.signature }) ``` On-chain, hash the struct with `hashTypedDataV4` under the same domain and recover with `ECDSA.recover`; a contract can therefore accept a fixing submitted by anyone and reject anything the publisher did not sign. Raw inputs (every snapshot and event, with source URL and timestamp) are kept for at least five years in the archive; fixings and methodology versions indefinitely. ## 9. Errors, complaints and contact Suspected errors go to hello@trycorpus.ai with the ticker, day and the value in question. corpusAI acknowledges within two business days, investigates against the archived inputs, and publishes the outcome under Revisions if a correction results. Complaints about the methodology are answered in writing. There is no fee for either. ## 10. Cessation If corpusAI stops publishing an index it will announce the date at least 90 days ahead on this page and the feed, continue serving historical fixings by version, and release the final methodology and the archived daily fixings for that index under the data licence so a successor administrator can continue the series. ## 11. Review This statement is reviewed at least annually and whenever the methodology changes materially; the review date and any change are listed here. | Date | Change | |---|---| | 2026-09-27 | First version |