What belongs in the contract envelope?#
The brief specifies accelerator class, region, delivery month, quantity, provider eligibility, verification method and settlement currency. The architecture adds pool binding, collateral, outstanding capacity and lifecycle state. Together these fields explain what a buyer receives and which evidence will determine delivery.
GPU-hours alone do not express parallelism, memory capacity, interconnect, permitted workloads or cancellation rights. These constraints must be attached to the terms if they matter to the workload. Otherwise two quantities that look equal in a market view may not be substitutable in execution.
Pool, claim and reservation responsibilities#
The names below document the intended architecture, not a published SDK contract. Exact types, package identifiers, event formats and transaction signatures must be versioned before integrations rely on them.
| Proposed object | Key information | Lifecycle responsibility |
|---|---|---|
| CapacityPool | Provider, hardware, region, window, cap, outstanding units, collateral, active state | Bound issuance to declared supply |
| ComputeClaim | Pool binding, terms, quantity, issuance time | Represent and transfer compatible capacity rights |
| ComputeReservation | Claimant, workload reference, quantity, status, timestamps, result reference | Authorize delivery and connect evidence to settlement |
The invariants that preserve supply#
Issuing a claim must not increase outstanding obligations beyond the pool cap. Splitting and merging claims must preserve the total quantity. Merging requires compatible pool and delivery terms; combining unrelated claims would obscure the provider obligation.
Redemption must check the correct pool, authorized holder and active delivery window. The settlement transition must update the reservation and outstanding counters exactly once. Duplicate settlement events must not release collateral twice or create apparent additional supply.
Outstanding-capacity release is an accounting rule, not automatic renewal of a consumed delivery window. The final contract specification must explain whether units are consumed, expire or can be reused within a remaining time boundary. The high-level architecture does not fully resolve that scheduling policy.
An illustrative split and reservation#
Suppose a pool declares 1,000 eligible GPU-hours for a defined window and has 300 outstanding claim units. An additional issuance of 800 units would exceed the declared cap and should be rejected. A 100-unit claim could be split into 40 and 60 units without increasing the provider obligation.
Redeeming 40 units should bind the delivery request and its evidence to a distinct reservation. The production design must define treatment of partial delivery, unused time, expiry and cancellation before that reservation is offered to buyers. These numbers illustrate invariants; they do not describe available NeuraMesh inventory.
A compute claim is not hardware ownership#
The intended right is to contracted compute service, not to a GPU, a data center, provider equity or guaranteed performance. Transferability of a claim does not make the underlying hardware transferable, and a price hedge does not automatically create the right to schedule a workload.
The precise commercial terms and legal characterization require specialist review for the operating model. Documentation should expose the rights and failure process directly rather than relying on a token label to explain them.
Common questions
Can any two compute claims be merged?
The intended invariant permits merging only when pool and delivery terms match. Equal GPU-hour quantities are not enough.
Does a GPU-hour claim guarantee concurrent GPUs?
Not by itself. Concurrency, topology and access windows must be explicit in the contract terms.
Sources & implementation status
Based on the NeuraMesh investor brief and the project sources below. Source review: . Design explanations are not a deployment audit, legal opinion or commitment to launch.
Read our source and status conventions. Suggest a correction.