What evidence must connect to a reservation?#
The architecture calls for signed hardware identity or runtime attestation, a reservation-bound metering receipt, workload and result references, and inspectable evidence commitments. The exact receipt schema remains an implementation milestone. At minimum, the design must make it possible to identify the obligation being measured and the party making each assertion.
A receipt needs a meaning defined by the contract. Did the buyer purchase reserved access, elapsed eligible GPU time or completion of a specified workload? A successful output file cannot answer all three questions. The terms and verification method must be established before delivery.
Walrus is an evidence layer, not a verdict#
The proposed data path puts large documents, workload references, metering records, result artifacts and challenge evidence outside the transaction payload. On-chain state references commitments rather than embedding large model weights or result data.
Content-addressed evidence helps associate a decision with a particular artifact. It does not establish whether a provider fabricated the measurement, ran the correct hardware or honored a privacy requirement. Access control, encryption, retention and availability policy are separate responsibilities.
Independent verification and challenge handling#
The intended verifier compares the provider report against the reservation and contract. A challenge window lets the buyer or relevant operator raise discrepancies. The brief does not fix the window duration, verifier selection rules, proof thresholds or escalation service levels.
A production process needs to preserve the contested evidence, identify the decision authority and record why an outcome was chosen. A retry of a verification event must not generate a second payout. An unavailable evidence reference must have a defined failure state rather than being silently treated as success.
| Stage | Required question | Expected record |
|---|---|---|
| Submission | Which reservation and contract does this receipt describe? | Provider report and immutable artifact references |
| Verification | Does the report meet the specified delivery test? | Decision, input version and responsible authority |
| Challenge | Is evidence missing, contradictory or disputed? | Challenge, response and resolution trail |
| Finalization | Which authorized outcome applies exactly once? | Payment, refund or other final state |
The proposed non-delivery waterfall#
The brief gives the sequence as buyer refund, provider collateral slashing, replacement capacity where available and dispute escalation. This is a proposed operating policy. The source does not define complete accounting, reserve priorities or every partial-delivery outcome.
Replacement is explicitly conditional on availability. It may not be equivalent if region, memory, timing or topology differ. Correlated failures can affect both replacement supply and reserve adequacy, so neither collateral nor a replacement policy should be described as a delivery guarantee.
What the current implementation does#
POST /api/settlements returns HTTP 503 and creates nothing. The prototype performs no evidence verification, dispute review or Sui transaction, and it no longer stages settlement records, so there is no local artifact that could be mistaken for a cleared delivery.
The separate Move marketplace source has a ComputeJob completion path that transfers payment and records a result reference. That simpler source flow is not the complete independent verification and challenge process described here. A production integration must reconcile the models and test the full lifecycle.
Common questions
Does uploading a result trigger verified settlement?
Not in the documented production design. Delivery evidence needs the specified checks and challenge process; the local HTTP endpoint does not perform them.
How long is the dispute window?
The investor brief does not finalize a duration. A production contract must state it explicitly before buyers commit.
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.