Who is the provider model designed for?#
The investor brief includes hyperscalers, neoclouds, research labs and smaller operators. These are intended provider categories, not confirmed partnerships or an approved-provider roster. The initial production concept is a small brokered pilot with identifiable supply and recurring buyers.
The advantage proposed for a provider is structured demand and explicit delivery terms without independently building a public financial venue. The trade-off is operational accountability: capacity declarations, evidence, collateral and failure handling must be verifiable, not simply listed in a profile.
What must onboarding establish?#
Approval should assess both identity and the ability to fulfill a particular obligation. Hardware ownership alone does not establish scheduling rights, workload isolation or reliable metering. A provider must explain how its declared capacity relates to other commitments.
| Area | Information to establish | Why it matters |
|---|---|---|
| Organization | Responsible entity and operational contacts | Accountability and escalation |
| Hardware / region | Accelerator, memory, topology and location evidence | Workload compatibility and contract matching |
| Capacity / timing | Quantity, concurrency, window and existing obligations | Avoid overcommitting the same supply |
| Metering | Measurement definition and reservation-bound receipts | Verify the billed delivery |
| Data handling | Access, isolation, retention and incident procedures | Understand workload confidentiality boundaries |
| Collateral / failure | Backing, refunds, replacement and disputes | Make non-delivery consequences explicit |
Publish only what can be bounded#
A capacity declaration should specify the delivery window and quantity rather than imply unlimited access to a hardware class. Minimum order sizes are proposed to be configurable by providers within a platform-wide floor; exact thresholds are not published in the brief.
Changes in availability need a defined treatment for existing claims. Removing a listing must not silently erase an obligation. A production provider console needs consistent state between listings, outstanding commitments, runtime scheduling and settlement records.
Delivery creates an evidence obligation#
The provider must connect metering to the authorized reservation and submit the relevant receipt and result references. A general benchmark or hardware screenshot is not proof that a particular buyer received the contracted service.
Independent verification and a challenge window are part of the target design. The provider needs a response procedure for missing logs, partial execution, discrepancies and outages. Collateral can absorb some losses but does not replace evidence or create replacement hardware during a correlated failure.
How to start a provider conversation#
Use the Contact page to describe your organization, hardware models, region, quantity, time window and operating constraints. Do not send credentials or private customer workloads. An inquiry is a discussion, not automatic approval, listing or a promise of order flow.
A pilot should track delivered rather than merely listed GPU-hours, fill rate, verification pass rate, disputes and repeat demand. These measurements help distinguish usable supply from attractive catalog entries.
Common questions
Is provider registration permissionless?
Not in the proposed launch model. Manual approval comes first; permissionless participation is a later possibility with explicit prerequisites.
Does collateral guarantee every buyer can be reimbursed?
No. Its adequacy depends on the collateral rules and correlated losses. The brief identifies insufficient insurance coverage as a material risk.
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.