The GPU compute pipeline, from supply to settlement

The complete delivery sequence#

The physical-delivery path below describes a compute claim or reservation. A perpetual-style index hedge is a different proposed product: economic exposure to a price index must not be presented as a reservation for a specific machine. Its risk and financial settlement rules require a separate specification.

1. 1
   Approve

   Organization, hardware and operating procedures

2. 2
   Declare

   Bounded GPU capacity and delivery terms

3. 3
   Discover

   Comparable markets and fresh quotes

4. 4
   Contract

   Eligibility, collateral and claim state

5. 5
   Deliver

   Authorized runtime and metering

6. 6
   Verify

   Evidence checks and challenge window

7. 7
   Settle

   Payment, refund or failure resolution

1. Establish supply before advertising availability#

A provider submits organizational details, hardware identity, region, available quantity, delivery windows and operating procedures. Manual approval is the initial policy. A capacity pool should bound the amount of supply that can support outstanding claims; listing a provider name is not enough to establish that bound.

Discovery presents those terms in a searchable catalog. A buyer compares hardware, memory, timing, region, price and workload constraints. The catalog is a read model and may be cached. Before a state-changing action, the intended transaction path refreshes authoritative object state and available capacity rather than trusting a stale listing.

2. Separate a quote, a claim and a reservation#

A quote expresses an offer under specified terms. A claim expresses a bounded contractual right. A reservation binds an authorized use of that right to a delivery request or workload. They are separate records because a quote can expire, a claim may be transferable, and an execution request needs a unique identity for metering and settlement.

The proposed transaction flow checks buyer eligibility, applicable account limits, collateral, delivery-window validity and remaining pool capacity. Only after the required state transition is confirmed should the runtime treat work as authorized. The current POST /api/orders endpoint performs none of these production checks; it only stages the submitted object.

3. Execute against an authorized reservation#

An orchestrator receives a reservation, matches provider capabilities, retrieves authorized workload references, schedules an isolated runtime and collects metering. It must not be able to create its own capacity or alter claim ownership merely because it runs the job.

The delivery terms determine what gets measured: eligible GPU time, hardware identity, window, workload association and any required result artifact. A batch workload may also need reproducibility metadata; a reserved-capacity agreement may measure access rather than model quality. The contract must decide this before delivery, not after a dispute.

If execution is interrupted, an explicit retry and checkpoint policy is needed. Replaying an event must not run and bill the same reservation twice. These are production design requirements, not guarantees implemented by the local finance scaffold.

4. Turn evidence into a settlement decision#

The provider submits reservation-bound metering and execution receipts, with large artifacts or commitments stored through the proposed Walrus evidence layer. An independent check compares the report to the contract. The design includes a challenge window so missing or contradictory evidence can be reviewed before a final decision.

On successful verification, the intended Sui transition releases the appropriate payment and records final state. On failure, the brief proposes a buyer refund, provider collateral slashing, replacement capacity where available and escalation. Neither evidence upload nor an HTTP 201 response is proof that this final settlement occurred.

• Read verification, disputes and failure handling ↗
• Read claim and reservation invariants ↗

Trace one example without confusing units#

Illustrative workload: a buyer needs four eligible GPUs for six hours within an agreed window. The quantity is 24 GPU-hours, subject to the specified hardware and delivery terms. A 24-GPU-hour claim does not automatically guarantee four-way parallel access; concurrency and topology must be explicit.

The intended evidence trail links provider approval, the pool, the quote or order, the claim, the reservation, metering, verification and settlement. A useful operational trace allows an auditor to ask what was authorized, what was delivered and why money was released without inferring those answers from a dashboard balance.