Browse documentation
DocsBuild & reference
Reference

NeuraMesh glossary and documentation sources

The docs use GPU-hours for a quantity of accelerator time, claims for proposed contractual rights, reservations for authorized delivery, evidence for supporting records, and settlement for the final authorized outcome. These terms describe distinct responsibilities and should not be used interchangeably.

On this page

Capacity and delivery terms#

GPU-hour: one eligible GPU used or made available for one hour under specified contract terms. It is not a universal performance unit across different accelerators. Hardware, memory, topology, concurrency and delivery conditions remain relevant.

Capacity pool: a proposed bounded supply object associated with a provider, hardware class, region and delivery window. Its capacity cap and outstanding units constrain issuance. It is not merely a searchable product listing.

Compute claim: a proposed right to a quantity of service under matching pool and delivery terms. It does not represent ownership of hardware. Compute reservation: the authorized consumption record connecting a claimant and workload to a delivery obligation.

ComputeJob: the individual-job model found in the existing Move marketplace source. It should not be treated as an implemented equivalent of every proposed capacity-pool or financial-market object.

Market and risk terms#

Spot capacity refers to near-term delivery. A monthly forward or future refers here to the brief’s proposed dated product for planned requirements; final product terms and classification remain to be defined. A perpetual-style hedge refers to ongoing price-index exposure and does not automatically grant physical compute access.

Reference index: a proposed price derived from eligible observations under a published methodology. Mark-to-market: revaluing a position against the applicable reference. Funding: a proposed transfer mechanism for perpetual-style exposure, requiring an explicit formula and timing policy.

Isolated margin allocates backing to an individual position. Cross-margin shares backing across eligible positions and can connect losses. Liquidation is a risk action intended to reduce an undercollateralized position; it is not the same as verifying workload delivery.

Open interest describes outstanding positions under a defined counting convention. Traded notional describes transaction value, not revenue. Basis risk is the difference between a buyer’s actual compute cost and the exposure represented by its chosen reference or hedge.

Evidence and operations terms#

Metering measures the eligible service delivered under the contract. A receipt records assertions about that delivery and must bind them to the relevant reservation. An attestation is an assertion or verification result whose value depends on its issuer, method and scope.

A content commitment binds a reference to particular data; it does not establish the truth of a provider’s report. A challenge window provides a period for disputed evidence to be raised under explicit rules. Settlement is the final authorized state transition, such as payment or refund, after the applicable conditions are met.

Reconciliation connects records across payment, account, market and settlement systems. Idempotency means retrying the same intended operation does not create an additional unintended effect. Neither feature is implemented by the current in-memory staging arrays.

How this documentation was assembled#

The investor brief is the main source for product scope, economics, market mechanics, launch sequence and principal risks. MARKETPLACE_ARCHITECTURE.md supplies the intended service boundaries and capacity invariants. server/api.js is the authority for the six local HTTP routes described here.

The Move marketplace and TypeScript client were inspected to distinguish source scaffolds from the planned object model and a verified deployment. Where the investor brief and code differ, the docs state the difference instead of treating the broader plan as shipped functionality.

The documentation was prepared with AI assistance from those project sources and reviewed against the inspected code on October 9, 2026. Source inspection is not an audit, production benchmark or legal opinion. Linked source snapshots make the documented inputs inspectable; they should be updated with substantive code or design changes.

Parameters that must not be inferred#

The sources do not finalize margin ratios, leverage limits, funding formulas, index weights, dispute-window duration, all fee schedules, token supply or unlocks, complete receipt schemas, or launch dates. A numeric example in these docs is labeled illustrative or identified as a code fixture.

For an implementation issue, use Support. For a documentation correction, send the page, the disputed statement and a relevant source through Contact. Before committing to any production workflow, verify the actual deployed version and published contract terms.

Common questions

Are these docs a smart-contract audit?

No. They explain inspected prototype behavior and proposed design. They do not certify a deployment, security posture or economic model.

What happens when the brief and code disagree?

Current implementation claims follow the inspected code; future product descriptions remain labeled as proposals. The docs call out material gaps between them.

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.