Operating model
One controlled loop, from registration to settlement.
The exchange is built around a single operational loop. Each step has an explicit status, an owner, and an audit record.
01
Provider registers
A provider applies, is reviewed, and is admitted to the exchange under a controlled status model.
02
Compute node is submitted
The provider describes the node: GPUs, VRAM, CPU, RAM, storage, operating system, drivers, runtime, and network.
03
Administrator verifies the node
Nodes move from submitted to verification pending to verified. Only verified capacity becomes listable.
04
Customer submits a workload request
The customer states workload type, GPU and VRAM requirements, duration, geography, privacy, and storage needs.
05
Administrator matches capacity
Requests are matched to eligible listings. Matches are proposed, then accepted or declined.
06
Deployment is opened
An approved match becomes a deployment with a recorded lifecycle: proposed, approved, provisioning, active.
07
Usage is recorded
Metered usage events are recorded against the deployment with idempotency keys to prevent double counting.
08
Deployment is closed
The deployment is completed, and the recorded usage becomes the basis for financial calculation.
09
Charges, proceeds, and fee are calculated
Gross customer charge, provider proceeds, and the 10% marketplace fee are written as separate append-only ledger entries.
10
Every material action is audited
Status changes, approvals, and financial events are recorded in an immutable audit trail.
Current build status
What is live today
Founding Beta intake, authentication, role-based application areas, the database foundation, and administrator review of applications are live. Node registration, verification workflows, matching, deployments, metering, and settlement are being implemented during the Founding Beta and are labelled accordingly inside the application. Live payments are not enabled.