Marketplace roadmap

The planned Marketplace turns verified computations into reusable products with immutable versions, finite API permissions and accountable service settlement. It is a broader business flow than Wallet Mining V3. A successful Devnet discovery reward does not complete the Marketplace.

Proposed catalog#

The catalog groups ten research projects covering response, stimulus search, intervention, optic flow, looming, heading, odor, anomaly, navigation and sparse retrieval into five product families:

The names describe proposed products, not completed trained models. Separate Core SKUs do not invent three independently trained models from the same underlying computation.

The ten-project/five-product catalog, eight draft price templates, additive migration and read-only catalog API are implemented. Prices require measured cost, benchmarks and explicit activation before they become offers.

The required end-to-end loop#

The proposed service loop

1. 01Verified workActual complete-model training data
2. 02Immutable modelTrain, evaluate and export genuine weights
3. 03Authorized API callFinite permission and real delivery
4. 04Settle + claimMature income and historical entitlements

Authorized complete-model work must generate actual training data. A small Ridge model must be trained, evaluated and exported with all weights, biases and normalization. Its immutable version and contributor share manifest must then be frozen.

A finite service authorization pays an actual call. Only delivered, settled and mature income creates historical entitlement. The original contributor can claim it. A second genuine call can create new historical earnings without new mining; retries of the same call cannot create duplicate charges, refunds, allocation or claims.

Scientific training requirements#

Inputs must not read the response they predict. Train/validation/test splits follow the underlying trajectory to avoid leakage between related samples. Distributed Ridge merges sufficient statistics rather than independently trained weight matrices.

Controlled shard recomputation checks coverage and matrix integrity. A target metric is distinct from measured achieved performance. Native work executes outside SQLite locks and HTTP execution threads; completed state requires successful durable artifact writes.

Finance and storage requirements#

The planned API payment asset is FBW. Its production identity and acquisition routes are not configured. The existing FBW Devnet asset is a test asset and does not fund production services.

The tested service domain enforces complete asset identity, finite allowances, request idempotency, cumulative pools/claims, refund limits and shared-vault coverage. A vault must cover the aggregate of customer, reserved, unmatured, refund, task and unpaid revenue obligations.

Complete small-model storage needs its actual content, order, length and references. A hash-only manifest does not mean the whole model is stored on chain; hybrid storage must be labeled.

Remaining implementation#

Still required are the independent service SBF adapter and actual SPL integration, budgeted assignment/lease/fencing endpoints, native workers, genuine training/export/evaluation, immutable release, finite API authorization, durable settlement/unknown-state reconciliation, refunds, historical claims and the full product acceptance matrix.

External data rights, including unresolved source licensing conflicts, must be resolved before affected products are activated. No imported catalog definition creates a worker, customer, revenue, accuracy or funding fact. Follow Feature availability for the current release scope.