NeuraMesh architecture and trust boundaries

Five responsibilities, not one trusted backend#

A searchable catalog should not decide who owns a claim. A node scheduler should not mint capacity. An evidence store should not decide whether a buyer must pay. Keeping these responsibilities separate makes the trust assumptions and recovery process visible.

Read paths and write paths use different authority#

The read path runs from a browser or agent through a discovery API to indexed Sui events, object reads and provider capability references. Cache invalidation and freshness matter, but a stale read need not itself mutate contract state.

The intended write path uses authorized, signed operations to create pools, issue or transfer claims and redeem a claim into a reservation. Execution then produces artifacts, and a permitted settlement operation updates final state. The API should coordinate and prepare these steps without taking custody of user keys.

Buyer / provider -> authorization -> Sui contract state
                           |                |
                    discovery view    reservation event
                                            |
                                      node runtime
                                            |
                                  metering + receipt
                                            |
                                    Walrus reference
                                            |
                             verification / challenge
                                            |
                                   Sui final state

Off-chain services required for production#

The brief identifies market data and index construction, matching and AMM quotes, margin and liquidation, provider metering, payment reconciliation, identity and account limits, and dispute operations. A database, event bus and audit event store connect their workflows.

An implementation needs durable identifiers, retry-safe consumers and a way to reconcile events against authoritative state after downtime. A service restart must not erase open obligations. A payment callback must not release an unrelated reservation. These are engineering implications of the proposed boundaries, not evidence that those controls already exist.

Where failures cross a trust boundary#

Provider declarations can misstate physical capacity; signed hardware identity, attestation, collateral and capacity policy are proposed controls. An index can be stale or manipulated; transaction-time refreshes, input-quality checks and bounded oracle authority limit the damage. A workload can leak sensitive data; access scope, runtime isolation and a clear retention policy must be specified.

A content commitment proves the relationship to particular bytes, not that those bytes truthfully describe a GPU run. Metering needs reservation binding and independent checks. A settlement decision also needs accountable dispute operations, because a deterministic transaction can faithfully execute a bad input.

How the repository differs from the target architecture#

server/api.js is an in-memory HTTP scaffold. marketplace.move defines ComputeJob creation, assignment, completion, failure and refund paths. The capacity-pool, claim and reservation vocabulary comes from the architecture design and is not the object model implemented by that marketplace file.

The TypeScript client includes deployment placeholders. The finance interface is not evidence that these source files are configured together or audited. Production integration requires an explicit migration and schema versioning plan so consumers do not treat an older job object as a fully specified capacity claim.

• Inspect the implemented API ↗
• Read the integration milestones ↗