# NeuraMesh Investor Brief NeuraMesh is building a market and settlement layer for GPU-hours. Buyers will be able to purchase immediate capacity, hedge future requirements through monthly forwards, and manage perpetual-style exposure against an approved compute-price index. Providers—from hyperscalers and neoclouds to research labs and smaller operators—can monetize committed capacity through standardized contracts. This brief describes the proposed product, economics, architecture, launch sequence, and principal risks. It is a planning document for discussion, not an offer of securities, a promise of returns, or a legal opinion. ## Executive summary AI compute is becoming a procurement problem and a risk-management problem. Buyers need predictable access to accelerators, while providers need better ways to sell future capacity and reduce utilization uncertainty. NeuraMesh is designed as a brokered, on-chain marketplace for standardized GPU-hour contracts. The initial market model is: - Contract unit: one GPU-hour. - Contract types: spot, monthly forwards/futures, and perpetual-style hedges. - Initial expiry: monthly. - Marking: daily mark-to-market with final settlement at expiry. - Reference price: weighted approved-provider index plus external cloud benchmarks and volume filters. - Trading engine: central limit order book with an AMM fallback. - Initial liquidity: NeuraMesh treasury. - Providers: manually approved only at launch. - Settlement: Sui smart contracts with Walrus evidence and document records. - Payment rails: cards and bank transfers, alongside USDC and NMESH. ## The problem Compute buyers currently combine ad hoc cloud quotes, reservations, broker conversations, and operational guesswork. The resulting purchase is difficult to compare across vendors because hardware, region, delivery window, reliability, metering, and cancellation terms are not standardized. Providers face the inverse problem. They may have future accelerator capacity that is difficult to pre-sell, and they may lack a transparent market for expressing delivery terms without building a full financial product or sales operation. NeuraMesh addresses the coordination problem by making the contract explicit: `hardware × region × delivery window × GPU-hours × verification × settlement` ## Product ### Buyer experience The buyer can: 1. Browse standardized reference markets. 2. Compare hardware, region, expiry, delivery state, and provider terms. 3. Buy immediate capacity or hedge a future monthly requirement. 4. Use USDC, fiat balance, or NMESH as collateral/payment. 5. Receive a 6% compute-purchase discount when NMESH is selected. 6. Monitor margin, open interest, mark-to-market P&L, invoices, receipts, and settlement status. ### Provider experience Providers apply for approval and publish bounded capacity pools. The initial approval process verifies organization, hardware identity, region, delivery window, metering, collateral, data handling, and failure procedures. A provider earns brokered demand without needing to operate a public, permissionless derivatives venue. ### Market experience The market supports three product classes: - Spot capacity for near-term delivery. - Monthly forwards/futures for planned requirements and committed supply. - Perpetual-style hedges for ongoing exposure to the approved compute-price index. The launch UI includes a market tape, order ticket, open positions, portfolio margin, NMESH swap, provider console, and settlement lifecycle. ## Market mechanics ### Contract unit and expiry The base unit is one GPU-hour. Each contract specifies the accelerator class, region, delivery month, quantity, provider eligibility, verification method, and settlement currency. Monthly expiry creates a simple initial calendar and allows providers to quote capacity in a planning horizon they can realistically manage. Minimum order sizes are provider-configurable within a platform-wide minimum floor. This keeps smaller supply visible without allowing unusably fragmented markets. ### Pricing and index construction The reference index is proposed to combine: - Approved-provider quotes. - Executed marketplace activity. - External cloud benchmarks. - Volume, freshness, region, and outlier filters. No single provider should be able to set the settlement price. The index service must publish methodology, input windows, confidence bands, and an emergency fallback rule before production trading. ### Trading and liquidity The proposed venue combines a central limit order book with an AMM fallback. The order book is suited to institutional quotes and explicit limit prices. The AMM fallback gives smaller buyers a predictable execution path when the book is thin. The initial liquidity source is the NeuraMesh treasury. Treasury liquidity must be subject to position limits, transparent inventory reporting, a separate risk budget, and governance-approved withdrawal rules. ### Margin and liquidation The initial risk model uses hybrid margin: - Isolated margin by default, so one position cannot automatically contaminate an entire account. - Optional cross-margin for qualified users after risk and identity checks. - Index-based funding for perpetuals, capped by circuit breakers. - Partial liquidation first, followed by full liquidation if the account remains undercollateralized. - Provider collateral, protocol fees, and NMESH staking contribute to an insurance backstop. These rules are proposed product mechanics and require formal risk modelling, stress testing, legal review, and independent audit before real-money activation. ## Settlement and evidence The settlement path is designed as a hybrid: 1. A provider declares a bounded capacity pool. 2. A buyer trades or receives a claim against that pool. 3. The provider delivers the workload or reserved GPU-hours. 4. The provider submits metering evidence and execution receipts. 5. Independent verification checks the report against the contract. 6. A dispute window allows evidence review and escalation. 7. Sui contracts release payment or apply the failure waterfall. 8. Walrus stores the paperwork, workload references, receipts, and evidence commitments. If a provider fails to deliver, the proposed waterfall is: buyer refund, provider collateral slashing, replacement capacity where available, and dispute escalation. ## Payments and fiat rails The system is designed to support both cards and bank transfers. Fiat can enter through a payment provider and be converted into USDC for trading, while an off-chain fiat balance can support invoices, refunds, and non-trading payment workflows. Production payment architecture must include identity checks, sanctions screening, transaction monitoring, chargeback handling, reconciliation, custody boundaries, and jurisdiction-specific licensing analysis. The local implementation is intentionally a prototype and does not move real money. ## NMESH utility NMESH is proposed as a utility and coordination asset with four uses: - 6% discount on eligible compute purchases when NMESH is selected. - Governance over market parameters, listing standards, and protocol policy. - Staking for the provider-insurance backstop. - Fee rebates for eligible activity. The 6% discount is planned to be funded jointly by the broker commission and the NMESH treasury. The final token economics must define eligibility, discount caps, anti-abuse controls, treasury limits, emissions, unlocks, and the relationship between staking rewards and actual protocol revenue. ## Revenue model The proposed revenue stack combines: 1. Trading fees on executed spot, forward, and perpetual-style contracts. 2. Broker commissions on provider-supplied capacity. 3. Settlement fees for verification, clearing, and document handling. Illustrative gross revenue can be modelled as: `monthly GPU-hours traded × average contract price × trading take rate` `+ provider-delivered GPU-hours × broker commission` `+ settled contracts × settlement fee` The investor model should separate gross volume, net revenue, provider payouts, liquidity incentives, payment costs, verification costs, insurance reserves, and treasury-funded NMESH discounts. Volume alone is not revenue. ## Go-to-market ### Phase 1: controlled testnet - Manual provider approval. - Reference markets without live inventory claims. - Simulated order book, AMM quotes, and settlement receipts. - Synthetic or testnet collateral. - Low account limits before identity verification. - Provider, buyer, and broker workflows tested end to end. ### Phase 2: brokered production pilot - A small set of approved providers. - A small set of anchor buyers with recurring GPU requirements. - Monthly H100, H200, A100, L40S, RTX 4090, MI300X, B200, and multi-GPU markets as liquidity supports. - Fiat payment partner and USDC conversion. - Independent metering and dispute operations. ### Phase 3: scaled market - More providers and regions. - Institutional APIs and agentic procurement. - Deeper order books and professional market makers. - Broader collateral and governance. - EVM interoperability after the Sui/Walrus system is operationally proven. Permissionless provider registration is intentionally deferred until the verification, collateral, reputation, and dispute systems can support it safely. ## Technical architecture ### Frontend The product frontend is React/Vite and retains the deployed NeuraMesh information architecture. New finance routes provide: - `/trade` - `/portfolio` - `/swap` - `/providers` - `/settlement` The prototype trade terminal includes live-style market data, contract selection, order staging, collateral selection, NMESH discount calculation, and portfolio views. ### API layer The repository now includes a dependency-light Node API prototype with endpoints for: - `GET /api/health` - `GET /api/markets` - `GET /api/portfolio` - `POST /api/orders` - `POST /api/swap/quote` - `POST /api/settlements` These endpoints are intentionally in-memory and marked as prototype behavior. They are scaffolding for a production service backed by a database, event bus, risk engine, payment provider, oracle service, and Sui transaction worker. ### On-chain layer Sui Move should own the state that benefits from deterministic settlement: capacity pools, claims, escrow, collateral, settlement transitions, governance parameters, and slashing conditions. Walrus should store large evidence and document artifacts with content commitments referenced by on-chain state. ### Off-chain services Production services will include: - Market data and index service. - Matching engine and AMM quote service. - Margin and liquidation engine. - Provider metering and verification service. - Payment and reconciliation service. - KYC/KYB and account-limit service. - Dispute and evidence operations. - Risk, compliance, and audit event store. ## Risk and compliance boundary Live trading in forwards, futures, and perpetual-style products can create significant financial, legal, market-integrity, custody, payments, consumer-protection, and derivatives-compliance obligations. NeuraMesh should not activate real-money trading until specialist counsel, regulated partners, and independent risk reviewers have mapped the launch jurisdictions and operating model. The main non-technical risks are: - A compute contract may be characterized as a regulated financial instrument. - Provider failure can create correlated settlement losses. - Thin markets can produce manipulation and unreliable index prices. - Fiat payments introduce chargebacks, fraud, custody, and reconciliation risk. - NMESH discounts can create treasury and token-liquidity obligations. - A provider report may be incomplete, delayed, or dishonest. - The insurance fund may be insufficient during correlated outages. - Buyers may misunderstand a compute claim as hardware ownership or guaranteed performance. The safest initial posture is a restricted testnet, manual provider approval, low limits, transparent disclosures, staged contracts, and no representation of live liquidity until the required controls exist. ## Key metrics Investors should track: - Approved providers and active providers. - Contracted and delivered GPU-hours. - Monthly traded notional and open interest. - Bid-ask spread and order-book depth by market. - Buyer repeat rate and provider fill rate. - Delivery verification pass rate. - Dispute rate and average resolution time. - Liquidation rate and insurance-fund coverage. - Fiat conversion success and reconciliation breaks. - Net revenue after provider payouts, incentives, verification, and payment costs. - NMESH discount utilization and treasury exposure. ## Funding use case A first financing round should prioritize market integrity over surface area: - Smart-contract engineering and independent audits. - Risk, oracle, and liquidation infrastructure. - Provider onboarding and verification operations. - Payment, identity, and reconciliation partnerships. - Buyer integrations and demand generation. - Security, monitoring, incident response, and legal/compliance work. The immediate objective is not maximum listed markets. It is proving that a small group of approved providers and repeat buyers can quote, trade, deliver, verify, and settle GPU-hours with clear economics. ## Current implementation status The repository contains the restored deployed NeuraMesh site plus a first finance-layer prototype. The new routes stage orders and quotes locally, and the API scaffold returns prototype data. No wallet signing, fiat movement, production order matching, oracle attestation, KYC/KYB, or real settlement is active. The next engineering milestones are: 1. Add persistent storage and event-sourced order state. 2. Define signed market and contract schemas. 3. Implement Sui testnet transaction flows. 4. Build provider verification and metering adapters. 5. Add account limits, margin calculation, liquidation simulation, and dispute workflows. 6. Integrate a compliant payment and identity provider. 7. Run adversarial testing, economic simulations, and independent audits.