How Spawn Works
Where Models, data, World parameters, runtime execution, records, and settlement live.
The complete flow
- A Designer turns an idea into explicit simulation rules.
- Code, data manifests, tests, documentation, and limits become a versioned Blueprint.
- A Launcher selects that Blueprint and chooses one World configuration.
- Spawn checks the configuration, dependencies, runtime cost, and verification plan.
- The World manifest identifies the exact Blueprint, parameters, seed, and economic rules.
- A browser, server, or specialized runtime executes the simulation off-chain unless the Model is small enough to run on-chain.
- Player actions enter an ordered event log. Economic actions and ownership changes use the applicable contracts.
- Full state remains in available storage while compact checkpoint hashes can be anchored on-chain.
- Independent software replays or checks results when the World requires verification.
- Any economic outcome settles only after its declared finality conditions are met.
This is the target architecture. The production modules remain under development.
Where each thing lives
| Component | Typical location |
|---|---|
| Model code | Versioned repository or package |
| Large source data | Cloud/object storage, database, IPFS, or similar available storage |
| Data manifest and file hashes | Blueprint package; important identifiers may be anchored on-chain |
| Launcher parameters | Versioned World configuration; its hash appears in the World manifest |
| Live simulation | Browser, server, cloud CPU/GPU, or future runtime provider |
| High-frequency actions | Signed off-chain event log or ordered batches |
| Ownership, payments, and settlement | On-chain contracts |
| Complete checkpoints | Available off-chain storage |
| Checkpoint fingerprints | On-chain registry or another declared public commitment layer |
What belongs on-chain?
Generally on-chain: World registration, Blueprint and configuration identity, token transfers, paid entry or actions, fee routing, deposits and withdrawals, checkpoint commitments, and final settlement.
Generally off-chain: physics calculations, mold cells, high-frequency movement, large datasets, visual state, intermediate results, and most non-economic interface actions.
The exact boundary changes by Model. A coin flip may run entirely on-chain. A Marble World may run deterministic physics off-chain and publish race checkpoints. A large agent-driven strategy World may batch thousands of signed actions and publish periodic state commitments.
Security boundary
The simulation controls the World. The settlement contract controls the money.
The runtime can calculate an outcome. It should never receive arbitrary authority over participant funds. Any value-bearing result must pass the verification and finality rules published for that World.
What replay proves
Replay can show that the runtime followed the declared Model, starting state, parameters, seed, and ordered actions.
It does not prove that a scientific assumption was correct or that a Model predicts reality. Technical reproducibility and real-world validity are separate claims.
Scaling from simple to complex
- Coin flip: tiny Model, no dataset, potentially fully on-chain.
- Marble Run: deterministic physics runtime, course files, race event log, replayable result.
- Mold: grid-based biological state, published parameters, periodic checkpoints, visual growth map.
- Large strategy World: distributed runtime, large state, signed action batches, published invariants, periodic commitments, and stronger review.
Spawn should never claim exact verification where a Model class cannot provide it. Each World must publish what is checked, how it is checked, and what participants still need to trust.