Trust Model
What Spawn can verify, what users must trust, and the evidence required before a feature is called live.
Spawn combines onchain contracts, offchain computation, data, interfaces, and third-party infrastructure. No single label makes that entire system trustless.
What exists today
- The existing
$SPAWNtoken is live on Robinhood Chain. - The Pons community-takeover transition is publicly tracked but is not complete until the receiving configuration is verifiably changed.
- The v2 Model Store, Launchpad, World contracts, runtime, verification, and settlement system are under development.
Trust boundaries
| Layer | What can be established | What it cannot establish |
|---|---|---|
| Contract | deployed bytecode, permissions, balances, and state transitions | that the product is useful, safe, or fairly marketed |
| Provenance | which sources, files, licenses, and assumptions were declared | that a source is accurate or a Model is scientifically valid |
| Checkpoint | that an operator committed to specific bytes | that those bytes were computed correctly |
| Replay | that declared execution can be reproduced under the stated conditions | that the Model predicts reality |
| Attestation | that named verifiers accepted a result | independence, honesty, or mathematical certainty |
| Liquidity lock | that identified withdrawal paths are unavailable | price support, demand, or safety outside the lock |
Required launch disclosures
Before an economically active World is called LIVE, its public evidence pack must identify:
- every production contract address and target chain;
- verified source code or documented bytecode behavior;
- owner, administrator, upgrader, pauser, fee recipient, treasury, and signer authorities;
- whether each authority is an EOA, multisig, contract, or immutable rule;
- applicable delays, caps, emergency powers, and renunciation conditions;
- Blueprint, configuration, data, runtime, and verification versions;
- fees, settlement bounds, liquidity mechanism, and runtime-depletion behavior;
- completed tests, reviews, and known unresolved risks;
- transaction hashes for creation, configuration, and funding events.
An empty address field means not deployed. A planned audit, test, multisig, lock, or replay service must never be described as completed.
Minimum v1 evidence
The first public economic launch should demonstrate one complete path end to end: published Blueprint, retrievable data, pinned runtime, reproducible test vectors, funded execution, visible checkpoints, declared verification, and bounded settlement. A public replay client or equivalent reproducible procedure is required before a World may claim REPLAYABLE status.
Failure posture
When evidence is missing or conflicting, Spawn should fail closed: pause execution, withhold finality, prevent settlement, preserve the last finalized state, and display the unresolved condition publicly.
Spawn documentation makes mechanisms inspectable. It does not turn design intent into deployment evidence.