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 / Verification / Randomness
NEEDS PROOFv2.0

Randomness

Replayability, predictability, and competitive fairness.

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

The remaining work is calibration, proof, security review, and implementation.

Economic parameters

  • $SPAWN World-creation requirement, if adopted by verified production contracts.
  • Minimum World Token liquidity and whether launch templates scale it by market or World class.
  • Default World Token fixed-supply templates and Launcher/community/treasury allocations.
  • World Action Fee split: burn / World treasury / Launcher / Blueprint Designer / protocol.
  • Whether runtime receives local-token fees directly, receives $ETH fees, or receives proceeds only after an explicit conversion layer.
  • Player entry/position fees and whether competitive capital is gross or net of fees.
  • Blueprint royalty cap and whether Designers may choose within a bounded range.
  • Launcher fee cap.
  • Protocol fee and allocation between operations, grants, security/verification, and treasury.

Security parameters

  • Runner bond size relative to maximum settlement exposure.
  • Verifier bond/eligibility.
  • Required verifier quorum and diversity.
  • Challenge/finality period.
  • Exposure caps for REPLAYED versus ONCHAIN or future PROVED Worlds.
  • Emergency halt scope and governance.

Runtime parameters

  • Reference benchmark environments.
  • Resource-unit pricing model.
  • Minimum runtime runway before a World or Season may accept economic positions.
  • Treatment of unpredictable cloud/provider price changes.
  • Data-retention requirements and provider redundancy.
  • Runtime-market bidding, failover, and quality metrics.

Randomness

Competitive fairness needs explicit classification. Deterministic public-seed randomness is replayable but can be predictable. Candidate mechanisms include commit/reveal or a verifiable randomness source; no mechanism should be treated as selected until it is implemented and tested on the target chains.

Token launches, transferable local tokens, paid competitive simulations, outcome markets, and cross-jurisdiction participation may have different legal treatment. The architecture should support jurisdictional gating or disabling specific economic templates if counsel requires it. Outcome prediction markets are not required for core v1.