Phase 1: prove the controlled loop#
The intended testnet uses manually approved providers, reference markets, simulated order-book and AMM quotes, synthetic or testnet collateral, low account limits and end-to-end buyer, provider and broker workflows. The current repository supplies parts of that experience, not proof that the full testnet loop is operational.
The immediate engineering sequence is persistent storage and event-sourced order state; signed market and contract schemas; Sui testnet transaction flows; provider verification and metering adapters; and account limits, margin calculation, liquidation simulation and dispute workflows. Each milestone should be demonstrated with traceable state and failure tests.
A useful exit condition is the ability to reconstruct one complete obligation from quote through final outcome after a service restart. The system should also demonstrate rejected over-issuance, duplicate-event handling, missing evidence and non-delivery. These are proposed acceptance criteria inferred from the architecture, not completed test results.
Phase 2: a small brokered production pilot#
The brief proposes a limited group of approved providers and anchor buyers with recurring GPU requirements. That narrower scope makes delivery verification, dispute handling and reconciliation observable before a large catalog makes failures harder to isolate.
Required work includes a payment and identity partner, independent metering, dispute operations, adversarial testing, economic simulations, independent audits and jurisdiction-specific review. A signed commercial relationship, configured infrastructure and verified capacity must precede a live availability claim.
The contemplated hardware set includes H100, H200, A100, L40S, RTX 4090, MI300X, B200 and multi-GPU configurations as liquidity supports. This is an expansion direction, not a launch inventory list. A single reliably delivered market is more valuable evidence than many simulated listings.
Phase 3: scale only after the operating model holds#
The planned scaled market adds providers and regions, institutional APIs, agentic procurement, deeper books, professional market makers, broader collateral and governance. EVM interoperability is explicitly later than operational proof of the Sui/Walrus system.
Permissionless provider registration is also deferred. It requires verification, collateral, reputation and dispute systems capable of supporting participants without the same manual relationship. Removing a manual gate without replacing its risk controls would change the trust model rather than merely improve onboarding.
Where the longer-term opportunity could develop#
Agentic procurement is one possible extension: a software agent could translate a workload envelope into eligible capacity, compare terms and prepare a bounded request. It still needs a spending policy, approved counterparties, contract authority and limits. Automation does not eliminate provider trust or execution risk.
Institutional integrations could connect forecasting, purchase approvals, invoices and capacity reservations to a shared contract model. Their value would depend on consistent schemas and reliable operational data rather than the number of API methods.
A deeper market could help providers express future supply and buyers compare future requirements. Whether it produces useful liquidity and risk-management products depends on genuine two-sided activity, robust reference prices and jurisdiction-specific operating constraints. These are hypotheses to validate, not revenue forecasts.
Evidence that should determine the next stage#
The brief lists providers, contracted and delivered GPU-hours, traded notional, open interest, spread and depth, repeat buyers, fill rate, verification outcomes, disputes, liquidations, insurance coverage, payment reconciliation and net revenue. Definitions should distinguish fixtures, treasury-supported activity and external production usage.
| Question | Useful evidence | Misleading substitute |
|---|---|---|
| Can supply deliver? | Verified delivered GPU-hours and failure outcomes | Listed hardware or claimed pool size |
| Do buyers return? | Repeat demand and fulfilled requirements | One-off incentive-driven volume |
| Does the market work? | Executable depth, spread and valid index inputs | A live-style market tape |
| Are economics durable? | Net revenue after costs, losses and discounts | Gross traded notional alone |
| Can operations recover? | Reconciled events, incident and dispute results | A successful demo without failure testing |
Funding priorities and unresolved risks#
The investor brief prioritizes smart-contract engineering and audits; risk, oracle and liquidation infrastructure; provider onboarding; payment, identity and reconciliation partnerships; buyer integrations; and monitoring, incident response and specialist review.
The unresolved risks include thin-market manipulation, dishonest metering, correlated non-delivery, chargebacks, custody boundaries, reserve inadequacy and treasury exposure. The goal is not to claim these risks disappear through tokenization. It is to make obligations explicit, bound authority and demonstrate that controls work under stress.
Common questions
When will production launch?
The investor brief does not commit to a date. Readiness depends on engineering, provider delivery, payments, verification, risk review and operational prerequisites.
Is EVM support available now?
It is a later proposed direction after the Sui/Walrus system is operationally proven, not a current integration.
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.