SpawnFarm
Join the waitlist →
Browse documentation
START HEREWhat is Spawn?60-Second ExplanationHow Spawn WorksKey TermsWho Participates
PRODUCTModels & BlueprintsWorldsSeasonsPositionsModel StoreLauncher Configuration
ECONOMICSThree-Asset Architecture$SPAWNOptional World TokensLaunch EconomicsPlayer EconomicsEconomic LineageFeesLiquidity
RUNTIMERuntime OverviewCompute ProfilesRuntime CostRuntime BatteryRuntime DepletionRuntime ProvidersLarge Data
VERIFICATIONDeterministic ExecutionCheckpointsVerification ClassesVerification & ReplayFinality & SettlementData AvailabilityRandomnessVaults & SettlementThreat ModelProtocol Invariants
BUILD ON SPAWNBuild a ModelModel SpecificationBlueprint StatusSpawn LabsLaunch a WorldWorld Creation FlowWorld ConfigurationOptional Token Design
REFERENCEOfficial $SPAWNProtocol StatusTrust ModelContractsChain CompatibilityFormula ReferenceGlossaryRiskFAQHistorical Archive
Docs / Build on Spawn / Blueprint Status
WORKINGv2.0

Blueprint Status

DRAFT → REPLAYABLE → TESTED → LAUNCHABLE.

Updated 2026-09-23 · Canonical at www.spawnfarm.com · Status labels describe evidence, not marketing readiness

Purpose

The Model Store is a marketplace/catalog for reusable Blueprints. Anyone should be able to develop and submit models without paying a launch burn simply to publish an idea.

Suggested status ladder

  • DRAFT — uploaded, not technically qualified.
  • REPLAYABLE — deterministic execution and state replay demonstrated in the reference environment.
  • TESTED — resource, serialization, input, failure, and replay tests pass.
  • LAUNCHABLE — satisfies the protocol interface required for a World launch.
  • VERIFIED IMPLEMENTATION — only after the stated cross-chain and security tests pass; this label must never imply scientific truth.

Store metadata

Each Blueprint listing should expose:

  • name/version/Designer;
  • category/subcategories;
  • plain-language description;
  • source/provenance summary;
  • license;
  • royalty terms;
  • configuration surface;
  • compute class;
  • benchmark cost/tick;
  • active data size and archive size;
  • expected storage cost;
  • verification class;
  • Worlds launched;
  • usage/fee statistics when live;
  • known limitations.

Competitive dynamic

Designers should compete not only on sophistication but on value per unit compute. A model with similar player value at one-tenth the runtime cost should be economically advantaged in the store.