Browse documentation
NEEDS PROOFv2.0

Protocol Status

Current v2 implementation state and explicit distinction between live, working, unproven, and conceptual components.

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

Spawn uses explicit status language so documentation cannot be mistaken for deployment evidence.

Launch reality: $SPAWN is live as an existing token. The v2 platform is not yet a deployed protocol. The current public artifact is a working specification, website, and development program.

Canonical website: www.spawnfarm.com. The legacy domain spawn.farm is not controlled by the current community-led team and may contain outdated or conflicting claims.

Current CTO transition

Status: APPROVED — 72-HOUR FREEZE ACTIVE

Pons approved the community takeover on 2026-09-21 and initiated the required freeze. The freeze window is scheduled to end at 6:58 p.m. ET on Thursday, 2026-09-24.

During the freeze, the public record appears under Current Takeovers at cto.ponsfamily.com. After completion, it should appear under Archives. Completion must not be claimed until the receiving configuration is verifiably changed.

v2 system status

ComponentCurrent status
Existing $SPAWN tokenEXISTING TOKEN
CTO / creator-fee transitionAPPROVED / FREEZE ACTIVE / TRACKED PUBLICLY
v2 website + documentationPUBLIC / CURRENT DOCUMENTATION
Public browser simulation demoNEEDS PROOF
Blueprint RegistryNEEDS PROOF
World RegistryNEEDS PROOF
SpawnUnitVaultNEEDS PROOF
RuntimeVaultNEEDS PROOF
Replay verificationNEEDS PROOF
Reference Blueprint + public replay clientNEEDS PROOF
Open Runtime MarketplaceCONCEPTUAL
ZK / validity verificationCONCEPTUAL

Evidence standard

  • VERIFIED — implemented and tested to the stated Spawn standard.
  • NEEDS PROOF — technically plausible / designed, but the combined implementation has not passed the required validation gate.
  • CONCEPTUAL — longer-term direction or research path.
  • WORKING DECISION — current v2 architecture or product decision; not itself a deployment claim.

No module moves from NEEDS PROOF to VERIFIED solely because its design is documented. The applicable code, deployment, permissions, tests, and public evidence must exist.

Near-term proof target

The first meaningful product milestone is one reference World that a stranger can run and inspect. It should publish:

  • source and immutable version identifier;
  • seed, inputs, configuration, and expected checkpoints;
  • a browser demo or documented local command;
  • measured compute cost for a named workload;
  • replay or comparison instructions;
  • an explicit statement that no player-capital vault is used unless a verified vault exists.

Documentation volume does not substitute for this artifact.

Read the Trust Model →